Il est fourni à titre d'exemple et le lecteur pourra
bien sûr l'adapter en fonction de ses besoins. Il est écrit
en assembleur pour PIC 16F876:
Il est nécessaire de compiler le programme source
fourni, au moyen de MPLAB, puis d'introduire le fichier .hex obtenu dans
le microcontrôleur PIC 16F876 grâce au logiciel ICprog paramétré
avec l'option "AN589". Le module microcontrôleur-horloge
autorise la programmation in-situ au moyen d'un simple câble raccordé
au port parallèle d'un ordinateur portable. Il s'agit là
d'une facilité et rien n'empêche bien sûr de procéder
au changement de version logicielle d'une manière plus traditionnelle
par débrochage puis rebrochage du PIC.
L'émetteur est commandé par la réception
d'une porteuse sur le récepteur. L'information est un niveau
logique provenant du squelch du récepteur.
Nous avons à notre disposition quatre modes dits
"modes administrateur" et trois commandes utilisateurs. Les
modes administrateur sont activés par l'envoi d'un code secret
suivi d'un caractère définissant le mode choisi. Les commandes
utilisateurs sont publiques.
- le mode administrateur A
Le relais fonctionne pendant une durée de 120 minutes après
l'envoi d'une commande utilisateur d'activation. L'utilisateur peut
également décider d'arrêter prématurément
le relais.
- le mode administrateur B
Le relais fonctionne dès l'envoi d'une commande utilisateur d'activation.
L'utilisateur peut ensuite décider d'arrêter le relais.
Il n'y a pas de temporisation.
- le mode administrateur C
Le relais fonctionne en service permanent. Les commandes utilisateurs
sont inhibées, hormis la commande de beep long (signal 1000 Hz
pendant 10 secondes) utilisée à des fins de test.
- le mode administrateur Z
Le relais est arrêté. Les commandes utilisateurs sont sans
effet. Le récepteur et le décodeur DTMF restent cependant
à l'écoute des codes transmis, dans l'attente d'une éventuelle
demande de retour en fonctionnement.
- la commande utilisateur 0
Allume le relais
- la commande utilisateur 1
Eteint le relais
- la commande utilisateur 9
Le relais transmet à des fins de test un signal audio 1000 Hz
pendant 10 secondes. Ceci est utile pour permettre des réglages
d'antennes ou de récepteurs.
Le système n'est pas fermé. Lorsqu'on a
bien compris la structure du logiciel, explicitée plus bas, il
devient facile de modifier des paramètres, d'ajouter de nouveaux
modes administrateur ou de nouvelles commandes utilisateurs !
Un accusé réception, sous la forme d'un
beep de fréquence 1000 Hz et de durée 800 ms, est par
ailleurs émis après chaque commande active.
Le logiciel est écrit en assembleur 16F876 et conçu
de manière modulaire. Pour les commentaires, on se rapportera
au fichier transp.lst qui comporte des numéros de lignes.
télécharger le programme
source transp.asm (20 ko zippé)
La ligne 033 indique la configuration retenue pour le
PIC (état des "fusibles"). Dans cette version nous
n'activons pas le watchdog.
De la ligne 036 à 093, nous trouvons la déclaration
des différentes variables utilisées dans le programme.
De la ligne 112 à la ligne 221, se trouvent les
routines I2C. Il y a là plusieurs heures de travail personnel
avant d'obtenir un fonctionnement correct. Aussi, sauf si l'on est un
expert du domaine, il est déconseillé de toucher à
ces routines. La procédure pour envoyer un octet à un
périphérique est très simple: on entre l'adresse
I2C du périphérique dans la variable "SlaveAddr",
puis l'octet à transmettre dans la variable "ByteToSend".
Il suffit ensuite d'appeler le sous programme d'émission par
la ligne "call Send_Byte" pour déclencher l'envoi du
message I2C.
exemple de code:
movlw 0x24 ; address of radio module
movwf SlaveAddr
movlw b'01111111' ; TX ON, Audio from RX ON
movwf ByteToSend
call Send_Byte
La procédure de lecture des octets sur un périphérique
est similaire avec un appel par l'instruction "call Receive_Byte",
l'octet lu étant récupéré dans la variable
"Received_Byte".
De la ligne 222 à la ligne 343 nous trouvons la
routine d'initialisation du circuit horloge PCF8583, puis la routine
de lecture de l'heure système : centièmes de secondes,
secondes, minutes et heures, soit quatre octets. Les variables Hundredths,
Seconds, Minutes et Hours sont mises à jour. Les jours et mois
seraient disponibles, mais ne sont pas chargés.
De la ligne 344 à la ligne 422, nous trouvons les
routines de gestion de l'octet "administrateur". Celui-ci
est essentiel au fonctionnement du relais car il conditionne son comportement.
Il ne doit bien sûr pas être altéré par une
coupure de secteur. Aussi, est-il sauvegardé en EEPROM dès
son acquisition ou sa modification. Après un arrêt du système,
une procédure d'initialisation restaure le contenu de l'octet
"administrateur" à partir de son image sauvegardée
en EEPROM.
De la ligne 423 à la ligne 443 nous trouvons deux
fonctions d'initialisation et de lecture des codes DTMF sur le module
de réception DTMF. Les lignes 444 à 470 réalisent
les mêmes opérations pour le module interface radio.
A la ligne 471 débute le programme principal, par
une séquence d'initialisation de tous les modules périphériques,
puis la grande boucle à la ligne 493.
A noter que la communication entre les différentes
sections du logiciel s'effectuent au moyen de drapeaux ou "flags".
Leur signification précise est détaillée dans une
page spécifique.
Les lignes 497 et 498 servent à génerer
une impulsion test de 1 µs, d'amplitude 5 V sur la patte RB1 du
16F876. On peut ainsi mesurer facilement, au moyen d'un oscilloscope,
le temps mis pour boucler la boucle: utile dans un système "temps
réel" !
le test de la durée de boucle: ici T = 1700 µs
A la ligne 503 nous débutons la réception
et l'analyse des codes DTMF reçus. Les caractères reçus
sont stockés dans un buffer circulaire de 16 chiffres "Digit_Counter",
grâce à un adressage indirect. Une mise en phase est assurée
lors de la réception d'un caractère particulier: ici le
caractère " * ".
Nous trouvons ensuite les échelles de décodage
des séquences utilisateurs et administrateur. Le 6ème
et 10ème caractère, respectivement, sont sauvegardés
comme étant l'octet utilisateur et l'octet administrateur.
Bien que purement logiciels, les timers sont très
précis. Leur nombre est ici de trois, mais n'est en fait pas
limité. Nous faisons appel à un algorithme simple mais
très efficace:
Nous avons vu que nous chargions l'heure système, heures, minutes,
secondes et centièmes de secondes, dans des variables spécifiques
en début de chaque boucle. Pour réaliser par exemple une
temporisation de 120 secondes, il suffit d'observer la valeur du chiffre
des secondes et d'incrémenter un compteur chaque fois que le
chiffre des secondes de l'heure système est modifié entre
deux cycles successifs. Lorsque le compteur atteint la valeur 120, la
temporisation est écoulée.
A partir de la ligne 765, nous trouvons les arbres de
décision qui déterminent les actions à mettre en
oeuvre en fonction de l'environnement (squelch, CTCSS, temporisations,...),
et des valeurs des octets utilisateurs et administrateur.
Les messages I2C d'allumage ou d'extinction de l'émetteur
et de sélection de la source audio sont situés à
partir de la ligne 801.
Enfin, la ligne 829 marque la fin d'un cycle et le renvoi
vers le début de la boucle.
