3.25. Notions de base du bus CAN

Le bus CAN (Controller Area Network) a été conçu à l’origine par Bosch dans les années 1980 pour relier tous les calculateurs électroniques d’une voiture sur un seul bus court et partagé. Il domine toujours le faisceau de câbles automobile, mais sa robustesse, son comportement temps réel et son architecture multi-maître en font également le bus de terrain par défaut dans l’automatisation, la robotique, le matériel agricole et les équipements industriels de toutes sortes.

Le CAN ne possède pas un unique « contrôleur » et un ensemble de « périphériques » comme le font le SPI et l’I2C. Chaque nœud du bus est un pair, et n’importe quel nœud peut émettre dès que le bus est inactif. Ce qui permet à ce modèle de passer à l’échelle, c’est la conception du bus fondée sur la diffusion avec arbitrage.

3.25.1. Diffusion avec arbitrage par priorité

Chaque message sur un bus CAN porte un identifiant – 11 bits pour la trame standard classique, 29 bits pour la variante étendue. L’identifiant n’est pas une adresse ; il indique ce dont le message traite (régime moteur, position de la pédale de frein, tension de la batterie, etc.). Lorsqu’un nœud veut envoyer une valeur, il la diffuse en l’étiquetant avec l’identifiant approprié, et chaque nœud du bus voit la diffusion. Chaque récepteur filtre le bus de manière matérielle pour ne retenir que les ID qui l’intéressent.

Si deux nœuds tentent d’émettre en même temps, la conception électrique du bus fait gagner le message dont l’identifiant numérique est le plus faible, sans perdre le moindre bit.

L’astuce repose sur les deux états électriques du bus : dominant (logiquement 0) et récessif (logiquement 1). Les fils du CAN sont maintenus à l’état haut (récessif) par des résistances de terminaison lorsqu’aucun nœud ne parle ; n’importe quel nœud peut tirer les fils vers le bas (dominant) en faisant circuler du courant via son émetteur-récepteur. Le résultat est un ET câblé : si un seul nœud impose l’état dominant au bus, la ligne se lit comme dominante, et elle ne se lit comme récessive que lorsque tous les nœuds l’ont relâchée. Le dominant l’emporte toujours. (Certaines références appellent ce même montage un OU câblé, en considérant l’état « dominant » comme le signal affirmé plutôt que comme le ET des bits récessifs – le comportement physique est identique dans les deux cas.)

Le ET câblé sous forme conceptuelle. Le CAN réel applique la même logique sur une paire différentielle (CAN_H / CAN_L) avec les émetteurs-récepteurs et les résistances de terminaison répartis sur les deux fils, mais la règle sur le bus reste la même : n’importe quel nœud peut imposer l’état dominant, et ce n’est que lorsque tous les nœuds l’ont relâché que le bus se lit comme récessif.

L’arbitrage exploite directement cette asymétrie. Chaque nœud émetteur envoie son ID un bit à la fois, MSB en tête, et surveille le bus pendant qu’il émet. Un nœud qui place un bit récessif sur le fil mais relit un bit dominant sait qu’un autre nœud ayant un ID plus faible émet au même instant et a remporté cette position de bit. Il cesse aussitôt d’imposer son état au bus et se met à l’écoute. Le nœud gagnant, lui, voit ses propres bits sortir inchangés – de son point de vue, rien d’inhabituel ne s’est produit. L’ID au numéro le plus faible l’emporte parce que ses bits dominants écrasent les bits récessifs que les ID aux numéros plus élevés auraient sinon envoyés aux mêmes positions.

Le perdant attend alors que le bus redevienne inactif et réessaie automatiquement. Il n’y a ni collision, ni message perdu – seulement un ordonnancement déterministe par priorité.

C’est ce style publication/abonnement qui permet au CAN de fonctionner à grande échelle : tout le monde peut parler, tout le monde peut écouter, et les ID rendent l’acheminement implicite.

3.25.2. Le bus physique

Le contrôleur CAN du microcontrôleur ne pilote pas le bus directement. Il n’expose que deux broches CMOS 3,3 V – TX (le bit qu’il veut envoyer) et RX (le bit qu’il voit sur le bus) – et ces broches vont vers une puce séparée appelée émetteur-récepteur CAN ou PHY. L’émetteur-récepteur se place entre le contrôleur et les véritables fils du CAN ; c’est lui qui sait dialoguer avec le bus.

Le bus lui-même est une paire différentielle en 5 V :

