CAN

Page précédente

PAGE EN CONSTRUCTION ..... __**Par Anicet DJADA, M13 ; Cours : systèmes embarqués**__ flat =**1. Le bus CAN: Généralités**=



**1.1 Introduction**
Le CAN (//Controller Area Network//) est un bus de communication de type série, développé à la fin des années 80, par l'entreprise allemande Robert Bosch. L'objectif était de fournir à l'industrie automobile une alternative aux nombreux câbles nécessaires pour interconnecter les équipements électroniques, sans cesse croissant des automobiles. Aujourd'hui, l'efficacité et la robustesse de ce protocole l'ont amené à être utilisé dans de nombreuses autres applications industrielles, en particulier celles nécessitant un débit important (jusqu'à 1 Mbits/s) avec un très faible taux d'erreur. //→ Sur base d'une électronique "intelligente" et bon marché, on a créé un système fiable et robuste.// Le CAN est aussi devenu un standard international reconnu par l'ISO. De nombreux contrôleurs CAN sont aujourd'hui disponibles chez la plupart des fabricants, qui proposent aussi des versions de leurs microcontrôleurs avec des contrôleurs CAN intégrés. De nombreux packages de développement existent également sur le marché.

Ce bus de classe C ( 125 kbit/s à 1 Mbit/s) est présent dans l'automobile avec deux débits distincts:
 * Le CAN High (250 kbit/s) répond à la demande de débit élevé entre organes de sécurité et le calculateur (Airbag, ABS...).
 * Le CAN Low (125 kbit/s) est utilisé pour les organes ne requérant pas un timing serré (rétroviseurs électriques, climatisation...).

__//Exemple d'utilisation://__ media type="youtube" key="EMbFVd2QOCA" height="480" width="640" align="center"

haut de page
 * 1.2 Principes et propriétés **

Le CAN est un bus série multi-maîtres, reliant un ensemble de nœuds (ECU/M: Electronic Control Unit/Module), qui communiquent entre eux en envoyant des paquets (messages). Les messages transmis par un nœud sur le bus ne contiennent aucune adresse. C'est plutôt le contenu du message; sa signification qui est précisée par un identificateur (ID). Chaque nœud recevant un message, regarde si celui-ci est intéressant pour lui (grâce à l'ID du message) et le traite le cas échéant. Cet ID unique, indique également la priorité des messages. Plus sa valeur est faible, plus le message sera prioritaire. Si deux nœuds ou plus veulent transmettre en même temps, c'est le nœud de plus haute priorité qui gagne. Les messages de priorité inférieure sont alors automatiquement retransmis lorsque le bus est libre. La priorité du message étant définie dans l'ID. La complexité d'un nœud peut aller d'une simple unité d'entrée sortie, à un ordinateur embarqué possédant une interface CAN et une suite logicielle complète. Il peut tout aussi bien s'agir d'une passerelle permettant à un ordinateur standard de communiquer via l'usb, le port ethernet (...), avec d'autres appareils du réseau CAN. - bus de données série half duplex (une seule paire différentielle pour envoie et réception; mais à des instants différents) - fonctionnement multi maîtres (pas de //Chip Select//, aucune adresse de destination) - Réception de multiples sources, avec synchronisation temporelle - Garantie des temps de latence - Détection et signalisation des erreurs - Retransmission automatique des messages altérés - Déconnexion automatique des nœuds défectueux: différence entre défectuosité temporaire et permanente - //Carrier sense (CS):// chaque nœud doit écouter le bus pendant une période avant de transmettre - //Multiple Acces (MA):// Si le bus est libre, tous les nœuds ont le même niveau de priorité pour envoyer un message - //Collision Detection/Resolution (CD/R):// si deux nœuds décident de transmettre au même moment, il y a collision. Pour résoudre ce problème, chaque nœud écoute donc après avoir transmis. Si le message écouté est différent de celui transmis, il le retransmet.
 * **En resumé:**
 * **Autres propriétés:**

Haut de page

**1.3 Modèle OSI**
Vu la diversité de leurs caractéristiques, une communication entre les systèmes serait impossible, si elle n'avait pas fait l'objet d'une normalisation rigoureuse. D'où la définition d'un modèle de structuration de protocole pour les systèmes ouverts, appelé OSI (Open Systems Interconnection) de l'ISO (International Organisation for Standadization).


 * La **couche physique** s'occupe de la transmission des bits de façon brute sur le canal; elle normalise donc les caractéristiques électriques (tension, codage, timing, synchronisation, ...) et le support de transmission (forme des connecteurs, topologie, ...).
 * La **couche liaison** assure le transfert d'informations, de manière fiable, entre deux entités connectées au même canal de communication. Pour y parvenir, les données devraient être structurées et une correction d'erreurs mise en place.
 * La **couche application** définit la signification à attribuer aux données reçues et les actions qu'elles doivent entraîner. Bien que le protocole CAN ne normalise pas cette couche, il existe une couche applicative très répandue, qui vaut le détour: le CAN OPEN.

Haut de page =**2. Le bus CAN: couche physique**=

