LOCODUINO
Discussions Générales => Bus CAN => Discussion démarrée par: bobyAndCo le août 28, 2024, 10:20:22 am
-
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
-
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
-
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.
-
@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
-
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.
-
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 ! ;D Et j'ai pu constater la performance de la passerelle CAN <=> TCP via MS2 & Rocrail que tu as réalisé récemment.
@+
J
-
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.
-
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.
-
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.
-
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 :D
-
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
-
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 :
https://www.youtube.com/watch?v=Xuvttht08FA (https://www.youtube.com/watch?v=Xuvttht08FA)
-
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
-
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
-
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
-
Bonjour
Je rejoins Christian sur ses observations pertinentes.
Je voudrais souligner au passage que les librairies ACANxxx de Pierre MOLINARO ont maintenant une maturité forte et, transposées à des hardwares plus récents et performants et qui sont du même coup, il me semble, plus simples à utiliser ( 32 masques et 32 filtres par exemple) quelques exemples pourraient être actualisés aussi.
Je pense au MCP2517FD notamment (en lieu et place du MCP2515)
Idem pour les déclinaisons ESP32, Teesny, ST32,... Quelques exemple de base.
Sur ESP32, un petit tuto sur comment créer des pages web pour configurer des valeurs que le code va utiliser aurait aussi une forte plus value pour les débutants.( c'est utile)
Quelques exemples "contemporains" pourront relancer l'intérêt.
Pour ma part je combine actuellement un CMP2517FD avec un TJA1052i dans l'esprit "carte historique" d'interface CAN LOCODUINO avec quelques ajouts.
A noter que la TJA1052i permet l'isolation galvanique
On y retrouve la connectique RJ45 (compatible Satellites autonomes) et des connecteurs additionnels alternatifs ainsi qu'une alimentation DC DC local pouvant monter à 5V 2.5A/3A ce qui couvrira bien des usages!
Format 50/70mm en cours de finalisation. ( led d activité à ajouter et quelques contrôles à boucler)
Ltr
-
Bonjour,
Je suis bien content de voir ce sujet et je vais pouvoir peut être enfin arriver à mettre en place le CAN: l'année dernière (c'est pour moi un hobby uniquement hivernal...), j'ai passé des heures à essayer de faire communiquer 2 arduino. j'avais des modules MCP2515 qui n'ont jamais marché et des cartes shield avec lesquelles je suis arrivé à un résultat mais trop aléatoire pour être utilisé.
un qui ne fonctionnait qu'en émetteur... Bref un peu frustré ne pas y être arrivé.....
Je n'ai pas compris pourquoi une telle difficulté alors que la théorie a l'air assez simple.
Est ce que les solutions matérielles intégrées que vous utilisez dans les satellites autonomes sont plus fiables ou quels modules faudrait il utiliser?
J'ai bien compris l'intérêt du CAN : Mon réseau est conçu sous forme de module que j'aimerai pouvoir relier de façon rapide avec un connecteur 6 broches : 2DCC, 2CAN, 2Alim
Merci
-
Bonjour,
Peux-tu préciser quelles cartes Can as-tu utilisé et comment (schéma, photo) car nous n'avons pas de difficulté avec les cartes que nous utilisons.
Testes avec des cartes Niren pour commencer. Exemple ici :
https://forum.locoduino.org/index.php?topic=509.msg5760#msg5760 (https://forum.locoduino.org/index.php?topic=509.msg5760#msg5760)
ou faire une recherche avec "Niren"
-
Bonjour
Lire les 2 tutoriels de Jeans-Luc
https://www.locoduino.org/spip.php?article268
https://www.locoduino.org/spip.php?article269
Cela fonctionne sans ambiguïté et simple à comprendre. (même moi j'y suis arrivé)
Ensuite voir les articles écrit par Christophe & Dominique
Il y a aussi Antoine (Tony), j'ai oublié Eric nopxor => http://forum.locoduino.org/index.php?topic=1784.0
Cordialement
-
Oui, j'avais bien suivi les tutos,
Je suis en attente de nouveaux modules pour refaire des essais, Je ne manquerai pas de faire un retour
-
Ca y est, grace aux cartes de Boby&co, tout fonctionne parfaitement chez moi et j'ai pu commencer la programmation des messages.
il est vrai que ce sont des cartes à base de MCP2562 qui sont au final plus simple à manipuler qu'un controleur SPI externe comme les cartes MCP2515.
J'utilise de ce fait la librairie TWAI-CAN
je me pose quand même une petite question:
Il y a une fonction à appeler pour controler l'arrivée de message, quel est le délai raisonnable entre 2 appels pour ne pas rater de messages? ces controleurs integrent ils une file d'attente pour les messages, de combien de messages?
Merci si vous avez ces précisions
-
J'utilise de ce fait la librairie TWAI-CAN
Pourquoi pas !!! Mais bon, si tu avais utilisé la bibliothèque ACAN_ESP32 comme la plus part d'entre nous il nous serait plus facile de répondre à tes questions
je me pose quand même une petite question:
Il y a une fonction à appeler pour controler l'arrivée de message, quel est le délai raisonnable entre 2 appels pour ne pas rater de messages? ces controleurs integrent ils une file d'attente pour les messages, de combien de messages?
Sur la bibliothèque ACAN_ESP32 tout ceci est effectivement paramétrable. Par défaut les tailles des buffers de réception et d'envoi sont de 16 messages mais ceci peut facilement être modifié dans le setup(). Selon ton application, ces réglages peuvent être modifiés. Par exemple, tampon de 0 message en réception (l'appli ne fait qu'envoyer) et 32 en envoi !!!
Pour les délais, c'est aussi dépendant de ton application. Si la réception est critique, il faut priorisé, voir créer une tâche freeRTOS très prioritaire pour cela. J'ai le cas sur mes satellites où je considère que le changement de signalisation lumineuse peut avoir une latence de 1 seconde et donc, pour ces messages, une priorité faible.
Christophe
-
Pourquoi pas !!! Mais bon, si tu avais utilisé la bibliothèque ACAN_ESP32 comme la plus part d'entre nous il nous serait plus facile de répondre à tes questions
J'ai confondu avec la librairie ACAN simple pour connecter un module MCP2515 comme il est écrit dans les articles du site. Je ne voyais pas l'intérêt de connecter en SPI. Je ne savais pas que la bibliotheque ACAN_ESP32 était différente.
J'ai déjà écrit pas mal de code. je vais voir si je change de bibliothéque