Bus CAN

Le bus CAN est un une laison série :

  • asynchrone : pas de fil d’horloge (les différents éléments connectés doivent être configurés avec le même débit
  • half Duplex : on parle chacun son tour, à condition que le bus soit libre

reseau_can.svg


1 - Format d’une Trame de Données (Data Frame)

data_frame.svg

  • Bit de Start : Passage de 1 (état de repos) à 0
  • Adresse / Identifiant / champ d’arbitrage
  • Champ de Commande : Nombre d’octets dans le champ de données
  • Champ de données
  • Champ de CRC : Calcul sur les données envoyées permettant de détecter des erreurs de transmission
  • Champ de ACK : Tout message doit être acquité ; le destinataire doit forcer le bus à 0
  • Fin de Trame

Capture d’une Trame avec Analyseur Logique SALEAE :

saleae_can.png

test_can.png


2 - Arbitrage

CSMA CD/AMP ( Carrier Sense Multiple Acces with Collision Detection and Arbitration Message Priority).
Avant d’Emettre sur la ligne, le noeud écoute et vérifie qu’aucun transfert n’est en court. Si c’est le cas il attend.

Lorsque le bus est libre, plusieurs noeuds peuvent vouloir émettre. Tous ces noeuds commencent à placer l’identifiant sur le bus.
Le niveau 0 étant dominant, si un noeud tente de forcer le niveau 1 sur la ligne, mais qu’il entend 0, c’est qu’il a perdu l’arbitrage.
Le noeud envoyant un message avec l’identifiant le plus petit gagnera donc le droit d’émettre.

arbitration.svg

REMARQUE : Format Standard/Etendu

Il est possible de faire cohabiter sur un même réseau des trames au format standard (11 bits) et au format étendu (29 bits).

format_etendu.svg


3 - Filtrage

Tous les messages défilant sur le bus n’intéressent pas forcément tous les noeuds.
Pour éviter d’interrompre un noeud dès qu’un message est placé sur le bus, on peut écrire au niveau du périphérique CAN les identifiants accceptables.


4 - Modèle ISO du Bus CAN

La norme CAN spécifie les couches Physique et Liaison de données uniquement.
D’autres protocoles (devicenet, canopen, ..) spécifient les couches hautes.

couches.svg

5 - La Couche Physique

5.1 - Le codage NRZ

nrz.svg

5.2 - Le bit Stuffing

Le bus CAN étant une liaison asynchrone, il faut qu’un front soit régulièrement présent pour resynchroniser le récepteur.
L’ajout systématique d’un bit de polarité inversée au bout de 5 bits de même polarité permet de résoudre le problème.
L’émetteur ajoute donc ces bits de stuffing, le récepteur ne les considèrera pas comme de l’information utile.

bit_stuffing.svg

5.3 - Une liaison différentielle

L’information du bus CAN est une tension différentielle entre CAN_H et CAN_L.
Cela permet une meilleure immunité face aux perturbations électromagnétiques (les perturbations touchant les deux fils, la différence de potentiel reste la même).

liaison_diff_1.svg

liaison_diff_2.svg

Le driver CAN doit permettre, en plus d’amplifier le signal du µC, de transformer une tension référencée par rapport à la masse en une tension différentielle.

Exemple de circuit d’interface de ligne :

block_diagram.svg


6 - Les autres Trames

6.1 - Trame de requête (Request Frame)

A identifiant identique, moins prioritaire qu’une trame de données (cf RTR bit)

request_frame.svg

6.2 - Trame d’erreur (Error Frame)

En cas de problème (par exemple défaut d’acquittement), interrompt le transfert en court en abandonnant la règle du stuffing.

error_frame.svg

Le noeud interrompu réémet sa trame ; si l’erreur n’est pas résolue, une autre trame d’erreur sera émise.
Une trame d’erreur active interrompt la communication en cours ; au bout d’un certain nombre de trames d’erreur active émises, on passe en erreur passive.
Une trame d’erreur n’est alors émise que lorsque le bus est libre. Si l’erreur persiste, le noeud responsable est déconnecté.

error_frame_me.svg

error_frame_diag.svg

6.3 - Trame de Surcharge (Overload Frame)

Identique à une trame d’erreur active.
Interrompt le transfert en cours pour signaler une demande de délai.