Le CAN sur nos réseaux : Pourquoi et comment ?

[bobyAndCo]

Bonjour à tous,

J’ouvre ce sujet car le CAN a été mis sur le devant de la scène avec son incorporation récente à l’intérieur de laBox. C’est aussi le moyen de communication des satellites autonomes dont je vous parle de puis quelques temps. Mais enfin et surtout, parce que l’on vous en parle régulièrement dans Locoduino au travers de nombreux projets.

J’ai l’espoir que ce fil permettra au plus grand nombre d’entre vous de comprendre tous les bénéfices qu’il y a à déployer sur nos réseaux une communication en CAN plutôt que toute autre, d’en comprendre les mécanismes fondamentaux pour être capable de déployer progressivement cette technologie avec une totale compréhension plutôt que par copier-coller qui montre rapidement ses limites.

Alors, s’agit-il d’un énième article sur le sujet ? Je ne crois pas. J’ai la chance de discuter avec différents Locoduinistes dont beaucoup sont convaincus que le CAN est effectivement ce qu’il y a de mieux pour un réseau mais ne voient pas comment l’utiliser concrètement, se l’approprier pour développer pour leurs propres besoins.

Oui beaucoup a été écrit (ou dit comme à la conférence de Jean-Luc à Trainmania) et pourtant, force est de constater que les résultats ne sont pas à la hauteur des moyens engagés.

Beaucoup voudraient en faire mais peu se sentent capables et armés pour cela. Et n’osent pas trop avouer que cela leur passe largement au-dessus.

Alors peut-être ce fil aurait pu s’intituler : « Tout ce que vous auriez voulu savoir sur le CAN sans jamais oser le demander ».

Oui, il y a de nombreux articles sur le sujet mais aussi des choses qui manquent et j’espère que ce fil pourra être l’occasion d’exprimer sans tabous vos blocages et vos interrogations car le bénéfice au terme en vaut largement le coup.

J’ai beaucoup réfléchi et depuis pas mal de temps à ce sujet et je pense que le CAN est tellement différent de tout ce que l’on peut connaitre dans notre quotidien qu’il nous est difficile d’en avoir une compréhension par « analogie ».

Nous connaissons les communications téléphoniques « de point à point », un appel un. En composant un numéro, je m’adresse à une personne en particulier et cette personne m’identifie grâce à mon numéro d’appel. Ce sont les communications dites de point à point.

Depuis le COVID, nous connaissons mieux le principe des visos ou plusieurs personnes peuvent échanger et se voir mais il faut rapidement organiser la prise de parole car cela devient vite un capharnaüm.

Nous connaissons bien aussi le principe de la communication hiérarchisée du professeur vers sa classe, du conférencier vers son auditoire. Dans nos systèmes, il est bien connu au travers de l’I2C avec les maîtres et les esclaves

Mais du principe du CAN, où tout le monde peut envoyer des messages librement et écouter tout ce qui se dit sur le bus nous n’avons que peu d’exemples depuis mai 68 hormis les réseaux sociaux mais on voit avec quels résultats.

Alors je crois qu’il faut chercher à connaitre quels sont les principes fondamentaux et les spécificités qui font que le CAN répond si bien aux besoins sur nos réseaux. Et ayant compris ces spécificités originales, comment vous pourrez petit à petit les maitriser et les mettre en place.

Aussi, j’espère aussi que vous serez nombreux à vous exprimer sans tabous et sans fausse pudeur et que les « experts » du sujet à Locoduino joueront le jeu pour vous éclairer le mieux possible.

En parallèle de ce fil, nous avons envisagé avec Catplus (Marcel) de réaliser de petites visio-conférences qui permettraient d’apporter des réponses plus personnelles et interactives. Nous avions déjà réalisé des visios sur ce même sujet et avec succès il y a un an ou deux maintenant.

Voilà donc le cadre posé, à vous de vous en saisir si vous le souhaitez.

Christophe

[bobyAndCo]

Alors, pour entamer, je pense qu’il faut avant tout répondre à cette première question pour ensuite l’évacuer : Pourquoi une communication en CAN sur un réseau de modélisme ferroviaire est-elle préférable à toute autre ?

Je ne poserai ici que quelques arguments et de manière très superficielle, principalement pour ouvrir la discussion et, à partir de là, approfondir ce qui vous intéresse.