Il existe deux normes pour la couche physique: > La limitation du nombre total de nœuds tient compte des retards de propagation sur la ligne et des valeurs de charges électriques que ces derniers présentent sur le bus. La longueur maximale de la ligne dépend quant à elle, du débit utilisé pour la transmission.
 * Le CAN "low speed, fault tolerant"
 * De 0 kbps à 125 kbps
 * Nombre de nœuds limité à 20
 * ISO 11898-3 en 2006, anciennement ISO 11519-2 en 1994
 * Le CAN "high speed"
 * De 125 kbps à 1 Mbps
 * Nombre de nœuds limité à 30
 * ISO 11898-2 en 2003

Haut de page

**2.1 Connecteur**
Le connecteur normalisé pour une communication via le bus CAN est le DB9 (anciennement DE-9). Le protocole CAN décrit un transport sur paire torsadée; de manière non restrictive : on peu très bien envisager une liaison infrarouge, par fibre optique, Bluetooth, WIFI, etc.



Haut de page

**2.2 Encodage des bits**
Le codage utilisé est de type NRZ (non retour à zéro). Les bits 0 et 1 représentent des états significatifs (de tension), sans état intermédiaire.
 * __Avantage:__ facilité de mise en œuvre[[image:Image2NRZ.png width="264" height="68" align="right"]]
 * __Inconvénients:__
 * une inversion de fils provoquerait une erreur d'interprétation
 * problème de synchronisation lors de longues séquences 0 ou 1

Pour résoudre ce probable problème de synchronisation, la norme CAN utilise un "bit-stuffing" ou bit de transparence. Après une suite consécutive de **cinq** 0 ou 1, on ajoute un bit de valeur opposée. Pour un fonctionnement correct de tout le réseau, cette technique doit être implémentée aussi bien en émission qu'en réception. On parlera de la trame CAN dans le chapitre suivant, mais notons déjà que le "bit-stuffing" ne s'applique pas à tous les champs. Haut de page

**2.3 Niveaux électriques**
Les nœuds sont câblés sur le bus par le principe du "OU câblé", d'un point de vue électrique ("ET " logique), ce qui veut dire qu"en cas d'émission simultanée de deux nœuds, la valeur 0 écrase la valeur 1. On parle donc d':
 * état dominant pour l'état logique 0
 * état récessif pour l'état logique 1

Haut de page

