Discussions Générales > Bus CAN
Le bus CAN
Jean-Luc:
Nous avions démarré en interne une discussion sur le bus CAN qui a débouché sur la réalisation d'un module permettant d'expérimenter le bus sur un Arduino. La carte réalisée est visible sur le fil voisin : BreakoutBoard CAN. Ce développement a été entrepris car les shields CAN sont mystérieusement hors de prix (20€ et plus).
Le bus CAN est déjà utilisé dans notre hobby. Il y a tout d'abord le MERG (Model Electronic Railway Group). Organisation anglaise qui a choisi le CAN pour interconnecter les modules qu'elle développe. L'explication est donnée ici : http://www.merg.org.uk/merg_resources/cbus.php
Ensuite il y a Zimo qui a choisi le bus CAN comme bus de rétro signalisation : http://www.zimo.at/web2010/aboutus/highlights_EN.htm
Enfin il y a CAN Digital Bahn : http://www.can-digital-bahn.com/news.php
J'utilise moi même le CAN sur mon réseau (2 bus en fait, l'un à 125kb et l'autre à 700kb+)
Des informations concrètes suivront sur le site éditorial.
railyRabbit:
J'ai un doute à lire les différents post : le bus CAN intègre-t-il un système de validation / renvoi des ordres si nécessaire ?
Que se passe-t-il si l'information transmise est corrompue en chemin, ou si le destinataire ne la reçoit pas (buffer plein, pb transitoire sur la connexion...) ?
DDEFF:
Jean-Luc est pas mal occupé en ce moment.
Je peux néanmoins répondre à tes questions : oui, le bus CAN s'occupe de tout. Il a plusieurs niveaux de sécurité et renvoie les messages si nécessaire.
Je n'ai pas pu tester encore, mais c'est ce qui se fait de mieux comme bus.
Dominique:
J'ai fait quelques tests entre un UNO et un MEGA:
J'ai réalisé un banc de test avec un Mega qui émet des messages CAN sur 4 IDs et 4 tailles différents toutes les 25ms ( variable en fait, avec une limite basse à 10ms) et un Uno qui les reçoit sous IT, les compte et renvoie les compteurs (message de 4 octets) au Mega.
Pour garantir la réception, les messages sont récupères dans l'IRQ du CAN dans un buffer circulaire de 256 octets et traites 1 par 1 dans la LOOP qui est assez rapide pour suivre sans problème. Le buffer ne se sature jamais.
Apparemment il faut respecter 2 règles:
- mettre le moins de traitement possible dans l'ISR, juste un flag à monter,
- vider complètement le buffer du MCP2515 à chaque LOOP si le flag est monté.
Le UNO qui teste combine le CAN, l'I2C et un timer1 pour un Watchdog. Il compte les messages reçus, les affiche et renvoie un message avec ses compteurs toutes les secondes.
J'ai mis en place le maximum de précautions:
- la surveillance de l'IRQ du 2515, avec vidage forcé si plus d'IRQ depuis 1 seconde (ça peut servir à surveiller la vie des autres modules)
- la surveillance des overflows
- un Watchdog sur la LOOP avec réinit du CAN si la librairie se bloque.
Pour le moment ça tient à l'aise les 40 messages par seconde (4 messages de taille différents repères toutes les 25 ms.)
En augmentant la cadence, je vois que ça tient encore à 100 messages par seconde.
Mais il y a quelques pertes tout de même : 6/1000 à 40 messages/sec, 17/1000 à 100 messages/sec, 1/1000 à 20 messages/sec.
Il faut donc utiliser des messages Accusés de Réception au niveau application, notamment pour confirmer l'exécution d'une commande
Dominique:
Mise à jour :
La cause des pertes de message résidait dans le test de non réception (plus d'IRQ pendant 1seconde) dont le traitement consistait à vider le tampon du 2515 pour lui permettre de générer à nouveau un IRQ.
En supprimant ce vidage forcé, les pertes de messages ont disparu !
Néanmoins, avec toutes les tortures qui je lui fais subir, il reste une perte de 1 message sur 10.000 environ.
Navigation
[#] Page suivante
Utiliser la version classique