1° - Tout d’abord, d’un point de vue technique : La transmission différentielle du signal le rend particulièrement insensible aux perturbations électromagnétiques particulièrement présentes sur les réseaux. J’ai volontairement mis ce point en premier quand je vois sur d’autres forums les prises de têtes que sont les communications (rétrosignalisation par exemple) défaillantes.

2° - Au-delà de ce point, il possède un haut niveau général de fiabilité : Bien sûr, nos problématiques à ce sujet ne sont pas à la mesure de ce qui est nécessaire dans un avion ou encore une automobile. Mais on appréciera tout de même que nos trains n’entrent pas en collision à cause d’une communication défaillante.

2° - Il est rapide comparé à beaucoup d’autres systèmes. Dans les systèmes qui restent abordables à notre niveau, on peut atteindre de vitesses d’échange de 250, 500 ou même 1000 kb/s en CAN.

3° - Il est économique. De nombreux exemples sur le site montrent l’utilisation de petits module niRen que l’on peut acheter pour 1 ou 2€. Il n’y a rien besoin d’autre, pas de routeur ni système centralisé. Pour peu que l’on entreprenne de réaliser ses propres PCB avec du CAN, les composants pour des débits de 1Mb/s vous reviendront à moins de 5€. Ils sont reliés entre eux par de câbles économiques également.

4° - Il est facile à déployer et se substitue souvent très avantageusement à de nombreux autres câbles.

Pour déployer un bus CAN, on n’a besoin tout au plus que de deux fois deux fils ; deux fils pour l’alimentation électrique (qui peut être la même que pour les autres équipements). Deux fils pour le bus lui-même, CAN L (LOW), CAN H (HIGH)

On rencontre de plus en plus souvent un principe de câblage avec du câble Ethernet et des prises en RJ45. C’est ce que j’ai utilisé par exemple sur les satellites autonomes. Les câbles Ethernet étant largement utilisés en bureautique par exemple, ils sont avantageux et très fiables au niveau de leur connexions. Il est alors possible de faire circuler dans un seul câble le courant d’alimentation des appareils et le signal CAN.

Pour ne pas être trop long, je me limite à ces quelques arguments mais je ne doute pas que d’autre avanceront d’autres atouts. Je ne doute pas également que ce qui est avancé soit discutable, voir critiquable. D’autres modélistes sur Locoduino utilisent avec succès d’autres technologies et peuvent apporter en miroir leur expérience voir leur désaccord.

Quand ce postulat préalable aura été démontré, nous pourrons mettre en évidence certaines spécificités et voir comment nous les approprier en pur bénéfice pour nos réseaux.

Encore une fois, n’hésitez surtout pas à vous mettre au clavier, que vous soyez d’accord  ou pas, que vous ayez des expériences profitables aux autres ou des questions et blocages pour lesquels vous aimeriez avoir des réponses.

Christophe

[phenixpopol]

Bonjour et merci pour les articles,
Ayant réalisés la plupart des applications des dossiers "la bibliothèque ACAN1 et 2 " , j'attends la suite avec impatience.
Cordialement.

[bobyAndCo]

@phenixpopol.

Merci pour ce témoignage. Est-ce que tu accepterais de nous en dire un peu plus pour pouvoir orienter le sujet ? Par exemple, les difficultés éventuelles que tu as pu rencontrer. Les informations qui auraient pu te manquer ? Quelle appréciation portes tu sur le CAN après cette expérience ? Est-ce que tu projettes quelque chose de précis avec le CAN ?

bien cordialement

Christophe

[Dominique]

Bonjour et merci pour les articles,
Ayant réalisés la plupart des applications des dossiers "la bibliothèque ACAN1 et 2 " , j'attends la suite avec impatience.
Cordialement.

Et justement, un des arguments majeurs en faveur du bus Can, c’est la disponibilité de ses bibliothèques pour la plupart des microcontrôleurs Arduino (AVR, RISC, ESP32, TEENSY, etc..) tous réalisés par Pierre Molinaro (bibliothèques ACAN) et son excellent livre très complet « CAN et CAN FD » aux éditions Elektor. Plusieurs articles sont consacrés à l’usage de ces bibliothèques.

[JeromeUK]

2° - Au-delà de ce point, il possède un haut niveau général de fiabilité : Bien sûr, nos problématiques à ce sujet ne sont pas à la mesure de ce qui est nécessaire dans un avion ou encore une automobile. Mais on appréciera tout de même que nos trains n’entrent pas en collision à cause d’une communication défaillante.

