Dans le cadre de l'évolution du relais de Montpellier
F1ZGU, il est nécessaire de disposer d'une unité de commande
capable de gérer de nombreux périphériques:
- un émetteur-récepteur VHF: commande arrêt-marche
TX, squelch, CTCSS
- un éventuel récepteur VHF ou UHF supplémentaire,
dédié à la réception des télécommandes
- une commutation de sources audio: récepteur VHF, annonces vocales,
générateur 1000 Hz
- un émetteur de télévision d'amateur: commande arrêt-marche
- une commutation de sources vidéo: mire, différents récepteurs,
données à 2 Mbit/s
- un récepteur de télécommande DTMF, avec deux niveaux
de fonctions: utilisateur et administrateur
- un afficheur LCD fournissant des informations d'exploitation
Il est de plus souhaitable de réaliser une unité
de commande évolutive, capable d'intégrer facilement, au
fur et à mesure de l'évolution des besoins, de nouveaux
périphériques et de nouvelles fonctions.
A contrario, on pourra observer que, l'ensemble étant
modulaire, il est possible de n'installer que les modules strictement
nécessaires à l'application envisagée. Pour un simple
relais VHF, seuls les modules microcontrôleur, commutation audio,
annonce vocale et interface radio sont utiles. Bien entendu, les modules
logiciels correspondants doivent être activés en conséquence.
-
architecture matérielle
Afin
d'éviter un câblage dense, une gestion de connexions d'entrées-sorties
problématique et pour préserver l'évolutivité
de l'ensemble, le microcontrôleur et les périphériques
sont organisés autour d'un bus I2C. Ce dernier est constitué
d'un simple câble à deux conducteurs, blindés séparéments.
Le traitement des informations est confié à un microcontrôleur
PIC type 16F876, qui joue le rôle de maître. Les périphériques
mentionnés ont un statut d'esclave et échangent leurs informations
à travers le bus au moyen de circuits interface 8 I/O PCF8574 ou
PCF8574A. Il est possible de placer au total 16 de ces circuits sur le
bus, ce qui représente 16 x 8 = 128 entrées ou sorties adressables
séparément. Enfin un circuit horloge PCF8583, dont le rôle
sera précisé au paragraphe suivant est placé également
sur le bus.
-
architecture logicielle
Dans un système comme celui décrit, des événements
extérieurs simultanés peuvent apparaître: ouverture
d'un squelch de récepteur pendant qu'a lieu une réception
de codes DTMF, par exemple. Il est donc nécessaire que plusieurs
tâches puissent être réalisées de manière
quasi-simultanée. Par ailleurs, comme d'autres événements,
les codes DTMF reçus se succèdent à leur propre rythme
et doivent être traités sans délai, sous peine de
dysfonctionnements graves. Il n'est donc pas imaginable d'introduire des
boucles d'attente longues comme on peut les rencontrer dans les systèmes
simples qui n'ont à gérer qu'un type d'événement
à la fois.
Pour résoudre ces problèmes, on fera appel
à un "ordonnancement circulaire": chaque périphérique
sera visité, très vite, et à tour de rôle.
Pour ne pas perdre de temps, les événements seront notés
en RAM au fur et à mesure de leur apparition, puis traités
au plus tôt. Lorsqu'un événement nécessite
une action différée (par exemple une attente de confirmation
ou une temporisation), l'heure d'apparition de l'événement
sera notée en RAM, et les durées calculées par simple
différence avec le temps actuel. Pour obtenir un fonctionnement
satisfaisant, en particulier pour un traitement correct des signaux DTMF,
il est souhaitable que dans tous les cas le cycle complet de visite et
de traitement des différents périphériques s'effectue
en moins de 10 ms.
le cycle
( le périphérique # 1 est constitué de l'horloge
donnant l'heure système)
Pour permettre la tenue de la contrainte temps réel,
le logiciel sera écrit en langage assembleur, et assemblé
au moyen de l'environnement
MPLAB et du logiciel MPASM fournis gratuitement par Microchip. Pour
faciliter la maintenance et l'évolutivité de l'ensemble,
les modules logiciels suivront autant que possible la découpe matérielle.
A chaque module matériel correspondra un module logiciel contenant
les fonctions de base associées. Il restera à ajouter un
peu de "liant" dans la boucle principale pour animer l'ensemble
!
le bus I2C véhicule un flot continu de données
(fil SDA, 1 ms/division)
- considérations système
Un tel système peut-il fonctionner et, dans l'affirmative,
quelles sont ses limites ?
Tout d'abord, au niveau matériel, les spécifications
I2C fixent à 400 pF la capacité électrique maximum
du câblage. Ceci correspond à une quinzaine de périphériques
I2C à 10 pF de capacité d'entrée plus 2,5 mètres
de câble à 100 pF/m, ce qui est tout à fait compatible
avec le projet. Les périphériques pourront être répartis
dans plusieurs tiroirs d'une baie 19 pouces.
L'aspect temps réel est plus critique. L'I2C standard
travaille avec une horloge cadencée à 100 kHz maximum, soit
une période de 10 µs. Lire un octet sur un périphérique
nécessite la transmission d'un octet pour l'adresse, plus la réception
de l'octet proprement dit, plus les signaux de protocole, ce qui demande
grossièrement 250 µs. Une quinzaine de périphériques
peuvent être lus en 15 x 250 = 3750 µs, ce qui laisse un temps
plus que confortable pour les traitements par le microcontrôleur,
ces derniers ne représentant qu'un poids négligeable. Deux
périphériques transmettent ou reçoivent plusieurs
octets et doivent donc faire l'objet d'une vigilance particulière
pour ne pas dépasser la barre fixée des 10 ms:
- l'horloge système transmet, centièmes de
secondes, secondes, minutes et heures, soit quatre octets. Pour éviter
les transmissions répétées sur le bus, l'heure ne
sera lue qu'une fois en début de cycle et stockée en mémoire
RAM. L'heure sera donc une heure "cycle".
- l'afficheur LCD. Voici un périphérique par
instants très gourmand en temps d'utilisation du bus ! Compte tenu
de la gestion de la broche "Enable" des afficheurs standards,
trois octets sont nécessaires, en sus de l'octet d'adresse, pour
afficher un seul caractère. Plus de 5 ms sont donc nécessaires
pour afficher une ligne de 16 caractères. Comme, même un
observateur attentif ne verra pas de contrainte temps réel pour
un affichage LCD, on résoudra le problème par une gestion
particulière de l'affichage sur la base d'un fractionnement, ou
d'une file d'attente.
Les différents modules matériels sont placés
dans un tiroir 19 pouces, une unité. La face avant comprend de
gauche à droite, l'interrupteur marche/arrêt, l'afficheur
à cristaux liquides, un connecteur Sub-D pour la programmation
in-situ au moyen d'un ordinateur portable, et un bouton de remise à
zéro (hard reset).
A noter sur la face arrière, en sus des connecteurs
audio et vidéo, deux connecteurs Sub-D qui permettent de prolonger
le bus I2C. En fait, chacun des tiroirs 19" d'extension comprend
en face arrière deux connecteurs Sub-D, ce qui permet de chaîner
de proche en proche le bus, pour une évolutivité maximale.
Une réalisation encore incomplète
