Mise en oeuvre du bus CAN

1. Présentation

• Entrées TOR (Tout Ou Rien) optocouplées
• Sorties TOR sur relais
• Sorties TOR ou gradateurs sur relais statiques (utilisations de triacs)
• Récepteurs de télécommandes radio
• Emetteurs/Récepteurs de télécommandes IR
• Capteurs de température, d'humidité, de niveau d'eau,...
• Claviers numériques avec afficheur LCD

• Eclairage
• Alarme
• Arrosage automatique
• Chauffage
• Sonorisation
• ...

 

1. But de cette page

Le but de cette page est de vous expliquer la mise en oeuvre du bus CAN sur les microcontroleurs PIC de chez Microchip à l'aide des librairies écrites en language C. Etant donné le volume d'informations sur le net ainsi que dans les livres, je ne détaillerai pas le fonctionnement du bus CAN ainsi que celui des autres bus de terrain. Je vous renvoie aux liens.

Cet article s'adresse à ceux qui ont des connaissances sur la programmation en C des microcontroleurs PIC ainsi qu'une base sur le fonctionnement des bus de terrain. Je ne saurai que vous recommander de visiter les liens.

1. Le Bus CAN ( Controller Area Network )

Le bus CAN est un bus de terrain crée par l'équipementier automobile BOSCH, il est utilisé sur les véhicules pour interconnecter les équipements et permettre l'échange de données. Il peut utiliser plusieurs types de supports physiques pour véhiculer les données sous forme série (simple fil, paire différentielle, radio, fibre optique, courant porteurs, ... ). Le support principal étant la paire différentielle en raison de son faible cout et de son immunité aux parasites.



 

• La connection sur le bus CAN

La connection au bus CAN est réalisée à l'aide d'un transceiver CAN et d'un controller CAN, le controleur pouvant etre intégré dans un microcontroleur.

Comme transceiver, je peux vous donner comme exemple le MCP2551 de chez Microchip et le PCA82C250 de chez Philips.

• Les Controleurs CAN

Le bus CAN étant un bus complexe, il est difficile de le mettre en oeuvre de manière totalement software. Les controleurs CAN permettent de gérer le bus de manière hardware ils intègrent les couc, avec les transceivers, les couches 1 (physique) et 2 (liaison) du modèle OSI.

On distingue deux types de Controleurs :

Ceux externes au Microcontroleurs reliés à ce dernier par une liaison de type SPI , comme le MCP2515.

Les Controleurs intégrés aux microcontroleurs qui disposent donc d'un module CAN avec les lignes TXCAN et RXCAN reportés sur les pins et destinés à êtres reliés au transceiver CAN.

• Les Microcontroleurs 8bits avec controleur CAN intégré de chez Microchip

Il en existe plusieurs, les premiers étants les suivants :

PIC18F248, PIC18F258, PIC18F448, PIC18F458

Ceux-ci ont quelques bugs qui font qu'ils ont un fonctionnement erratique si on ne les utilise pas d'une manière particulière(gestion de banques de mémoire, des interruptions,...). Les "Erratas" sont disponibles sur le site de Microchip.

J'utilise depuis peu les suivants :

PIC18F2680 et PIC18F4680

Ils sont récents, ne comportent plus les bugs précédents, disposent de plus de mémoire et , d'un module CAN plus évolué mais compatible avec ceux des anciennes générations. De plus, ils sont disponibles en boitier DIP28broches et 40 broches ainsi qu'en CMS SOIC28 pour le 2680, ce qui permet de le souder convenablement à la main.

• Schéma d'exemple

• PARTIE LOGICIELLE

Vous avez deux méthodes de programmer les PIC pour gérer le bus CAN :

En Assembleur, c'est ainsi que j'ai commencé, grace aux cours de bigonoff auquels je vous renvoie si vous voulez programmer ainsi.

En C, il existe plusieurs compilateurs C, et certaines directives changent, je ne parlerai que du C18 de Microchip que vous trouverez gratuit à l'essai.