Bonjour Christophe, comme tu le sais je débute donc il m'est difficile d'avancer des arguments pertinents a ce stade, ni meme de poser des questions précises. Mais je vais suivre ce post avec interet pour apprendre justement.

Pour me convaincre de la qualité du protocole CAN, il me suffit de penser qu'il équipe nos voitures depuis 28 ans avec l'introduction du standard obligatoire OBDII (On Board Diagnostic) en 1996. Le nombre de calculateurs embarqués dans nos voitures modernes est impressionnant et les exigences de fiabilité/précision sont hautes. Donc pour nos petits trains, l'idée ne me parait pas mauvaise, qui peut le plus peut le moins !   Et j'ai pu constater la performance de la passerelle CAN <=> TCP via MS2 & Rocrail que tu as réalisé récemment.

@+
J

[bobyAndCo]

Merci Jérôme pour ce témoignage. Et je suis très heureux que des 3raillistes comme toi soient présents sur Locoduino.

Effectivement, tu as réalisé cette passerelle pour laquelle j’avais écrit un article et je me réjouis qu’elle fonctionne bien (et ne t’ai pas couté trop cher !)

Pour tous ceux qui souhaitent comprendre le CAN pour pouvoir réaliser ensuite sans peine des montages propres et originaux, je ne saurais trop vous conseiller les articles de Jean-Luc : https://www.locoduino.org/spip.php?article268 et suivant.

Il est très didactique et l’évolution est très progressive. Toutes les bases du CAN sont là. De plus, le petit composant niRen que Jean-Luc utilise est fiable et très économique.

Astreignez-vous à ne sauter aucune étape avant que vous n’ayez parfaitement compris la précédente. Réalisez les montages, travaux pratiques indispensables. La seule lecture ne suffit pas.

Cela demandera peut-être quelques efforts et du temps également mais le jeu en vaut la chandelle, croyez-moi.

Le code que vous aurez copié (écrit) dans votre dossier Arduino vous resservira pour tous vos autres montages.

Et n’oubliez-pas, que vous pouvez évoquer tous vos questions ou difficultés sur ce fil et nous vous apporterons les réponses.

Christophe.

[Dominique]

Traditionnellement, on commence par écrire un récepteur sans filtre et un émetteur simple qui envoie un message toutes les secondes.

À ce stade on peut compter et afficher les messages pour vérifier que ça marche.

Ensuite ou à la fin on peut tester les filtres car c’est le plus difficile à comprendre.
Le livre de Pierre Molinaro les explique bien aussi mais nos articles sont déjà suffisants.

[dduni56]

Aller pour apporter un peu de contradiction, le bus CAN c'est les 2 premières couches de l'OSI.
Donc c'est robuste certes mais après il y a encore pas mal de programmation à faire.

[Dominique]

Juste non, grâce à la bibliothèque ACAN et surtout au contrôleur de bus Can qui fait magistralement les couches supérieures .

Voir la figure 3.2 du livre de Pierre Molinaro qui m'autorisera, j'espère :

Un tel bus aussi fiable et complexe (de ce fait) n'est aussi simple à mettre en oeuvre 

[laurentr]

Bonjour

Merci Christophe pour cette initiative.

Il y a peut être plusieurs "Levels" à démystifier.

Tout d abord ce qui a trait au hardware puis au soft.