• CAN_H – le fil « haut » de la paire.

• CAN_L – le fil « bas ».

À l’état récessif, les deux fils se situent à environ 2,5 V (le milieu de l’alimentation 5 V du bus). À l’état dominant, l’émetteur-récepteur tire CAN_H jusqu’à environ 3,5 V et CAN_L jusqu’à environ 1,5 V, produisant une différence d’environ 2 V entre la paire. Les récepteurs échantillonnent la différence entre les deux fils, ce qui rend le signal insensible au bruit de mode commun capté sur de longs câbles.

La double tâche de l’émetteur-récepteur :

• Côté TX, il lit la broche TX asymétrique 3,3 V du contrôleur et soit écarte CAN_H et CAN_L pour produire l’état dominant, soit relâche les deux pour l’état récessif.

• Côté RX, il lit la paire différentielle CAN_H / CAN_L et restitue un niveau asymétrique 3,3 V sur sa broche RX vers le contrôleur.

Deux résistances de terminaison de 120 ohms, une à chaque extrémité physique du câble, maintiennent le bus au point milieu récessif lorsqu’aucun nœud n’émet et amortissent les réflexions qui corromperaient autrement le signal différentiel sur de longues distances.

3.25.3. La trame de données

Une trame de données CAN standard se présente ainsi sur le fil :

Une trame de données CAN standard : les champs SOF, ID, RTR, contrôle, données, CRC, ACK et EOF.

Chaque champ a un rôle précis :

• SOF (start of frame, début de trame). Un bit dominant qui signale qu’une nouvelle trame commence et synchronise l’horloge de bit de chaque nœud.

• ID (identifiant). L’identifiant 11 bits sur lequel le bus arbitre. Numéro plus faible = priorité plus élevée.

• RTR (remote transmission request, demande de transmission distante). Positionné sur une demande de données plutôt que sur une livraison de données ; les récepteurs ayant un ID correspondant répondent en envoyant eux-mêmes les données.

• Contrôle. Un champ de 6 bits encodant la longueur des données (DLC) et quelques bits de gestion.

• Données. De 0 à 8 octets de charge utile (CAN Classic ; CAN FD étend cela à 64 octets).

• CRC. 16 bits au total : un CRC de 15 bits sur les champs précédents plus un délimiteur de CRC de 1 bit.

• ACK. 2 bits au total. Dans le premier bit – le créneau ACK – l’émetteur relâche la ligne et tout nœud ayant reçu correctement la trame la tire vers le bas ; le second bit est un délimiteur récessif. L’absence d’ACK indique à l’émetteur qu’aucun nœud n’a entendu la trame et qu’il doit réessayer.

• EOF (end of frame, fin de trame). Sept bits récessifs qui clôturent la trame.

Tout cela est généré et décodé par le contrôleur CAN de manière matérielle ; le logiciel ne voit que l’ID, les données et quelques drapeaux.

3.25.4. La place du CAN

Les choix de conception du CAN déterminent sa niche :

• Robuste. La signalisation différentielle sur paire torsadée, la détection d’erreurs intégrée, l’arbitrage par priorité déterministe et les retransmissions automatiques permettent au CAN de survivre dans des environnements électriquement bruyants où l’UART et le SPI corromperaient les données.

• Multi-maître. N’importe quel nœud peut parler à tout moment. Aucun contrôleur central n’est requis et aucun nœud ne constitue un point de défaillance unique.

• Bande passante limitée. Le CAN classique plafonne autour de 1 Mbit/s ; CAN FD étend cette limite. Le CAN est la bonne réponse lorsque la liaison se situe entre des cartes ou des modules, souvent sur plusieurs mètres de câble, avec la fiabilité comme priorité.

• Protocoles de couche supérieure. Le bus CAN nu ne dit pas ce que signifie un ID ni comment scinder un long message en fragments. Des protocoles de couche applicative – CANopen, J1939, ISO-TP/UDS, NMEA 2000 – ajoutent ces règles par-dessus. Un élément distinct qu’il est utile de connaître est le fichier DBC : un format texte propre au fournisseur qui consigne quels ID portent quels signaux au niveau bit sur un véhicule ou un système particulier. Les fichiers DBC sont un format de métadonnées décrivant l’agencement des messages d’un bus donné, et non un protocole à part entière.

Le pilote présenté dans Le bus CAN dans le code gère la trame CAN au niveau du fil ; faire correspondre les ID à leur signification est le travail de l’application.