Microchip fournit dans une de ses Application Notes (AN738) une librairie en C pour utiliser facilement le module CAN des PIC 18Fxx8 . Les nouveaux modules CAN (appelés ECAN) sont code compatibles avec les anciens mais possèdent deux modes de fonctionnement (mode 1 et 2) qui ne seront donc pas utilisés car la librairie n'a pas été écrite pour. Cepandant, l'ancien mode de fonctionnement (mode 0) est plus facile à maitriser et on pourra facilement un jour, migrer.

On utilisera le mode de fonctionnement "mode 0 - Legacy mode" (voir datasheet section 23.4).

En plus du mode de fonctionnement (Functionnal Mode), il faut distinguer le mode d'opération (Opération Mode). Attention de ne pas les confondre.

• Les modes de fonctionnement

On distingue 5 modes de fonctionnement :

• Normal

Le mode normal est celui que l'on va utiliser

• Sleep

Permet une mise en veille ainsi qu'un réveil par interruption du PIC lors de réception de TRAME

• Loop

Les trames CAN envoyées sont directement recopiées dans le buffer de reception sans envoi sur le bus.

• Listen

Mode d'écoute seul

• Config

Au démarrage, le PIC est toujours en mode config (les pins dédiées au CAN CANTX et CANRX peuvent etres utilisées commes entrées-sorties standarts). C'est dans le mode config que l'on va initialiser le module CAN, en dehors de ce mode, on ne pourra pas changer certains registres par sécurité).

Il existe 2 fonctions dans la librairie pour changer le mode d'opération :

CANSetOperationMode et CANSetOperationModeNoWait.

Le changement de mode n'étant pas instantané (attente de la fin de l'envoi d'une trame par exemple), la première procédure ne rendra la main que lorsque le changement aura été effectué tandis que la seconde fera juste une demande de changement de mode d'opération.

 

• L'initialisation

Le bus CAN étant assez complexe, son initialisation est assez complexe.

Il existe une procédure pour initialiser le module CAN : CANInitialize Il vous vaudra cepandant savoir quoi fournir commes paramètres

La figure vous présente la composition d'un "Nominal Bit Time", il s'agit de l'inverse du débit choisi du bus CAN. Le module CAN dispose d'une unité élémentaire de temps : le Time Quantum. Sa valeur est déterminée par BRP et dépend de la vitesse du quartz. Voici la formule : Time Quantum = (2 * BRP )/Fosc

Le Nominal Bit Time est composé d'un segment de synchronisation qui va permettre aux différents noeuds CAN de se synchroniser sur l'emetteur. Il correspond à SJW (Synchronized Jump Width bits), vous pourrez choisir une valeur de 1 à 4 quantum de temps. La valeur typique étant 1.

Le Segment de propagation sert à tenir compte des temps de propagation sur le bus. Sa valeur peut être comprise entre 1 et 8 quantums de temps. Il est matérialisé par PROPSEG.

Calcul du temps de propagation :

C'est le temps que va mettre le signal électrique pour faire un aller et retour entre deux noeuds CAN les plus éloignés du bus. Soit :

T segment de propagation = 2 * ( T propagation sur bus + T retard Comparateurs + T retard drivers de ligne CAN)

Les deux autres segments qui composent un Nominal Bit Time sont les segments buffers phase 1 et phase 2. Ils servent essentiellement à compenser les erreurs de phase détectées lors des transitions. Ils vont déterminer la position du "Sample Point" pour la mesure.

L'ensemble de tous ces segments de propagation doit donner le temps de bit nominal qui vous donnera alors le bitrate.

 



• L'émission

Voir AN738 page 12 pour la description de la méthode d'envoi de trames CAN

L'émission d'une trame CAN est réalisée à l'aide de la commande : CANSendMessage

Les PICs disposent de 3 buffers d'émission, cette méthode va chercher 1 buffer libre pour émettre. Si elle n'en trouve pas, elle retournera la valeur false.