Depuis les articles initiaux il y a eu grâce aux librairies de Pierre MOLINARO quelques mises à jour de la bibliothèque et les exemples pourraient être actualisés ( notamment dans les #include) ou tout est " en un" me semble t il à présent.

Dans la partie soft je vois la conception de la "messagerie" et la façon de l'observer.

J ai eu une petite déconvenue avec CAN qui utilise le SPI sur un NanoEvery.

Je désirai utiliser l'interruption de port sur une série de broches ( reliées à des capteurs de présence) et je n y suis pas parvenu!( erreur!! et compilation impossible).
J en ai déduit que l interruption de port n'était pas possible en cohabitation avec CAN et en suis revenu a une approche plus classique de faire une lecture des broches de façon cyclique plutôt que par interruption.
Je n ai toutefois trouver nulle part d info sur cette limitation.

Pour illustrer un exemple plus parlant et compilant plusieurs sujets traités par Locoduino voici une thématique d'utilisation:
gestion de servo avec pilotage par CAN ou DCC de 4 servos avec pilotage de relais inverseur pour les polarisations de pointe de cœur.

Au niveau "hard" ca peut ressembler à ceci...

Mais j ai encore un peu de grain à moudre cote code.

Laurent

[bobyAndCo]

Histoire de dynamiser ce fil un peu atone à mon grand regret. A croire que tout le monde a parfaitement pigé le CAN ou s'en fout totalement.

Pas mal d'éclairages intéressants ici :
 

[Christian M]

Bonjour,

Je suis en développement sur mon réseau un petit en Hom avec un allé-retour et probablement un réseau un peu plus conséquent en HO avec gare caché... etc
je regarde depuis plusieurs mois le forum ainsi que les développements des cartes et bien sûr du réseau CAN.

ce forum m’intéresse particulièrement car je suis assez nul en programmation arduino même si aujourd'hui mes deux centrales ont été créées et fonctionnent à partir du site LOCODUINO et avec JMRI.

J'espère que ce Forum sur le réseau CAN va perdurer car les explications que vous donnez sont assez claires pour moi et je compte bien gérer mon réseau à partir de ce protocole.

Merci beaucoup à tous les contributeurs qui me permettent d'avancer et de créer cartes et éléments de gestion de réseaux ferroviaires.

cordialement

Christian

[chris_bzg]

Histoire de dynamiser ce fil un peu atone à mon grand regret. A croire que tout le monde a parfaitement pigé le CAN ou s'en fout totalement.
...

Bonjour Christophe,

Je ne crois pas que tout le monde ait parfaitement pigé le CAN car le protocole est tout de même compliqué afin de garantir un taux d'erreur très faible. Je ne crois pas que les gens s'en foutent non plus, et je pense que c'est bien d'essayer de le promouvoir, ce que vous faites Dominique et toi.

Cependant, Dominique cite le livre de Pierre qui est un véritable dictionnaire du CAN : on y trouve absolument tout mais présenté dans un ordre qui n'est guère pédagogique (beaucoup de renvois à des pages ultérieures) et qui est un livre de référence pour des étudiants ou ingénieurs qui connaissent déjà le CAN mais certainement pas pour un débutant qui veut découvrir et comprendre. Je ne crois pas non plus que les polynômes isomorphes soient indispensables à la compréhension du CAN, ni la distance de Hamming, mais c'est décrit et donc très bien pour les deux catégories de lecteurs que j'ai citées. J'ai beaucoup apprécié le développement concernant le débordement de la fonction millis() d'Arduino, mais encore une fois, ce n'est pas pour les débutants.

La vidéo que tu cites est tout à fait l'inverse des vidéos que je préconisais pour le site, projet qui n'a guère retenu l'attention. Durant 40 minutes, on y voit un mec essayer d'expliquer le CAN (d'après le titre) mais sans trop savoir comment l'expliquer, donc c'est diffus (on explique tout le DCC), parfois confus, avec des erreurs d'élocution flagrantes. Les schémas sont cantonnés à une vague vignette en coin supérieur droit au lieu d'occuper tout l'écran. J'ai tenu 15 minutes puis j'ai survolé le reste sans être convaincu (la vidéo n'est même pas chapitrée). J'ai trouvé de bien meilleures vidéos pour expliquer le CAN mais hélas en anglais : il semble que nous les français ne savons pas faire ce genre de choses.

L'expérience accumulée en matière de CAN appliqué au modélisme ferroviaire par l'équipe LOCODUINO est incontestable et date de plusieurs années. Alors, pour promouvoir ce bus, personne n'est mieux placée que vous deux pour le faire. Un article pour le site éditorial, résumant les grands principes, ce qui est important, ce qui est superflu, les points forts et les comparaisons avec d'autres bus permettrait sans doute à beaucoup de gens de comprendre et de s'y mettre.

Je ne suis pas le mieux placé pour parler du CAN puisque je ne l'utilise pas. J'ai fait les expériences des articles de Jean-Luc mais cela s'arrête là. Pour autant, j'ai toujours suivi ce que vous avez fait à ce sujet, ce qui m'a aidé à comprendre la mise en oeuvre et à apprécier le livre de Pierre vu que je ne partais pas de zéro. La balle est dans votre camp et VOUS ETES LES MIEUX PLACES POUR EXPLIQUER : inutile de citer Pierre, Paul, Jacques. 

Amicalement.

Christian

[Jeje_12_34]

Bonjour Christophe

Je ne peux qu'appuyer ce qui a déjà été dit . Ce n'est pas parce que on ne s'exprime pas que ce n'est pas intéressant, bien au contraire.

Continuez comme vous faites tous, c'est très bien pour ceux qui s y interressent en partant de rien

Bonne journée

Jérôme