Conçu comme protocole de communication série pour faire communiquer entre eux tous les systèmes électroniques présents à bord d’une voiture, le bus CAN gagne aussi du terrain dans les domaines d’automatisation industrielle (robotique) et de la domotique. Dans cette série d’articles, ou de Leçons (comme vous voudrez), nous allons aborder la théorie de son fonctionnement et nous prendrons de nombreux exemples dans le domaine domotique (c’est-à-dire des automatismes dédiés à la maison). Dans cette quatrième partie, nous analyserons comment un module peut acquérir des données et les rendre disponibles sur le bus.
personnalisables. Notre programme doit pouvoir dialoguer avec une sonde thermique au moyen d’un protocole
“one-wire” (monofil), communiquer les données sur bus CAN et les écrire dans une EEPROM à travers l’interface I²C.
Enfin, nous implémenterons encore des messages dans le nœud émet-teur, à des fins de diagnostic et de contrôle (ces messages travailleront sur RS232). Toutes ces fonctions sont regroupées dans des librairies.
La structure générale du projet logi-ciel est résumée dans le Tableau 1. Nous utiliserons en outre deux fichiers indispensables à différentes occasions :
1) C18cfg.asm : contient les valeurs pour les bits de configuration du PIC, comme celles relatives à la désactivation du temporisateur du chien de garde (“watchdog timer”) ou du type d’horloge utilisée ; nous y insérons aussi le fichier .inc à propos du microcontrôleur actuel-lement utilisé (dans notre cas p18f458.inc).
2) compilatore.h : dans ce fichier, nous regroupons toutes les défini-tions nécessaires à la reprise des registres du microcontrôleur et des valeurs intéressant la totalité du code de notre projet logiciel.
Par exemple, nous redéfinissons la broche correspondant à la ligne données de la sonde thermique (RB5) comme PORTB_RB5 : le but de l’opération est d’en faciliter l’uti-lisation.
Afin de rendre plus clair le développe-ment, analysons séparément les deux nœuds. Dans le paquet téléchargeable sur le site de la revue vous trouverez deux dossiers, le firmNODOTX et le fir-mNODORX, la finalité étant de distin-guer les deux sous-projets. Commen-çons par le nœud émetteur.
Nœud TX
Sur le nœud émetteur nous relions une sonde thermique DS18B20. Nous utilisons la broche RB5 du PIC18F458 comme ligne de données. Les deux autres broches de la sonde doivent être reliées l’une à la masse (GND) et l’autre à la ligne +5 V (Vdd). Il est nécessaire de monter une résistance de tirage de 4,7 k sur la broche de sortie du capteur Dallas ; pour que cela soit plus simple, utilisons directement les barrettes laté-rales de la platine d’expérimentation (voir figure 1).
Une fois la connexion de la sonde effectuée, préparons notre programme
résident. Nous avons surtout à réaliser un cycle de lecture des registres de la sonde concernant la température et leur envoi sur le bus CAN. Pour facili-ter les actions de l’usager, faisons en sorte que l’échantillonnage se fasse dès que l’on presse le poussoir SW2 de la platine d’expérimentation, soit celui qui est relié à la broche RB0 du PIC. L’envoi des lectures s’arrête dès que ce poussoir est maintenu pressé.
Nous avons décidé d’effectuer une mesure toutes les secondes environ.
L’état du nœud est signalé par trois LED de couleurs, en particulier au démarrage la LED verte s’allume afin de signaler que le nœud est prêt à recevoir la commande de départ avec SW2.
Figure 1 : Montage d’une sonde thermique DS18B20 sur le nœud émetteur et brochages de celle-ci (monter une résistance de tirage de 4,7 k sur la broche de sortie du capteur Dallas en utilisant les barrettes latérales de la platine d’expérimentation).
Tableau 1.
Fonction Fichier Description
Protocole onewire onewire.c Regroupe toutes les fonctions permettant d’effectuer le “reset”
onewire.h d’un dispositif onewire, de lui envoyer et d’en recevoir un octet.
C’est une récriture des instructions OWIN, OWOUT du PICBasic.
CAN bus ecan.c C’est la librairie de base que nous utiliserons pour tous les projets logiciels ecan.h sur bus CAN. Conçu pour la famille PIC18 à 64, 68, 80 broches mais,
ecan.def comme nous le verrons ultérieurement, elle peut s’adapter très facilement aux plus modestes 18F458 et, de toute façon, à tous les PIC18 dotés de module CAN.
EEPROM xeeprom.c Il s’agit d’une librairie utilisée pour l’accès, la lecture et l’écriture xeeprom.h des EEPROM à adressage 16 bits.
Optimisée pour la 24LC256 montée sur nos nœuds CAN.
RS232 usart.h C’est une librairie standard distribuée avec le compilateur C18.
Permet de gérer tous les aspects de la communication série selon le standard RS232.
Nous l’utiliserons pour les messages de contrôle envoyés au PC par le nœud émetteur.
Durant l’échantillonnage la LED rouge clignote. Enfin, après la pression sui-vante du poussoir, le nœud termine les opérations de transmission et la LED jaune s’allume. Toutes les phases d’élaboration peuvent être suivies à travers une session d’HyperTermi-nal ouverte directement sur le port série (celui-là même où nous avons relié la platine d’expérimentation) ; la COM devra être configurée selon les paramètres suivants : vitesse de transmission 19 200 bps, 8 bits de données, aucune parité, 1 bit de stop (19200-8-N-1).
Le premier problème rencontré a été celui consistant à écrire une petite librairie qui permet d’exécuter toutes les opérations de communication avec la sonde ; on a pu le résoudre facile-ment en nous référant au “datasheet”
(banque de données) du composant, dans lequel on nous explique en détail comment le DS18B20 est interrogé, quelles réponses il donne et dans quel format il exprime la température.
Naturellement, les fonctions ainsi construites seront éminemment uti-les chaque fois que nous devrons dialoguer avec un composant monofil (“onewire”). La sonde en question nous permet de mesurer la température en
°C avec une précision d’un demi degré entre –10°C et +85°C. La valeur est exprimée par deux octets dont les bits représentent le module et le signe ; il est possible de définir combien
Figure 2 : À chaque demande la sonde répond par deux octets dont les bits sont disponibles dans deux registres, selon le format représenté ici.
de bits utiliser pour l’un et combien pour l’autre : nous avons opté pour la formule 11 bits de valeur absolue (module) et 5 de signe.
Donc, à chaque demande la sonde répond par deux octets dont les bits sont disponibles dans deux registres, selon le format illustré figure 2. Les bits S permettent d’établir le signe de la température relevée (S=0 pour les valeurs positives, S=1 pour les néga-tives). Par exemple, avec une valeur égale à 00A2h nous aurons une tem-pérature égale à 10,125 °C et avec FFF8h une température de –0,5 °C.
Le protocole “OneWire”
Le système de communication prévu pour le DS18B20 réclame l’utilisation d’un protocole particulier mais très efficace. N’importe quelle opération commence par le dispositif “master”
(maître), représenté ici par le PIC.
La première phase à considérer est le
“reset” (réinitialisation) du dispositif, consistant en une impulsion provenant du “master”, auquel la sonde répond par l’envoi d’un signal de présence.
Pour vous éclaircir les idées à propos de la phase de réinitialisation, jetez un coup d’œil au schéma de la figure 3.
Durant cette phase, le microcontrôleur met au niveau logique bas la ligne de données pendant au minimum 480 µs.
Ensuite, il se met en réception et, pour
cela, il se détache du bus ; par consé-quent la résistance de tirage met la ligne au niveau logique haut. Dès que la sonde détecte ce changement, elle attend pendant un délai allant de 15 à 60 µs, puis elle envoie une impulsion de présence en mettant la ligne au niveau logique bas pendant un délai de 60 à 240 µs.
A la fin elle se détache à nouveau du bus et la résistance de tirage remet la ligne de données au niveau logique haut. Toute cette procédure peut être facilement développée en C18. Nous avons regroupé les instructions sous la fonction du Listing 1.
La fonction Delay10TCYx(n) fait partie de la librairie standard C18 et permet d’insérer un retard égal à 10n cycles d’horloge. Il est clair que la tempori-sation dépend de la fréquence d’hor-loge de l’oscillateur utilisé (pour nous 20 MHz). Pour la mettre en œuvre, il suffit d’insérer les instructions sui-vantes :
#include <delays.h>
La “OWReset” renvoie une valeur égale à 1 si le PIC reçoit l’impulsion de présence de la part de la sonde et elle peut donc être utilisée à l’in-térieur d’une expression logique. De même, nous avons préparé la fonction
“OWTX” pour transmettre un octet au dispositif et la “OWRX” pour recevoir toujours un octet de celui-ci. Pour des raisons d’espace, nous n’analyserons pas leur “listing”. Les plus curieux de nos lecteurs peuvent satisfaire leur
“vilain défaut” en ouvrant le fichier du projet CANTX.mcp et en faisant un double clic sur le fichier “onewire.c”.
Toutes les déclarations relatives à cha-que fonction on été recueillies dans le fichier onewire.h. Voici une liste qui fait la synthèse des diverses procédures : - unsigned char OWReset (void) :
exé-cute l’initialisation de la sonde en en détectant la présence sur le bus ; renvoie la valeur 1 si la sonde est présente ;
Figure 3 : Phase de réinitialisation du microcontrôleur.
- void OWTX (unsigned char) : envoie au dispositif relié l’octet passé comme paramètre ;
- unsigned char OWRX (void) : reçoit un octet du dispositif relié et le passe à travers le paramètre de sortie ;
- unsigned char OWRX1 (void) : reçoit un unique bit du dispositif ; est utilisé pour vérifier si le relevé de la température est terminé ou non.
En ce qui concerne le relevé de la température, il est nécessaire d’utiliser des séquences spécifiques afin de commander le DS18B20. En envoyant la paire d’octets CCh-44h on lance une conversion.
Durant l’opération, le dispositif envoie un 0 et, dès qu’il a terminé, un 1 logi-que. Il est alors possible d’envoyer la séquence CCh-BEh pour lire les regis-tres de la sonde, structurés comme le montre le Tableau 2.
Pour nous, il suffit d’extraire les deux premiers octets ; en effet, nous uti-lisons la configuration prédéfinie de la sonde et, pendant la lecture, nous écarterons les 7 octets restants.
Le code C18, qui permet de repérer les informations que nous devrons ensuite transférer via le bus CAN, est celui du Listing 2. On voit que les deux octets de la valeur de la température relevée sont transférés dans deux champs de 8 bits composant la variable tempera.
Pour effectuer cette attribution de manière correcte, il a fallu définir une structure adéquate, comme le montre le code du Listing 3.
La communication RS232 Pour envoyer un message à un PC tout en permettant à l’usager de suivre les diverses phases de l’élaboration, nous devons utiliser une autre librairie distri-buée avec le compilateur C18.
Là encore, nous mettons en œuvre une instruction d’inclusion (“include”) relative au fichier usart.h contenant la déclaration des diverses fonctions uti-lisables ; voyons concrètement celles qui sont nécessaires à notre projet.
Avant tout nous devons initialiser le port de communication selon les para-mètres définis durant l’analyse initiale du projet logiciel. La fonction corres-pondante est la suivante :
void OpenUSART (unsigned char con-fig, unsigned int spbrg);
Le premier paramètre est créé à tra-vers une opération de AND entre une série de valeurs définies dans le fichier usart.h et qui permettent d’établir le fonctionnement précis du module série du PIC18F458, module correspondant aux broches RC6 et RC7 (Tableau 3). Le second précise la vitesse de transmission. Dans le cas d’une réception/transmission de type asynchrone, la valeur est calcu-lée avec la formule suivante :
FOSC/(16* (nbr de bit/seconde + 1)) en prenant comme FOSC la valeur de la fréquence d’oscillation du quartz utilisé par le circuit. Pour nous, avec un FOSC de 20 000 000 (20 MHz) et une vitesse
de 19 200 bps, la valeur du paramètre est :
((20 000 000 : 19 200) : 16) –1 = 64,104
Nous utilisons donc le 64. Ce résultat présuppose l’utilisation d’un prédivi-seur (“prescaler”) par 16. L’instruction utilisée pour l’initialisation du port est la suivante :
OpenUSART(USART_TX_INT_OFF&USART _RX_INT_OFF&USART_ASYNCH_MODE&
USART_EIGHT_BIT&USART_CONT_RX&
USART_BRGH_HIGH, 64);
Pour envoyer une quelconque phrase à travers le port série, nous pouvons nous servir de la putrsUSART.
Elle prend en entrée le pointeur à un flux de caractères ; en général on se sert de la putrsUSART pour des flux enregistrés dans la mémoire de données et de la putrsUSART pour des flux de la mémoire de programme. La déclaration que nous trouvons à l’intérieur de la usart.h est la suivante :
void putrsUSART (const rom char *data );
L’utilisation est très simple : il suffit de passer comme argument la phrase entre guillemets, comme le montre l’instruction suivante :
putrsUSART(“Electronique Loisir Maga-zine \n\r”);
Nous utilisons \n et \r pour les carac-tères, respectivement de “new line”
Le PIC met au niveau logique bas la ligne DQ pendant 480 µs.
Le PIC se détache du bus, se met en réception et attend 80 µs de manière à détecter l’impulsion de présence pendant ce délai.
Si le niveau logique bas est détecté, la sonde a répondu correcte-ment et donc le paramètre de sortie est valorisé à 1.
Les définitions pour le bus CAN
Après avoir vu ces quelques codes préliminaires, analysons le cœur du programme résident et par conséquent la partie nécessaire pour effectuer la communication sur le bus CAN. Avant tout, nous devons considérer le fichier ECAN.def contenant tous les para-mètres nécessaires pour configurer le module CAN du PIC18F458. Par commodité, nous utilisons l’interface graphique de Microchip Application Maestro ; toutefois, pour effectuer les modifications adéquates, vous êtes libres d’utiliser n’importe quel éditeur (à la ligne) et “carriage return” (retour
chariot) nécessaires pour faire revenir le curseur au début.
Tableau 2.
Octet 0 Température LSB Octet 1 Température MSB Octet 2 Registre THEORIE Octet 3 Registre TL
Octet 4 Registre Configuration Octet 5 Réservé FFh
Octet 6 Réservé OCh Octet 7 Réservé 10h Octet 8 CRC
Tableau 3.
Valeur Description
USART_TX_INT_ON Active/désactive le signal d’interruption en transmission USART_TX_INT_OFF
USART_RX_INT_ON Active/désactive le signal d’interruption en réception USART_RX_INT_OFF
USART_ASYNCH_MODE Active le mode de transmission/réception asynchrone ou synchrone USART_SYNCH_MODE
USART_EIGHT_BIT Transmet/reçoit données à 8 bits ou à 9 bits USART_NINE_BIT
USART_SYNC_SLAVE En mode de transmission/réception synchrone USART_SYNC_MASTER configure le module comme Esclave ou comme Maître USART_SINGLE_RX Etablit si la réception doit se faire de manière continue USART_CONT_RX ou pour un seul paquet
USART_BRGH_HIGH Etablit si le module doit être initialisé pour une vitesse USART_BRGH_LOW de transmission élevée ou non
de texte. Le Tableau 4 représente la séquence entière des paramètres utili-sés dans nos nœuds ; pour la description des champs, nous vous renvoyons à la troisième partie, soit au numéro précé-dent d’ELM.
On utilise des points de suspension là où les valeurs se répètent pour plusieurs paramètres à la suite ; par exemple, la valeur 0x0L pour le paramètre ECAN_RXF2_VAL se répète aussi pour ECAN_RXF3_VAL, ECAN_RXF4_VAL, ECAN_RXF5_VAL.
Attention, nous utiliserons un mode de fonctionnement constant pour toute
Listing 2.
OWReset();
OWTX(0xCC);
OWTX(0x44);
while (OWRX1());
OWReset();
OWTX(0xCC);
OWTX(0xBE);
tempera.bytes.LSB = OWRX();
tempera.bytes.MSB = OWRX();
for (indice=1;indice<=7;indice++) conv=OWRX();
Reset de la sonde et lancement de la détection de la température.
Attente jusqu’à la fin de la détection.
Demande des 9 octets contenus dans les registres de la sonde.
Enregistrement des deux premiers octets.
Les 7 derniers octets écartés.
Listing 3.
union {
unsigned short Val;
struct {
unsigned char LSB; /*Last significant byte*/
unsigned char MSB; /*Most significant byte*/
} bytes;
} tempera; /*Température divisée en deux champs*/
Tableau 4.
Paramètre Valeur
ECAN_LIB_MODE_VAL ECAN_LIB_MODE_FIXED
ECAN_FUNC_MODE_VAL ECAN_MODE_0
ECAN_INIT_MODE ECAN_INIT_NORMAL
ECAN_SJW_VAL 2
ECAN_BRP_VAL 4
ECAN_PHSEG1_VAL 8
ECAN_PHSEG2_VAL 8
ECAN_PROPDEG_VAL 8
ECAN_PHSEG2_MODE_VAL ECAN_PHSEG2_MODE_PROGRAMMABLE
ECAN_BUS_SAMPLE_MODE_VAL ECAN_BUS_SAMPLE_MODE_THRICE
ECAN_WAKEUP_MODE_VAL ECAN_WAKEUP_MODE_ENABLE
ECAN_FILTER_MODE_VAL ECAN_FILTER_MODE_DISABLE
ECAN_TXDRIVE_MODE_VAL ECAN_TXDRIVE_MODE_VDD
ECAN_TX2_SOURCE_VAL ECAN_TX2_SOURCE_COMP
ECAN_CAPTURE_MODE_VAL ECAN_CAPTURE_MODE_DISABLE
ECAN_RXBO_MODE_VAL ECAN_RECEIVE_ALL_VALID
ECAN_RXBO_DBL_BUFFER_MODE_VAL ECAN_DBL_BUFFER_MODE_DISABLE
ECAN_RXB1_MODE_VAL ECAN_RECEIVE_ALL_VALID
ECAN_B1_TXRX_MODE_VAL ECAN_BUFFER_TX
ECAN_B1_MODE_VAL ECAN_RECEIVE_ALL_VALID
ECAN_B1_AUTORTR_MODE ECAN_AUTORTR_MODE_DISABLE
…ECAN_B5_TXRX_MODE_VAL ECAN_BUFFER_TX
ECAN_B5_MODE_VAL ECAN_RECEIVE_ALL_VALID
ECAN_B5_AUTORTR ECAN_AUTORTR_MODE_DISABLE
ECAN_RXFO_MODE_VAL ECAN_RXFn_ENABLE
ECAN_RXFO_MSG_TYPE_VAL ECAN_MSG_STD
ECAN_RXFO_VAL OxOL
ECAN_RXFO_BUFFER_VAL RXBO
ECAN_RXFO_MASK_VAL ECAN_RXMO
ECAN_RXF1_MODE_VAL ECAN_RXFn_ENABLE
ECAN_RXF1_MSG_TYPE_VAL ECAN_MSG_STD
ECAN_RXF1_VAL OxOL
ECAN_RXF2_MODE_VAL ECAN_RXFn_ENABLE
ECAN_RXF2_MSG_TYPE_VAL ECAN_MSG_STD
ECAN_RXF2_VAL OxOL
ECAN_RXF2_BUFFER_VAL RXB1
ECAN_RXF2_MASK_VAL ECAN_RXM1
…ECAN_RXF5_MODE_VAL ECAN_RXFn_ENABLE
ECAN_RXF5_MSG_TYPE_VAL ECAN_MSG_STD
ECAN_RXF5_VAL OxOL
ECAN_RXF5_BUFFER_VAL RXB1
ECAN_RXF5_MASK_VAL ECAN_RXM1
ECAN_RXF6_MODE_VAL ECAN_RXFn_ENABLE
ECAN_RXF6_MSG_TYPE_VAL ECAN_MSG_STD
ECAN_RXF6_VAL OxOL
ECAN_RXF6_BUFFER_VAL RXB0
ECAN_RXF6_MASK_VAL ECAN_RXM0
…ECAN_RXF15_MODE_VAL ECAN_RXFn_ENABLE
ECAN_RXF15_MSG_TYPE_VAL ECAN_MSG_STD
ECAN_RXF15_VAL OxOL
ECAN_RXF15_BUFFER_VAL RXB0
ECAN_RXF15_MASK_VAL ECAN_RXM0
ECAN_RXM0_MSG_TYPE_VAL ECAN_MSG_STD
ECAN_RXM0_VAL OxOL
ECAN_RXM1_MSG_TYPE_VAL ECAN_MSG_STD
ECAN_RXM1_VAL OxOL
l’élaboration (ECAN_LIB_MODE_FIXED) avec le protocole standard (ECAN_
MODE_0) et la gestion des opérations de transmission comme de réception (ECAN_
// ECANCON_MDSEL1 = ECAN_FUNC_MODE_VAL >> 7;
// ECANCON_MDSEL0 = ECAN_FUNC_MODE_VAL >> 6;
INIT_NORMAL). Si l’on considère que le
“bit time” (durée du bit) est égal à 25 TQ (le maximum selon le standard CAN) et que nous utilisons une fréquence de 20 MHz, la vitesse de transmission est égale à 80 kbps.
La vitesse en question est certainement suffisante, du moins si l’on considère que nos paquets auront une partie de don-nées longue de deux octets tout au plus, ceux relatifs à la température relevée. Si vous observez les autres paramètres, vous remarquerez que toutes les fonc-tions de filtrage des messages (filtres et masques sont à zéro) sont désactivés ; tous ceux considérés comme valides
seront acceptés. Bien que ce soit une simplification, cela nous permettra d’ap-précier la différence de fonctionnement dans le cas où l’un des filtres du module serait activé. Pour notre premier projet, nous laissons une possibilité de dialogue maximale entre les deux nœuds.
Modifications d’implémentation
La librairie que nous utilisons est une version modifiée de celle que l’on trouve sur le site de Microchip. Les dif-férences sont en partie formelles et en partie substantielles. Dans le premier cas, on a principalement éliminé les définitions et les structures relatives à l’utilisation des autres compilateurs ; dans l’autre, nous avons éliminé cer-taines instructions spécifiques de la classe supérieure des PIC (64, 68, 80 broches) pour lesquels la librairie a été
La librairie que nous utilisons est une version modifiée de celle que l’on trouve sur le site de Microchip. Les dif-férences sont en partie formelles et en partie substantielles. Dans le premier cas, on a principalement éliminé les définitions et les structures relatives à l’utilisation des autres compilateurs ; dans l’autre, nous avons éliminé cer-taines instructions spécifiques de la classe supérieure des PIC (64, 68, 80 broches) pour lesquels la librairie a été