2.4 Temps et vitesse
La durée d'un bit sur le bus est appelée **//Nominal Bit Time//** __Composition__:
 * **//Segment de synchronisation//**: assure la synchronisation des différents nœuds du bus; par une transition 0 -> 1 ou 1 ->0
 * **//Segment de propagation//**: sert à compenser les retards dû à la propagation du signal sur la ligne. Semblable au paramètre TA (Time Advance, en GSM)
 * **//Segments buffer phase 1 et phase 2//**: servent à compenser les erreurs de phases détectées lors des transitions
 * **Sample point (point d'échantillonnage):** lieu où le nœud lit la valeur du bit sur la ligne

Le **//Time Quantum//** est l'unité de temps, construite à partir de l'oscillateur interne de chaque nœud. La fréquence du bus étant de 1 MHz (débit de 1 Mbps) au maximum, et celle des nœuds de plusieurs MHz, le "//time quantum//" vaut généralement plusieurs périodes d'horloge (de 1 à 32 fois). Le nombre de //time quantum// dans un //nominal bit time//, peut valoir de 4 à 25. Un nombre important de //time quantum// par segment, augmente la précision de la synchronisation des différents nœuds sur le bus. Haut de page =**3. Le bus CAN: couche liaison de données**=

Il existe également deux standards pour la couche de liaison:

 * ISO 11898 part A → CAN 2.0A «standard frame format» (identification sur 11 bits)
 * ISO 11898 part B → CAN 2.0B «extended frame format» (identification sur 29 bits)

Les contrôleurs CAN admettant le format étendu sont compatibles avec le format standard. On distingue: Il existe une période dite «//intertrame//» (entre deux trames),équivalente à la durée de trois bits. Pendant laquelle les émetteurs doivent maintenir le bus à l'état récessif. Haut de page
 * trames de données
 * trame de requête
 * trame d'erreur
 * trame de surcharge

**3.1 Trame de données**
La trame de données sert à envoyer des informations aux autres nœuds du bus CAN. Elle se décompose en sept champs différents: Les champs sont transmis dans l'ordre précédent (du SOF à EOF), et les bits y sont transmis du poids le plus fort au plus faible.
 * Le début de trame SOF (Start Of Frame), 1 bit dominant
 * champ d'arbitrage, 12 bits
 * champ de commande ou de contrôle, 6 bits
 * champs de données, 0 à 64 bits
 * champ de CRC (Cycle Redundancy Code), 16 bits
 * champ d'acquittement ACK (ACKnowledge), 2 bits
 * Champ de fin de trame EOF (End Of frame), 7 bits récessifs

Ce champ correspond à l'ID dont nous faisions allusion au §1.2.

Chaque nœud émet et écoute, si la valeur lue est différente de celle émise, il sait alors qu'il a perdu l'arbitrage.

- Le bit RTR (Remote Trame Request): détermine s'il s'agit d'une trame de données (RTR est dominant -0-) ou d'une trame de requête (RTR est récessif-1-) - Les 7 bits les plus significatifs ne doivent pas être tous récessifs - Pour des raisons de compatibilité avec les anciens circuits, les 4 derniers bits de l'ID (ID3:0) ne sont pas utilisés, ce qui réduit le nombre de combinaisons possibles. - Le bit SRE est un bit récessif transmis à la place du RTR du format standard. - Le IDE fait la distinction entre format standard (état dominant) et format étendu (état récessif): assure la rétrocompatibilité du format étendu avec le standard.
 * **Format standard CAN 2.0A → ID + bit RTR**
 * **Format étendu CAN 2.0B → ID + SRE + IDE + RTR**



3.1.2 Champ de commande (control field)

 * Composé de 6 bits
 * r1 et r0 sont des bits de réserve, qui assureront une compatibilité ascendante (avec le format étendu par exemple).
 * Les quatres derniers bits permettent de déterminer le nombre d'octets (de données) contenues dans le champ de données, pour une trame de données. Ou bien le nombre d'octets de données dont le nœud a besoin, pour une trame de requête.
 * Le nombre d'octets de données ne peut excéder huit.

3.1.3 Champ de données

 * Longueur allant de 0 à 64 bits (8 octets) : la longueur de ce champ a été évaluée lors de l'analyse du champ de contrôle.
 * Dans le cas d'une trame de requête, le champ de données est vide.

3.1.4 Champ de CRC
La séquence de CRC permet de vérifier l'intégrité des données transmises. Elle est codée sur 15 bits + CRC delimiter (toujours 1 bit récessif). Si la séquence de CRC calculée par le nœud, diffère de celle du nœud émetteur : il y a erreur (... de CRC). Les bits utilisés dans le calcul du CRC sont ceux du SOF, des champs d'arbitrage, de données et de contrôle.

__La séquence de CRC est calculée de la façon suivante:__
 * L'ensemble des bits (hors bit de stuffing) reçus depuis le SOF jusqu'à la fin de la trame de données (pour une trame de données), ou bien la fin du champ de contrôle (pour une trame de requête). Est interprété comme un polynôme f(x) avec des coefficients 0 ou 1; affectés à la présence effective ou non, de chaque bit. Le polynôme est ensuite multiplié par x^15, complété par l'ajout du mot de CRC.
 * Le polynôme ainsi formé est divisé (modulo 2), par le polynôme générateur g(x)=x^15+x^14+x^10+x^8+x^7+x^4+x^3+x^1. La chaîne de bits correspondante à ce polynôme est 1100010110011001.
 * Le reste de la division de f(x) par le polynôme générateur, constitue la séquence de CRC.



La réalisation du module de calculs de CRC est aisée à l'aide de registres à décalage. La norme BOSCH propose le programme informatique correspondant à l'algorithme précédent: code format="c" CRC_REG=0 ; REPEAT CRC_NXT_BIT=(NXT_BIT) XOR (CRC_REG(14)) ; CRC_REG(14:1)=CRC_REG(13:0) ; CRC_REG(0)=0 ; IF CRC_NXT_BIT THEN CRC_REG(14:0)=CRC_REG(14:0) XOR (4599hex) ; ENDIF UNTIL(CRC SEQUENCE starts or there is an ERROR condition) code

3.1.5 Champ d'acquittement
L'acquittement d'une donnée est une opération consistant à informer son émetteur, de sa bonne réception. Dans protocole CAN, le champ ACK possède deux bits: //l'ACK slot// et //l'ACK delimiter// (1 bit récessif).
 * Le premier correspond à l'acquittement par l'ensemble des nœuds ayant reçu le message. Après calcul du CRC, le nœud émet une trame d'erreur, si une erreur a été détectée; un bit dominant si non. L'émetteur réagira donc selon qu'on lui renvoie une trame d'erreur ou un bit dominant.
 * Le second bit est un délimiteur d'acquittement, qui est toujours un bit récessif.



3.1.6 Champ de fin de trame EOF (End Of Trame)
Chaque trame de donnée et de contrôle se termine par un champ de //fin de trame// ; c'est une séquence de 7 bits récessifs. Ces bits dérogent à la règle du //bit-stuffing//. Haut de page

**3.2 Trame de requête**
La trame de requête est semblable à la trame de données, à la différence que: Un nœud ayant besoin de données, va donc émettre une trame de requête dès que le bus est libre, en prenant soin d'indiquer le nombre d'octets de donnés dont il a besoin; dans le champ de contrôle
 * Le champ de données est vide
 * Le bit de RTR est récessif (dominant pour une trame de données): la conséquence est que si deux nœuds émettent chacun une trame contenant le même identificateur (une trame de donnée et une trame de requête), l'arbitrage sur le bit de RTR (dominant) donnera la priorité à la trame de donnée.

Haut de page

**3.3 Trame d'erreur**
Le CAN implémente cinq mécanismes de gestion d'erreurs:
 * 2 au niveau des bits: bit monitoring et bit-stuffing.
 * 3 au niveau des messages: vérification du CRC, de la structure des trames et l'acquittement.

La probabilité d'erreur est inférieure à 4,6*10^-11. Ce qui reste une particularité est également le fait que tous les nœuds écoutent et signalent les erreurs; même ceux qui ne sont pas intéressés par les messages ! Le système gère donc automatiquement les conflits et erreurs, en émettant des trames d'erreur. Il fait la différence entre disfonctionnements temporaires et défauts permanents. Et déconnecte automatiquement les nœuds en défaut permanent.

Signale que le bit envoyé est différent de celui reçu; fait suite à un monitoring du bus. Si un nœud détecte une séquence de 6 bits dominants ou récessifs, dans une partie du message admettant la méthode de bit-stuffing. Signale que le CRC calculé par le nœud diffère de celui contenu dans la trame de donnée. Signale qu'un bit qui devrait être à un certain niveau (dominant ou récessif) ne l'est pas. Exemple: Si les bit «CRC delimiter» ou «ACK delimiter» lus par les nœuds récepteurs ne sont pas récessif, c'est qu'ils sont altérés.
 * 3.3.1 Types d'erreurs**
 * **Erreur de bit**
 * **stuff error**
 * **CRC error**
 * **Form error**

Si aucun bit dominant n'est reçu pendant 'ACK slot.
 * **ACK error**

Ci-dessous, les différents types d'erreurs et leur validité suivant l'endroit où l'on se trouve.

Haut de page

3.3.2 Trames d'erreurs
La trame d'erreur est constituée de champs principaux:
 * **La trame d'erreur**[[image:isil-electro/trame erreur.png width="412" height="115" align="right"]]
 * Le drapeau d'erreur
 * Le délimiteur de champs

Le champ des drapeaux peut être constitué de deux sortes de drapeaux: Les trames d'erreur diffèrent selon le type de drapeaux qu'elles contiennent. Elle est constituée de six bits dominants consécutifs pour le champ de drapeau, suivis de huit bits récessifs pour le délimiteur. Elle brise donc la règle du bit-stuffing. Les autres récepteurs vont se mettre à émettre des trames d'erreur active (s'ils sont en mode d'erreur active), à la fin de la première station ayant émis la trame d'erreur active. La dernière station aura la charge d'émettre le champ d'//Error delimiter//; les autres champs étant remplacés par les bits dominants des drapeaux émis. __Remarque__: La norme limite le nombre de bits dominants consécutifs à 12.
 * Les drapeaux d'erreur active (active error flag)
 * Les drapeaux d'erreur passive (passive error flag)
 * **La trame d'erreur active:**

La trame est constituée de de six bits récessifs pour le drapeaux, suivis de huit autres bits récessifs pour le délimiteur. Et brise de nouveau la règle du bit-stuffing. Les récepteurs envoient à tour de rôle le //Passive error flag (//s'ils sont en mode d'erreur passive//).//Mais une trame d'active error flag reste prioritaire, en cas d'envoie simultané. La fin de trame quant à elle ne change pas, vu qu'elle est formée de huit bits récessifs, dans les deux cas.
 * **La trame d'erreur passive**


 * 3.3.3 Recouvrement d'erreurs**

Le recouvrement des erreurs est assuré par la retransmission automatique de la trame incriminée jusqu'à ce que l’émission de cette trame s’effectue sans erreur. La validité du message est acquise s’il n’y a aucune erreur depuis le SOF (//start Of Frame//) jusqu'à la fin de trame. Si l’émetteur n’arrive pas à émettre sa trame correctement, il essaye de nouveau de l’émettre jusqu'à ce que son compteur d’erreur passe en mode d’erreur passive.


 * 3.3.4 Modes et compteurs d'erreurs**

Deux compteurs mémorisent le nombre d’erreurs: Lorsque le nombre d’erreurs devient trop important on peut changer de mode d'erreur ou déconnecter le nœud. Le passage dans les différents modes s’effectue suivant la valeur des compteurs. <span style="font-family: Arial,Helvetica,sans-serif;">Le compteur s’incrémente plus vite lorsqu'il y a une erreur qu’il ne se décrémente lorsque la trame reçue est correcte.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Transmit Error Counter, pour l’émission (TEC)
 * <span style="font-family: Arial,Helvetica,sans-serif;">Receive Error Counter, pour la réception (REC)



Haut de page
 * **Mode d'erreur active**: si TEC | REC < 127 --> le compteur transmet un Active Error Flag, s'il détecte une condition d'erreur.
 * <span style="font-family: Arial,Helvetica,sans-serif;">**Mode d'erreur passive**: si 128 < TEC | REC < 255 -->passive error flag; ce mode indique que le nœud est défectueux.
 * <span style="font-family: Arial,Helvetica,sans-serif;">**Mode bus off**: si TEC | REC > 255 --> Le nœud est totalement déconnecté du bus.

**3.4.1 Trame de surcharge**
<span style="font-family: Arial,Helvetica,sans-serif;">La trame de surcharge indique aux autres noeuds qu’une station est surchargée. Elle est formée de deux champs : <span style="font-family: Arial,Helvetica,sans-serif;">Une trame de surcharge est émise sur le bus si : <span style="font-family: Arial,Helvetica,sans-serif;">Dès qu’une trame de surcharge est émise, les autres noeuds voient sur le bus une suite de six bits dominants qui ne respectent pas la règle du Bit-Stuffing. Ils émettent à leur tour une trame de surcharge. Seulement deux trames de surcharges consécutives sont autorisées sur le bus (pas plus de 12 bits dominants consécutifs émis sur le bus).
 * <span style="font-family: Arial,Helvetica,sans-serif;">le drapeau de surcharge (//Overload Frame//) avec six bits dominants,
 * <span style="font-family: Arial,Helvetica,sans-serif;">le délimiteur de surcharge (//Overload Delimiter//) avec huit bits récessifs.
 * <span style="font-family: Arial,Helvetica,sans-serif;">un bit dominant est détecté durant la période d’intertrame.
 * <span style="font-family: Arial,Helvetica,sans-serif;">un récepteur n’est pas prêt pour la réception d’une nouvelle trame de donnée ou de requête (retard sur le traitement des informations circulant sur le bus).

**3.4.2 Période d'intertrame**
<span style="font-family: Arial,Helvetica,sans-serif;">Sépare les trames de données ou de requêtes entre elles. Il s’agit d’une suite de plusieurs bits récessifs.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Le champ d’intermission est une suite de 3 bits récessifs consécutifs. Durant la période d’intermission, l’émission de trame n’est pas autorisée. Les gestionnaires de protocole ne sont autorisés à signaler que les conditions de surcharge.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Le champ de suspension de transmission est émis par un noeud lorsque celui-ci envoie une trame d’erreur passive.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Le champ de //Bus Idle// est celui du bus quand il est au repos. Le niveau de repos est le niveau récessif et aucune trame ne circule sur le bus.

<span style="font-family: Arial,Helvetica,sans-serif;">3.4.3 Autres modes
<span style="font-family: Arial,Helvetica,sans-serif;">Pour la gestion de l’énergie sur le bus, les drivers de ligne peuvent être désactivés lorsqu'il n’y a plus de trames sur le bus. <span style="font-family: Arial,Helvetica,sans-serif;">Pour activer ces drivers sur le bus, la station devra observer 11 bits récessifs consécutifs. La procédure ainsi décrite est la procédure de réveil appelée //Wake-up//. Un identificateur a été réservé à cette fonction pour éviter de perdre un trop grand nombre de trames lors de la reconnexion sur le bus. <span style="font-family: Arial,Helvetica,sans-serif;">Lors des démarrages d’une station sur le bus, le //Start-up// se charge de connecter les drivers de lignes et d’observer la séquence voulue pour commencer à émettre ou à recevoir des trames du bus.

Haut de page =**4. Le bus CAN: couche applicative CAN OPEN**=

=
La couche application CANopen a été développée par un groupe d'industriels réunis au sein de la fondation CiA (CAN in Automation). Elle a la particularité de supporter les systèmes temps réels. Programmation d'objets sous le modèle producteurs - consommateurs.====== CANopen est une solution difficile à mettre en œuvre, mais reste très fiable et de nombreuses bibliothèques existent en C; assurant l'inter portabilité.

Tout appareil CANopen, se doit d'implémenter certaines fonctionnalités standards dans son logiciel de contrôle.
 * L'**unité de communication** implémente les protocoles de messagerie avec les autres nœuds du réseau
 * Le démarrage et la réinitialisation de l'appareil sont contrôlés par une **machine d'état**. Cette dernière doit contenir les états initialisation, pré-opérationnelle, opérationnelle et stoppée.
 * Le **dictionnaire d'objets** est un tableau de variables avec un indice de 16 bits et admettant des sous-indices de 8 bits.
 * La **partie application** du dispositif assure effectivement la fonction désirée par l'appareil, après que la machine d'état ait été définie sur l'état de fonctionnement.

**4.1 Les dictionnaires d'objets**
<span style="font-family: Arial,Helvetica,sans-serif;">Le dictionnaire d'objets définit, pour chacune des entrées/sorties d'un périphérique CANopen(noeud), l'information sur le format de la donnée ainsi que sur le moyen d'y accéder. Il est donc utilisé pour la configuration et la communication avec l'appareil. <span style="font-family: Arial,Helvetica,sans-serif;">Chaque entrée du dictionnaire possède un index unique ainsi qu'une liste de sous-index.On accède à un objet grâce au couple [index, sous-index]. Ce dictionnaire d'objet est matérialisé par un fichier EDS(Electronic Data Sheet) à partir duquel il est possible de créer un fichier DCF(DeviceConfiguration File) qui définit la configuration d’un nœud: EDS =Classe et DCF = Instance de Classe. Une entrée dans le dictionnaire d'index est définie par:
 * **indice**: adresse de 16 bits de l'objet dans le dictionnaire
 * **nom de l'objet**: un type symbolique de l'entrée du dictionnaire, tel un tableau, un enregistrement ou une simple variable
 * **nom**: une chaîne de caractère décrivant l'entrée
 * **type**: donne le type de donnée de la variable (ou le type de données de toutes les variables d'un tableau)
 * **attribut**: donne des informations sur les droits d'accès pour une entrée; read, write ou read/write
 * Le **champ Obligatoire/facultatif (M/O)**: définit si un appareil conforme à la spécification du périphérique doit implémenter cet objet ou pas

4.2 Protocoles de communication

Le CANopen offre quatre possibilités d'accéder aux données du dictionnaire d'objets:
 * NMT (Network Management) / administration du réseau: démarrage du bus, affectation des identifiants, paramétrage et surveillance.
 * PDO (Process data objects): transmission rapide des données de procès lorsqu'elles sont inférieures ou égales à 8 octets.
 * SDO (Service Data Objet): Transmission des données de paramétrages par segmentation (lorsqu'elles sont supérieures à 8 octets) et sans contraintes de temps
 * SFO (Special Function Object): messages prédéfinis pour gérer les synchronisations, références temporelles, erreurs fatales. (Synchronization Object, Time stamp Object, EMCY Object)
 * Le node guardian (entendu gardien de nœud): fonctionne suivant le concept de maître-esclave (polling) et permet au manager du bus, de demander (remote request) l'état de chaque station à une période définie par configuration.
 * Le heartbeat: fonctionne suivant le concept de producteur - consommateur. L'état de la station est produit cycliquement à une période définie par configuration. Ce mécanisme nouvellement spécifié, remplace le node guardian sur les nouveaux appareils (meilleur usage de la bande passante).

Haut de page =**5. Aspect matériel de l'AT90CAN32**=

L'AT90CAN32 est un microcontrôleur 8 bits à architecture RISC, fabriqué par ATmel et **embarquant un contrôleur CAN**. Il dispose également : Mais nous ne nous attarderons que sur son contrôleur CAN.
 * Interface JTAG
 * 2 Timer/count (0,2) sur 8 bits et 1 timer/count 1 su 16 bits. Avec prédiviseur de 10 bits
 * Comparateur analogique
 * ADC sur 10 bits
 * Interruptions internes et externes
 * U(S)ART, SPI

5.1 Caractéristiques du contrôleur CAN
Le contrôleur CAN intégré à l'AT90CAN32, embarque tout le matériel nécessaire à une gestion efficace des trames CAN. Pour chaque message transmis ou reçu, ce module contient un message objet à appeler; dans lequel sont stockées toutes les informations attenantes au message: identificateur, champ de données, etc... Lors de l'initialisation du périphérique, l'application définit quels messages doivent être envoyés et lesquels doivent être reçus. Si le contrôleur CAN reçoit un message correspondant à l'un des messages configurés au niveau des Mobs, l'interruption correspondante va se produire. Ceci se fait donc de façon automatique et transparente, ce qui a pour avantage de libérer la charge du CPU, par rapport à une solution CAN de base (sans contrôleur CAN). On augmente ainsi le nombre de messages pouvant êtres traités.

Le débit du bus CAN est 1Mbit/s maximum, pour une fréquence d'horloge de 8MHz et le contrôleur embarqué dispose de 15 Mobs à programmer. La priorité dans l'exécution est donnée aux messages objets de niveaux les plus bas.

Haut de page

**5.2 Canal CAN**
Il peut être configuré de trois façons différentes: Haut de page
 * **Mode actif** (//enabled//)
 * TxCAN et RxCAN sont activés
 * L'entrée du signal d'horloge est connectée
 * **Mode veille** //(standby)//
 * L'émetteur fournit en permanence un niveau récessif (sur TxCAN interne)
 * Récepteur désactivé (RxCAN désactivé)
 * L'entrée du signal d'horloge est active
 * Les registres et les pages restent accessibles
 * **Mode écoute** //(listening//): transparent pour le canal[[image:Ashampoo_Snap_2014.10.28_22h07m47s_007_.png width="375" height="132" align="right"]]
 * permet un feedback interne de TxCAN sur RxCAN
 * Fournit un niveau récessif sur la broche de sortie TxCAN
 * Ne désactive pas la broche d'entrée RxCAN
 * fige les compteurs d'erreur TEC et REC

5.3 CAN timer
Un compteur 16 bits programmable est utilisé pour prendre une empreinte (capture) du message et déclencher la communication (TTC: Time Trigger Communication)


 * prédiviseur: un diviseur de 8 bits est initialisé par le registre CANTCON, il reçoit la fréquence clkIO et en fournit clk CANTIM = clkIO/8. Si le contrôleur CAN est activé (ENFG = 1)
 * compteur 16 bits: il compte de 0x0000 --> 0xFFFF --> 0x0000 et lève une interruption OVRTIM
 * Temps de déclenchement: deux modes de déclenchement sont implémentés pour TTC (bit TTC); en mode TTC,la trame est envoyée une seule fois. Même si une interruption survient
 * synchronisation sur début de trame (SYNCTTC = 0)
 * synchronisation sur fin de trame (SYNCTTC = 1)
 * Message d'estampage: La capture de la valeur du compteur s'effectue dans le Mob qui envoi (reçoit) la trame; sur TxOk (RxOK)

Haut de page

5.4 Gestion des erreurs
Le contrôleur CAN prend en charge les trois modes d'erreur: //BOFF peut générer une interruption//
 * **active** (par défaut): il prend part à la communication et peut envoyer une trame d'erreur active, lorsque la macro associée détecte une erreur.
 * **passive**: une trame d'erreur passive est envoyée au besoin; après une transmission, l'unité d'erreur passive doit attendre avant d'initialiser une nouvelle transmission
 * **bus off**: le canal n'est pas autorisé à avoir une quelconque influence sur le bus

Les types d'erreur sont (cf. §):
 * BERR: bit error
 * SERR: stuff error
 * CERR: CRC error
 * FERR: forme error
 * AERR: ACK error (Tx uniquement)

Haut de page

5.5 Interruptions
Les différentes interruptions sont les suivantes: Le bit ENIT autorise les interruptions globales et ENOVRT autorise celle sur le débordement du compteur CAN
 * INT lorsque réception complète
 * INT lorsque transmission complète
 * INT lorsque erreur (BERR, SERR, CERR, FERR, AERR)
 * INT lorsque la mémoire tampon de trame est pleine
 * INT BOFF lorsque le bus est mis off
 * INT lorsque le compteur CAN déborde

__**Ordonnancement:**__

Lorsqu'une interruption se produit, un indicateur d'interruption est activé dans le registre Mob-CANSTMOB ou le registre général CANGIT correspondant. Si les bits ENRX, ENTX et ENERR du registre CANIE sont à 1, alors le bit Mob correspondant du registre CANSITn est activé. Pour acquitter une interruption de Mob, le bit correspondant (RXOK, TXOK, ...) du registre CANSTMOB doit être effacé (en écrivant 1 dedans) de façon logicielle. De la même façon, il faudra effacer le bit correspondant (BXOK, BOF-FIT, ...) du registre CANGIT; pour acquitter une interruption générale. OVRTIM est réinitialisé de la même façon. Si un nœud en cours de transmission détecte une erreur de forme dans sa trame, une erreur de bit sera également levée. Par conséquent, deux interruptions consécutives peuvent être levées; toutes deux dues à la même erreur. Lorsqu'une erreur de Mob apparaît et est indiquée dans le bit correspondant du registre CANSTMOB, aucune erreur générale n'est signalée dans le registre CANGIT.

Haut de page

5.6.1 Registre général de contrôle - CANGCON
Lorsque ce bit est mis à 1, une réinitialisation (mise à 0) de CANEN1 et CANEN2 est faite. Les communications en attentes sont immédiatement désactivés, et celles en cours ; normalement terminées. le registre CANCDMOB reste inchangé Lorsque ce bit est mis à 1, le contrôleur envoie une trame de surcharge sur le bus, dès réception de la trame suivante. Utile en mode TTC uniquement, ce bit lorsqu'il est à 0, le TTC timer est pris sur le SOF (start of frame) et sur le dernier bit du EOF (End Of Frame); lorsqu'il est à 1. Ce bit utilisé par le fabricant pour effectuer des tests, n'est pas destiné à l'utilisateur final ! Si ce bit est à 1, il se peut donc que le bus fonctionne mal. Puisque ce bit est une commande, qui peut ne pas être immédiatement effective. Le bit ENFG du registre CANGSTA, donne l'état réel du mode choisi.
 * **BIT 7 - ABRQ : Abort Request → Abandonner la demande**
 * **BIT 6 - OVRQ : Overload Frame request**** → Demande de trame de surcharge **
 * **BIT 5 - TTC : Timer Trigger Communication → Timer enclenche la communication**
 * BIT 4 - SYNTTC : synchronization of TTC
 * **BIT 3 - LISTEN : Lstenig mode → Mode écoute**
 * **BIT 2 - TEST : Test Mode** ** → Mode de test **
 * **BIT 1 - ENA/!(STB) : Enable/Standby mode → mode actif / veille**
 * **0 - Standby mode**: S'il y a une transmission en cours, elle est normalement terminée et le canal CAN est figé (les bits CONMOB de tous les MOb restent inchangés). Le transmetteur fournit constamment un niveau récessif. Le récepteur est inactif, mais tous les registres restes accessibles par le µC.
 * **1 - Enable mode**: Le canal CAN entre dns le mode actif dès qu'une séquence de 11 bits récessif est lue sur le bus.
 * **BIT 0 - SWRES : Software Reset Request → reset logiciel du contrôleur CAN**

5.6.2 Registre général de statuts - CANGSTA
__//Seul le BIT 1 (BOFF) génère une interruption (BOFFIT)//__ Ce bit est mis à 1 durant la transmission d'une trame de surcharge. Ce bit est à 1 durant la transmission de toute trame autre que la trame de surcharge; même durant l’inter trame. Ce bit est à 1 lors de la réception de n'importe qu'elle trame. Indique l'état effectif du contrôleur CAN. Cf. BIT 1 du registre CANGCON (§ 5.6.1).
 * **BIT 7, 5 : Réservés**
 * **BIT 6 - OVRG: Overload Frame Flag**
 * **BIT 4 - TXBSY: Transmitter busy**
 * **BIT 3 - RXBSY : Receiver busy**
 * ** BIT 2 - ENFG : Enable Flag **
 * **BIT 1 - BOFF : Bus Off mode** ** → ** entrée en mode Bus OFF, suite à une défectuosité permanente du nœud
 * **BIT 0 - ERRP : Error Passive Mode** ** → **entrée en mode d'erreur passive

5.6.3 Registre général d'interruption - CANGIT
//__Il faut écrire un 1 dans les bits R/W pour les réinitialiser !!!__// > **BIT 0 - AERG : ACK Error General** ** → **le bit dominant de l'ACK slot ne correspond pas.
 * **BIT 7 - CANIT : General interrupt flag** ** → **fournit un ou logique de toutes les interruptions du contrôleur CAN; excepté l'OVRTIM.
 * **BIT 6 - BOFFIT: Bus Off interrupt** ** → **indique l'entrée en mode bus off, au départ du mode d'erreur passive.
 * **BIT 5 - OVRTIM : Overrun CAN Timer** ** → **indique le débordement (0xFFFF à 0) du Timer CAN. L'ISR correspondante reset ce bit
 * **BIT 4 - BXOK: Frame buffer Receive Interrupt** ** → **indique qu'une reception est complète. Ce bit ne pourra être réinitialisé que si, tous les champs CANMOB du buffer des MOb été ré-écrits au préalable.
 * **BIT 3 - SERG: Stuff Error General** ** → **indique une erreur de stuffing. Plus de 5 bits consécutifs ayant la même polarité !
 * **BIT 2 - CERG: CRC Error General** ** → **erreur de CRC: Le CRC calculé par le contrôleur diffère du champ CRC du message.
 * **BIT 1 - FERG : Form Error General** ** → **erreur de forme: CRC delimiter, ACK delimiter ou EOF ne sont pas récessifs.

5.6.4 Registre général d'autorisation d'interruptions - CANGIE

 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; line-height: 1.5;">**BIT 7 – ENIT** : Enable all Interrupts (Excepté l'interruption sur le débordement du compteur)
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; line-height: 1.5;">**BIT 6 – ENBOFF** : Enable Bus Off Interrupt
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; line-height: 1.5;">**BIT 5 – ENRX** : Enable Receive Interrupt
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; line-height: 1.5;">**BIT 4 – ENTX** : Enable Transmit Interrupt
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; line-height: 1.5;">**BIT 3 – ENERR** : Enable MOb Errors Interrupt
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; line-height: 1.5;">**BIT 2 – ENBX** : Enable Frame Buffer Interrupt
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; line-height: 1.5;">**BIT 1 – ENERG** : Enable General Errors Interrupt
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 13px; line-height: 1.5;">**BIT 0 – ENOVRT** : Enable CAN Timer Overrun Interrupt

5.6.5 Registres d'activation de Mob - CANEN2 & CANEN1

 * **0 - MOb desable:** indique que le message objet n'est pas en cours d'utilisation et est disponible pour une nouvelle transmission ou réception.
 * **1 - MOb enable:** MOb est en cours d'utilisation.

5.6.6 Registre d'activation d'interruptions sur les MOb - CANIE2 & CANIE1
Active ou désactive les interruptions sur les MOb. __Exemple:__ CANIE2 = 0000 1100b : active les interruptions sur les MOb 2 & 3

5.6.7 Régistre de statu des interruptions sur les MOb - CANSIT2 & CANSIT1
__Exemple__: CANSIT2 = 0010 0001b : MOb 0 & 5 interrupts
 * Signale s'il y a eu une interruption sur un MOb.

5.6.8 Régistre de contrôle du timer - CANTCON

 * BIT 7:0 - Prédiviseur pour l'horloge du timer: 8 bits ** → 0 à 255. **

media type="custom" key="26776642" align="center"

5.6.9 Registres du timer - CANTIML & CANTIMH


BIT 15:0 - compteur 16 bits; plage de 0 à 65535

5.6.10 Registre du timer en mode TTC - CANTTCL & CANTTCH


Même fonction que précédemment, mais lorsque le timer est utilisé en mode TTC (Timer Trigger communication).

5.6.11 Registre TEC - CANTEC
BIT 7:0 - TEC7:0 Bits du compteur d'erreurs TEC. Plage de 0 à 255

5.6.12 Registre REC - CANREC
BIT 7:0 - REC7:0 Bits du compteur d'erreurs REC. Plage de 0 à 255

5.6.13 Registre des MOb de plus haute priorité - CANHPMOB


=**6. Mise en œuvre du shield CAN-bus de sparkfun**=

media type="youtube" key="YKt5WssB4D8" height="390" width="640" align="center"

Le nœud d'émission (S) envoie à celui de réception (R) un message contenant les informations sur la vitesse du moteur et son sens de rotation. Le joystick du nœud S sert à la commande.

**7. Références:**

Dominique PARET. Le bus CAN controller Area Network. 1997 BOSCH. Norme CAN Datasheet AT90CAN32 (lien) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ PDF ] Le bus CAN, Patrice KADIONIK ( de ENSEIRB) CAN bus wikipedia fr | CANopen wikipedia fr CAN bus wikipedia en | CANopen wikipedia en

Page précédente. Haut de page