Noter que si vous envoyer 3 trames et qu'elles ne sont pas acquittées (c'est à dire qu'elles n'ont pas étés reçues par d'autres cartes) les 3 buffers vont rester pleins et vous ne pourrez plus envoyer.

La réception

La réception est plus complexe que l'émission, on dispose de deux buffers de réceptions ainsi que des filtres et masques pour chaque buffer. La configuration des filtres et masques va vous permettre de rediriger le type de trame selon son identifiant vers le buffer 1 ou le buffer 2. Le masque vous permet de sélectionner ce que vous voulez filtrer dans l'id. Bit à bit cela donne : Si le masque est à 0, on accepte quelque soit la valeur du filtre.Si le masque est à 1, on accepte que si le bit du filtre est identique au bit de la trame reçue.Voir AN738 page 10 et 11 pour les méthodes permettant de définir filtres et masques.

Le masque 1 et les filtres 1 et 2 correspondent au buffer 1. Le masque 2 et les filtres 3,4,5 et 6 correspondent au buffer 2.

La fonction CANReceiveMessage vous permet de récupérer le message CAN recu ainsi que de savoir par quel filtre il est passé, vous pourrez alors savoir de quel buffer il provient.

Il y a une erreur en haut de la page 14, la fonction ne retourne pas rien "void" mais retourne un booléen "BOOL" qui vaudra false s'il n'y a pas de nouveaux messages.

Noter la présence d'une fonction CANIsRxReady() qui permet de savoir si au moins une trame a été reçu.

La gestion des erreurs

La gestion des erreurs est un des points les plus complexes du bus CAN. Plusieurs types d'erreurs peuvent avoir lieu. Les controleurs CAN disposent de deux compteurs d'erreurs : Un pour les erreurs d'émission, et un pour les erreurs de réception. Ces compteurs ne sont pas de simples compteurs d'erreurs, ils vont s'incrémenter et de décrémenter automatiquement lors de l'émission/réception.

A partir de ces compteurs, le controleur CAN va passer dans différents modes de fonctionnement.actif, passif, et Off. Lorsqu'un noeud CAN a eu plus de 255 erreurs d'émission, il va passer en mode Bus Off, c'est à dire qu'il ne tentera plus d'émettre.

De 0 à 127 : Etat "error active". Le noeud CAN en question continuera d'émettre et de reçevoir normalement mais il indiquera son status d'"error active" aux autres noeuds si une autre erreur est détectée.

De 128 à 255 : Etat de "error passive". Le noeud CAN continuera d'émettre et de reçevoir mais il indiquera son status d'error passive à chaque trame d'erreur.

Plus de 255 : Etat de "Bus Off". Lassé de ne pouvoir émettre ou reçevoir, il va se mettre à bouder dans un coin afin de ne pas perturber le bon fonctionnement du bus.

Vous avez trois méthodes pour vérifier si le bus est off ou en état d'erreur passive :

CANIsBusTxPassive(), CANIsBusRxPassive(), et CANIsBusOff().

Comme vous pouvez le constater, la gestion des erreurs est très complexe! Il ne s'agit que d'une infime partie. Je ne connais d'ailleurs pas tout.

L'intéret de ce bus est que tout ce mécanisme de traitement des erreurs est géré automatiquement de manière hardware. On a donc juste à surveiller les erreurs dans le programme histoire de gérer les défauts comme mettre le système en sécurité.

La gestion des réceptions

Il existe deux méthodes pour gérer les réceptions de trames CAN, soit en testant en permanence l'état des buffers de réception par la commande CANIsRxReady() par exemple, soit en utilisant les interruptions.

L'avantage des interruptions de traiter très rapidement les trames recues avant l'arrivée d'une nouvelle. On peut par exemple se contenter dans la routine de réception de stocker les trames reçues dans un buffer puis de traiter ces trames dans le programme principal.

Les liens