Pour l'expo d'Orléans, j'ai réalisé quelques panneaux A4 pour expliquer le Bus Can et le comparer au bus I2C.
Comme nous mettons franchement en avant le bus Can, il est normal d'en bien comprendre ses avantages.
Je vous livre donc les contenus de ces panneaux :
Le bus I²C a été défini pour interconnecter des composants placés sur une même carte. Il n'a pas de robustesse vis à vis des perturbations, puisque le retour se fait par la masse. Son emploi est très risqué de carte à carte, à cause des problèmes de mode commun.
Le bus CAN été prévu pour connecter des sous-ensembles ou des équipements distants jusqu'à 1 km. Le débit est fonction de la longueur du bus. Il est particulièrement bien protégé contre les perturbations. Mais cela n'aurait pas de sens à l'intérieur d'une carte.
- 2 fils suffisent, pas de masse commune, carte 5V <-> carte 3,3V
- Le bus CAN est TRES robuste. C'est la raison pour laquelle il s'est imposé dans l'industrie puis dans le domaine automobile. Sans CAN on aurait toujours des voitures sans électronique...
1. I2c est synchrone and CAN est asynchrone.
2. i2c nécessite un maitre et des esclaves avec des adresses esclave. CAN n’a pas besoin d’adresses.
3. i2c est orienté Noeud et CAN est orienté message mais on peut connecter jusqu'à 30 noeuds ensembles.
4. i2c utilise SDA and SCL, référencés par rapport à la masse, CAN est un bus différentiel utilisant le SPI.
5. i2c marche à seulement 2 vitesses sur Arduino : 100kbps, 400kbps, CAN travaille de 10 à 1000 kbps.
Au final le Can est préférable parce que :- Bien adapté au modélisme ferroviaire.
- Insensible aux parasites (2 fils, différentiel), 100 m à 500kb/s, ou 500 m à 125 kb/s
- Messages de taille limitée. 8 octets de données au plus.
- Temps-réel. Les temps de transmission sont déterministes et peuvent être calculés à priori.
- Multi-maître asynchrone. pas d’arbitre centralisé, pas d’horloge globale, une station peut émettre quand elle veut et l’émission a lieu dès que le bus est libre.
- Priorité entre les messages. Les collisions, quand plusieurs contrôleurs CAN émettent sur le bus simultanément, sont résolues sans destruction du message le plus prioritaire.
Fiable :
- Une détection d’erreur est incluse. La probabilité qu’une erreur reste non détectée est inférieure à 4,7 10
-11.
- Le protocole définit une surveillance très stricte du bus.
- La cohérence des données est garantie. Un message est soit accepté par tous les contrôleurs CAN du réseau, soit rejeté par tous.
- Acquittement des messages par toutes les stations, le signalement d’erreur émis par une station est reçu par toutes les stations.
- Retransmission automatique des messages après signalement d’erreur.
- Un contrôleur CAN gère de façon autonome les erreurs temporaires qu’il détecte.
Et peu coûteux :- Les contrôleurs CAN sont soit disponibles en tant que composant destiné à être connecté à un micro-contrôleur, soit intégrés directement dans un micro-contrôleur.
- La quantité de logiciel nécessaire pour le faire fonctionner est très succincte.
- Les composants CAN sont fabriqués en grand nombre, donc peu chers.
A titre indicatif, la bibliothèque Can que nous utilisons avec le MCP2515 de Microchip se trouve sur le Git de Locoduino, ici :
https://github.com/Locoduino/CAN_BUS_ShieldAttention, elle diffère légèrement des autres bibliothèques car nous l'avons améliorée.
