Train miniature du futur

[chris_bzg]

A mon avis le cas le plus difficile est celui de plusieurs voies parallèles. Comme elles sont proches les unes des autres, il faudrait un dispositif de localisation assez précis pour savoir sur laquelle on est.
......

Avec une précision de 1cm, on peut parfaitement faire la différence entre une voie ou l'autre.
La technique existe donc, mais le problème est qu'il faut la miniaturiser (seul les industriels en auront les moyens) et aussi que le prix de l'abonnement diminue, mais cela viendra au fur et à mesure que d'autres secteurs utiliseront ce mode de localisation.

La boussole électronique peut également être une idée à développer d'autant que tu obtiens déjà une précision de 1 degré ; c'est donc prometteur et sans doute un montage utilisant plusieurs techniques permettrait d'obtenir un prototype fonctionnel.

[savignyexpress]

Bonjour à tous,

Permettez-moi d'apporter ma contribution à ces échanges passionnés en reprenant, dans le désordre, quelques points.

Fils / sans fils
Il n'est pas certain qu'une solution intégralement sans fil reste maîtrisable sans disposer de solides connaissances du système voire d'outils de diagnostic. Alors que suivre les fils et utiliser un multimètre permet déjà un dépannage de base, bus informatiques exceptés. La transmission d'énergie sans fils n'est par ailleurs probablement pas la plus efficace en terme de rendement, sans parler du rayonnement électromagnétique auxquels nous sommes et serons exposés.

Énergie embarquée
Personnellement, je trouve déjà suffisamment agaçant de devoir charger mon smartphone une fois par jour pour encore m'embêter avec la charge de batteries embarquées dans nos locos. L'alimentation par les rails a encore de beaux jours devant elle, d'autant plus qu'il existe des solutions pour pallier aux micro-coupures telles que les power pack, basés sur des super cap (déjà mentionné), couplés aux décodeurs DCC.

Localisation des trains
La détection par consommation de courant me semble la plus simple et la plus fiable à mettre en oeuvre.

Esprit Locoduino
Ces échanges appellent une réflexion plus générale quant à ce que j'appellerais l'esprit Locoduino. Si nous contribuons au site et au forum Locoduino, c'est avec la volonté de réaliser soi-même les composants nécessaires à nos petits trains, tout en gardant la compréhension et la maîtrise de ce que nous réalisons. Nous pouvons ainsi être moins dépendant des solutions du commerce et avoir la satisfaction de l'avoir entièrement réalisé.

De mon point de vue, cet état d'esprit est totalement absent des systèmes numériques actuels, que ce soient ceux dédiés au train miniature ou l'électronique grand public. Avec ces systèmes et aussi ceux qui ont été évoqués dans ces échanges, l'utilisateurs a avant tout le souci de les configurer au mieux pour obtenir la fonctionnalité souhaitée.

Si vous parcourez les forums dédiés aux centrales DCC, aux logiciels de contrôle, vous avez certainement remarqué que les problèmes rencontrés sont similaires à ceux des utilisateurs de PC: compatibilité de versions, configuration réseau, adressage, etc. Bien sûr ces problèmes ne sont pas totalement absent du monde de l'Arduino, il faut bien un PC pour programmer nos microcontrôleurs, mais je pense que l'on se prend beaucoup moins la tête.

Il est bien entendu impossible d'échapper complètement aux produits industriels, personne ne songerait ni ne pourrait réaliser un décodeur DCC lui-même, mais maintenir la complexité à un niveau maîtrisable me paraît possible.

Après tout dépend de l'intérêt du modéliste, selon que l'on fait de la technologie un moyen d'améliorer son réseau ou un but en soi, le réseau devenant un périphérique.


Bonne fin de semaine à tous.

[chris_bzg]

Bonjour Marc-Henri,

Effectivement, suivre un fil peut être plus simple pour un dépannage que la transmission d'énergie. Mais comme toujours, quand une nouvelle technique arrive, on apprend à la maitriser, à la reproduire, à la dépanner. Pour certains, un relais est plus simple à comprendre qu'un circuit intégré ; pour d'autres, le microcontrôleur s'impose de suite, or il a bien fallu apprendre à les maitriser ces microcontrôleurs.
Oui, c'est un inconvénient d'avoir à recharger une batterie : cette solution apporte par contre d'autres avantages que j'ai déjà mentionnés donc je ne vais pas y revenir. Comme toujours, chaque choix technique apporte des avantages et des inconvénients et chacun doit trancher. Enfin, je remarque que tu as quand même un smartphone, d'ailleurs plus personne n'utilise un poste téléphonique des années 70 (ceux qu'on ne rechargeait pas). La recharge par induction est déjà un progrès par rapport au chargeur à brancher : à méditer.
La consommation de courant est ce qui est le plus utilisé pour localiser les trains... parce qu'il n'y a pas grand chose d'autre. Mais si un système se développait pour transmettre la localisation du train sans avoir à câbler quoi que ce soit, il est à parier qu'il s'imposerait très vite !

Toute cette réflexion sur le train miniature du futur (et je te remercie d'y participer) peut donner naissance à des voies à expérimenter (on est encore loin de la réalisation) et cette expérimentation est bien dans l'esprit de Locoduino. Ensuite, il y a aussi le DIY (Do It Yourself) qui est aussi dans l'esprit de Locoduino et en général, on copie ce qui existe déjà dans le monde industriel (cas des centrales DCC fabriquées avec DCC++). Pour une fois, ce sera peut-être le monde industriel qui copiera ce que nous arriverons à expérimenter, mais encore une fois, cette expérimentation doit se faire avant tout pour notre propre plaisir.

Ensuite, une évolution de nos trains miniatures ne se fera pas en un an... alors le filaire, le courant dans les rails et les centrales avec décodeurs embarqués ont encore de beaux jours devant eux. Hélas, les gamins d'aujourd'hui ne veulent plus de tout cela. Je reste persuadé qu'il nous faudra évoluer ou périr et ce fil est fait pour voir comment nous pourrions évoluer, il n'a pas la prétention d'imposer quoi que ce soit. Exprimons nos rêves car nous en avons certainement encore.

[chris_bzg]

Vidéo embarquée

Ce qui a fait le succès des drones de loisir, c'est qu'ils peuvent filmer le vol et avec des casques de réalité virtuelle, on se transporte littéralement dans l'appareil qu'on pilote. Ceci donne donc assez rapidement du plaisir à jouer. Mais le drone a un autre avantage : à peine déballé, il est opérationnel : il n'y a rien à construire. Enfin, grâce à une technologie qu'on a sans doute longtemps cru réservée à des systèmes plus élaborés (accéléromètres et gyromètres), le pilotage devient un jeu d'enfant puisque si on lâche tout, le drone se met en vol stationnaire à attendre.

Le train miniature du futur doit donc se rapprocher de ce modèle s'il veut attirer les adolescents et pour cela, les locomotives doivent être capables d'embarquer de quoi filmer (caméra + transmission). Commandés par un smartphone ou une tablette ou un logiciel d'ordinateur, le paysage filmé peut alors apparaître comme dans un poste de conduite en tout point similaire au poste du modèle réel. Les différentes commandes peuvent également se retrouver sur l'écran (frein, klaxon, portes, pantographes, radio, etc.). La conduite de l'engin ressemble alors à la réalité contrairement au train miniature actuel où on reste extérieur au système (1). Certains scénarios de jeux pourraient aussi rajouter des pannes, comme cela se pratique avec les simulateurs de conduite des trains actuels (caténaire sur le point de se rompre, voie qui s'affaisse, autre train en détresse sur la voie à contresens, etc.). On peut aussi tenir compte de la masse tractée pour modifier le comportement du train et c'est à l'apprenti conducteur d'en tenir compte pour son jeu. Je crois qu'avec toutes ces possibilités, on se rapproche d'un jeu vidéo qui plaira aux adolescents.

Enfin, pour avoir de suite un système prêt à jouer, il faut justement qu'on puisse s'affranchir des étapes de câblage des rails qui demande à la fois du temps et des compétences. C'était déjà un peu l'idée avec le DCC qui ne demandait que deux fils, sauf que la rétrosignalisation a un peu compliqué le problème par la suite...

Peut-être aurons nous la chance d'avoir quelques adolescents qui s'exprimeront sur ce qu'ils aimeraient avoir comme train miniature pour s'y intéresser et avoir envie de pratiquer, car après tout, le train miniature du futur les concerne plus que nous, non ? 

(1) il y a deux philosophies, soit on veut piloter son train et il vaut mieux se sentir à l'intérieur, soit on veut contempler son réseau et regarder les trains passer et la façon de pratiquer actuelle est très bien pour cela. C'est un choix personnel.

[Dominique]

Quand même, le cuivre est sûrement plus bénéfique à la santé que les ondes électromagnétiques :

À la fois anti-infectieux et anti-inflammatoire, le cuivre aide à lutter contre les états infectieux et viraux (bronchite, angine, rhinopharyngite récidivante) et en cas de fatigue. Il agit aussi au cours d'affections rhumatismales inflammatoires (arthrite).

Le cuivre est un oligo-élément polyvalent, actif dans les états infectieux et inflammatoires. Il stimule puissamment les défenses naturelles des personnes immunodéprimées, les aidant à combattre microbes et virus. Sa propriété antibactérienne est précieuse.
Le cuivre est un catalyseur nécessaire à la constitution de la molécule d’hémoglobine, en association avec le fer.

Plus on vieillit, plus ces besoins augmentent, surtout quand un processus arthrosique apparaît. Dans la réversibilité de ce processus, l’oligo-élément cuivre joue un rôle incontestable.

Le modélisme ferroviaire étant principalement une affaire de séniors, méditons sur les avantages du cuivre pendant qu'il en reste encore un peu sur la planète !!!

J'aurais dû commencer le modélisme bien plus tôt, ça m'aurait peut-être évité une hanche en titane 
Parce que je dénude les fils avec les dents (j’ai la dent à dénuder !), j’ai maintenant ma dose de cuivre 

[Dominique]

Plus concrètement, pour diminuer considérablement le câblage qui vous chagrine, sans le supprimer (pour le moment) et satisfaire les désirs des jeunes qui ne veulent pas se casser, il y a quand même un moyen qui peut être viable :

Cela consiste à intégrer le câblage et l’électronique dans une semelle sous les rails et les aiguilles, avec le ballaste qui cacherait tout. Un système de gestion du type « un Arduino par zone ou canton », l’alimentation des rails, la détection de consommation, le bus CAN (2 fils), feraient qu’il y aurait très peu de points de connexion à réaliser.

Là, en creusant cette idée il y a peut-être du concrêt pour dans pas bien longtemps. Il est possible que nos présentations d’architectures en facilitent l’émergence.

[chris_bzg]

.....
Un système de gestion du type « un Arduino par zone ou canton », l’alimentation des rails, la détection de consommation, le bus CAN (2 fils), feraient qu’il y aurait très peu de points de connexion à réaliser.

Là, en creusant cette idée il y a peut-être du concrêt pour dans pas bien longtemps. Il est possible que nos présentations d’architectures en facilitent l’émergence.

Bonjour Dominique,

Tu prêches un convaincu : alors que beaucoup de gens souhaitent un système centralisé qui gèrerait tout leur réseau, j'ai toujours été convaincu qu'il y a un intérêt à "diviser pour mieux régner". Ainsi par exemple, un passage à niveau peut tout à fait être géré par une carte Arduino qui ne fait que cette tâche (ou par un ATtiny comme je l'ai publié récemment). Ensuite, on peut faire communiquer tout ce petit monde par différents moyens, le bus CAN étant sans doute celui qui a ta préférence mais il y en a d'autres. Tout dépend de la communication à établir. Si on prend l'exemple d'un canton de BAL, le µC doit simplement communiquer au canton amont son état (et recevoir aussi l'état du canton aval) ; or, il n'y a que deux états (libre ou occupé), ce qui peut être transmis par la simple présence ou non d'une tension. J'ai publié un tel système pour des feux tricolores de circulation routière où je faisais travailler deux ATtiny ensemble, chacun gérant son propre feu.

Il y a différentes possibilités pour que le train miniature du futur soit à la fois plus facile à utiliser et plus ludique et je pense que le site Locoduino a déjà donné, et donnera encore, de nombreuses idées que chacun peut reprendre à son compte pour les améliorer et les utiliser sur son réseau. Car l'esprit Locoduino dont nous parlions aussi un peu plus haut, est que tout ce qui est publié est Open Source ; nous ne cherchons pas à devenir des artisans ou des industriels du train miniature, nous travaillons pour notre plaisir en espérant que ce soit aussi celui des autres. Un des plaisir peut être celui de découvrir d'autres voies possibles, ou du moins de les essayer même si elles ne mènent nulle part (c'est le seul risque).

Pour ce qui concerne le débat cuivre-ondes, je me garderai bien de polémiquer là dessus. Tu as certainement raison sur le plan de la santé, mais un des inconvénient du cuivre est qu'il s'oxyde (d'où de mauvais contacts possibles) et un inconvénient du câblage est que les rongeurs l'adore comme ce modéliste qui a décrit sa malheureuse expérience d'avoir eu son réseau détruit par Mickey et ses copains (publié dans Loco-Revue). Au moins, les ondes auraient eu raison de la colonie car si c'est mauvais pour les humains, ce doit l'être pour les souris, mais bon, c'était juste pour sourire... 

[Dominique]

Tu prêches un convaincu : alors que beaucoup de gens souhaitent un système centralisé qui gèrerait tout leur réseau, j'ai toujours été convaincu qu'il y a un intérêt à "diviser pour mieux régner".

Mais je n'ai pas dit qu'un système centralisé n'est pas possible. L'Arduino par canton peut s'occuper d'interfacer tout ce qui se branche sur le canton et le ramener sur le bus CAN sous forme de messages. Un gestionnaire centralisé peut ensuite piloter tous les éléments. Cela simplifie considérablement le câblage (2 fils pour le CAN et l'alimentation 14-18V à brancher seulement) si quelqu'un se lance dans la réalisation de ces cantons Arduinisés pour ceux qui ont des ampoules aux creux des mains ou qui se sont déjà brulé tous les doigts avec le fer à souder !

On peut continuer à essayer de définir ce canton Arduinisé si tu veux et si ça intéresse d'autres lecteurs.

Bon week-end.

[dbe8f]

Bonsoir à tous,

Très agréable, je constate que les discussions vont bon train !
Plein d'idées, certaines très intéressantes.

Malheureusement, je n'ai pas assez de temps pour vous suivre. Beaucoup de travail et pas mal de problèmes à régler.
Dès que j'aurai de la disponibilité, je regarderai les possiblités et les solutions.

En tous les cas, merci de vous y intéresser.

@Marc-Henri, merci pour tes remarques.
En effet, la maitrise des technologies est bien plus difficile que de suivre des câbles. Mon "problème" à moi, c'est que je n'aime pas tirer des câbles...quelques uns OK, mais des milliers, rien pour moi !
Pour la recharge des batteries embarquées, il pourrait y avoir par exemple de l'alimentation lors des passages en gare ou en gare cachée qui les rechargeraient.
Tiens, je voyais hier un article LinkedIn qui disait que le premier bus électrique à recharge en parcours était mis en service à Genève ! Lorsqu'il s'arrête aux arrêts de bus, même 20 secondes, il est rechargé, au terminus il est rechargé...
Des solutions il y en a et s'il ni en a pas aujourd'hui, demain sûrement, une question de temps.

Le tout tout seul, je le disais dans un post précédent, c'est bien, et cela dépend de chacun. Pour moi, passer du temps à concevoir un module qui va me prendre bcp de temps pour le fabriquer, le tester, le corriger et le finaliser alors que le même module je peux l'acheter pour quelques francs (Euros), je ne réfléchi pas, je l'achète. Aussi parce que je n'ai malheureusement et absolument pas de temps à consacrer aux loisirs.

Concernant l'esprit Locoduino, il est respecté, du moment que l'on nous a créé un espace "Discussion ouverte". Penser aujourd'hui pour demain n'est pas un mal, bien au contraire.

Je crois que Christian a bien résumé tout ça dans son post.
Merci Christian pour ta réponse mais lorsque je mets les balises de citation, il ne vient que "Citer" et rien d'autre ! Alors comment fais-tu pour avoir les informations de la personne et de la date et heure ?

Bonne nuit à tous et meilleures salutations.
Dario

[chris_bzg]

Merci Christian pour ta réponse mais lorsque je mets les balises de citation, il ne vient que "Citer" et rien d'autre ! Alors comment fais-tu pour avoir les informations de la personne et de la date et heure ?

Bonne nuit à tous et meilleures salutations.
Dario

Hélas, je ne sais pas l'expliquer. Je clique sur citer et la première ligne donne, après "quote" le nom d'auteur, un lien et une date.
Je regarde le forum avec edge, le navigateur de Windows 10.
Jean-Luc en saurait plus que moi sur le pourquoi ça marche pour moi et pas pour d'autres...

Pour ce qui concerne ce fil, chacun peut s'exprimer sur le train qu'il aimerait avoir, celui qui lui donnerait le moins de problèmes à résoudre. Pour certains, cela peut être de ne pas trop tirer de câbles, pour d'autres d'avoir une interface conviviale pour le commander, d'autres encore auront envie d'avoir plus de fonctionnalités, etc.
Il n'est pas nécessaire forcément de savoir déjà comment y parvenir ; un jour la technique le fera. Ce qui compte, c'est que le plus grand nombre participe à ce fil car en faisant le tri des idées, il y en aura certainement une ou deux qui intéresseront certains à les développer. Il faut donc venir s'exprimer ici non pas forcément avec régularité mais quand une idée a germé dans votre cerveau. Cette idée vous parait folle ? J'aurais tendance à dire tant mieux car si elle était raisonnable, c'est qu'elle serait déjà dépassée !

[Dominique]

Bonsoir à tous,

1) Quand on clique sur « citer » en haut d’une contribution, ça crée une réponse avec la totalité de la contribution, son auteur et la date. En général on ne garde qu’une partie pertinente de la contribution dans la réponse qu’on fait.

2) Quand on clique sur l’icône de citation (la petite bulle de texte dans les barres d’icônes au dessus du texte en cours de saisie) en mode édition d’une contribution, on n’a alors que le mot

citation

.

[Dominique]

Moi j’aimerai bien savoir ce que vous pensez de mon idée de canton ou zone pré-équipée d’un Arduino programmé et connecté à toutes les fonctions de ce canton ou cette zone (les 2 mots n’ont pas le même sens), par exemple :

• les détecteurs de consommation des différentes zones
• les sorties pour les leds des feux
• les sorties pour les commandes d’aiguilles
• les détecteurs de fin de course des moteurs d’aiguille
• l’alimentation des rails en DCC ou PWM
• le bus CAN, les lampes d’eclairage du décor, etc...

On peut peut-être imaginer un nombre restreint de tels modules dont les combinaisons permettraient de construire pas mal de types de réseaux.

Évidemment celui qui fabriquerait ces modules aurait plein de fils à brancher, mais pour les modélistes utilisateurs, ce serait plus simple.

A côté de cela, il faudrait concevoir un gestionnaire, genre écran tactile graphique, relié au CAN pour piloter tout ça. Avec un bon jeu de bibliothèques et un QI minimum, ça doit être possible en DIY.

Pas trivial, mais pas utopiste !

[bobyAndCo]

Mon cher Dominique,

Je n’en pense que du bien ! Je suis d’ailleurs en train de travailler sur quelque chose de tout à fait similaire à ce que tu décris avec un Arduino par canton et :

• Un détecteur de consommation par canton
• Différents capteurs sur la voie, ILS, capteurs à effet Hall, capteurs IR dans mon cas
• Des sorties pour les commandes d’aiguilles. Je n’ai que des servos alors j’ai créé une classe aiguille qui hérite elle-même de la classe servo. (biblio Servo)
• Sorties pour les feux de signalisation
• …

Je n’utilise pas de détecteurs de fin de course pour les moteurs d’aiguillage. Je ne fais également pas passer les commandes DCC par ces Arduino.

Il est assez facile d’ajouter des sorties pour d’autres accessoires comme des moteurs.

J’utilise des Mega pour le nombre de broches disponibles. Avec la biblio « PinChangeInt », je dispose ainsi de 12 broches en entrée et tout le reste en sortie (un peu plus de 30). C’est largement suffisant pour un canton.

Toutes les broches d’entrée sont sous interruption.

La communication se fait soit par Ethernet, soit par WiFi en TCP et en Full Duplex. Rapide avec très peu de latence.

Il n’y a donc que peu de câblage pour chaque canton hormis les câblages de proximité entre les différents accessoires et le Mega.

Les seuls câblages qui courent sous la planche en plus de l’Ethernet sont le fils de puissance :
• 18 V DCC pour alimenter chaque canton
• 12 V DC pour alimentation des Mega (et autres sous cette tension)
• 5V DC pour les servos, les feux, capteurs à effet Hall et les relais

Tout ceci reste donc très limité.

Les programmes sur chaque Mega sont rigoureusement identiques ce qui simplifie la maintenance. J’ai juste un fichier de configuration pour chaque Mega qui contient 3 paramètres :
• Numéro du canton,
• Adresse IP du shield
• Choix de la communication en Ethernet ou Wifi

Au démarrage du Mega, dans le setup, j’ai une fonction qui télécharge sur le gestionnaire de réseau les paramètres spécifiques pour chaque canton (nombre de servos, angles pour chaque servo etc…). Les données sont échangées au format Json avec la (très bonne) biblio « ArduinoJson »

Je regarde également pour implanter « ArduinoOTA » qui permet de téléverser le code à partir de l’IDE mais par Ethernet ou WiFi ce qui évite de se brancher successivement sur chaque Arduino par le port USB/série.

Au final, j'ai un code extrêmement compact et très réactif avec tous les capteurs sous interruption et une communication avec le gestionnaire en Full Duplex.

Je peux fournir le code à ceux que ça intéresse. Ca fonctionne en Ethernet et il me reste à finir d'implanter le WiFi.

Bien amicalement.

[bricoleau]

Bonsoir

Je peux essayer de vous donner mon humble avis d'arduiniste, en gardant l'hypothèse d'un contrôleur à base d'arduino pour chaque canton, qui est certainement la plus modulaire :

Plus de pins sur la mega, oui ça peut être utile, encore que avec des registres à décalage et autres io expander on arrive à des résultats voisins. Disons que ça peut permettre de faire un programme unique, où toutes les pins sont associées à une fonction précise, même si celle-ci n'est pas mise en oeuvre dans chaque canton. Et en complément, on peut imaginer des locoshield mega pour simplifier la connectique avec les montages électroniques périphériques. Pour ma part, la mega est surtout indispensable quand on a besoin de plus de 32kb de code exécutable.

Une connectivité wifi (ou disons sans fil) par canton cela me semble un peu luxueux, et peut-être aussi moins fiable qu'un réseau local cablé, qu'il soit ethernet ou à base de bus CAN. Un seul point d'accès wifi pour l'ensemble du réseau n'est-il pas suffisant?

Entre CAN et Ethernet pour faire discuter ce petit monde, perso j'ai une préférence pour ethernet car c'est plus ouvert. Une centrale à base de raspberry pi pourrait donner des résultats très sympathiques. Mais j'ai cru comprendre que dans l'environnement électrique perturbé d'un réseau ferroviaire, le bus can était plus fiable pour échanger des infos.

Dans tous les cas, c'est bien d'avoir au démarrage une phase ou chaque participant publie sa signalétique sur le réseau. Cela simplifie l'appréhension de nouveaux éléments par la centrale ou entre eux. L'idéal est d'aller jusqu'à des fonctions d’appairage, que chacun mémorise dans son eeprom pour la fois suivante.
Là par exemple je suis en train de commencer à jouer avec des cartes CAN, je vois assez bien le principe de communication. Je m'interroge néanmoins sur la nécessité d'un sur-protocole standard (acquittements d'échanges, etc.), avec identification des équipements émetteurs/récepteurs. Le but n'est pas de refaire du TCP par dessus le bus CAN, mais je me demande si je ne vais pas commencer par coller un équivalent d'adresse MAC à chaque MCP2515

L'arduinoOTA j'avais déjà commencé à regarder mais c'est un peu chaud. J'en étais arrivé à la conclusion qu'il vaut mieux procéder en deux temps. D'abord récupérer le code exécutable par téléchargement, et le stocker en local (par exemple sur une carte SD - les shields ethernet ont un lecteur), puis modifier le bootloader pour recopier le code vers la flash, lorsqu'une nouvelle version est disponible en local et vérifiée intègre. Ca fait un bootloader un peu plus gros car il doit embarquer la lecture du stockage local. Ecrire en flash au fur et à mesure de la réception des paquets me semble trop fragile, face aux aléas réseau.
Avec un tel système, il serait possible d'héberger le code exécutable sur le cloud, pour qu'il soit partagé par une communauté.
Le programme principal pourrait interroger l'hébergement de référence à intervalles réguliers, en tâche de fond de son fonctionnement normal. Et si une nouvelle version est disponible, la télécharger en local sur un stockage annexe (toujours en tâche de fond), pour qu'elle s'installe au redémarrage suivant.
NB : je ne vois rien qui empêcherait de faire la même chose en passant par un bus CAN : un arduino en guise de passerelle CAN-Ethernet, qui se chargerait de récupérer le nouveau code et de le broadcaster sur le bus, en trame de fond et par paquets de 8 octets.

[Jean-Luc]

Là par exemple je suis en train de commencer à jouer avec des cartes CAN, je vois assez bien le principe de communication. Je m'interroge néanmoins sur la nécessité d'un sur-protocole standard (acquittements d'échanges, etc.), avec identification des équipements émetteurs/récepteurs. Le but n'est pas de refaire du TCP par dessus le bus CAN, mais je me demande si je ne vais pas commencer par coller un équivalent d'adresse MAC à chaque MCP2515

Je pense que tu commences juste juste et que tu es passé à côté de certaines choses.

1) l’acquittement fait déjà partie du protocole et il n’est donc pas nécessaire de reconstruire quelque chose qui va prendre du cpu par dessus. De même pour la détection et correction d’erreur.

2) le principe d’identifiant de message permet plus de choses que l’adressage des nœuds. Tu peux décider que tout ou partie des identifiants désignent le nœud destinataire (ce qui est l’équivalent d’une adresse MAC) mais aussi qu’ils désignent, ou étiquettent. le type de message que tout nœud peut prendre ou ne pas prendre. Il servent également de priorité car contrairement à ethernet les collisions ne détruisent pas le message, le plus prioritaire passe. Le temps de transmission est donc bornable et calculable, ce qui n’est pas le cas pour ethernet.

Exemple : tu veux faire une messagerie pour manœuvrer les aiguillages, l’identifiant du message désigné la carte mais tu peux aussi décider qu’il désigne le moteur d’aiguillage avec une partie de l’identifiant pour la carte et une partie pour le moteur sur une carte.

Exemple : pour synchroniser les asservissements de vitesse de cantons adjacents affectés à la même locomotive, on a besoin de diffuser la PWM et la composante intégrale de la loi de commande. Si un canton est désert, la PWM est à fond puisque la loi de commande tente de faire avancer une locomotive recalcitrante, ce qui n’est en fait pas la. Dans ce cas un identifiant de message est formé de la concaténation de l’identifiant de la loco et de la valeur de la PWM. Les nœuds affectés à une loco programment les filtres de manière à ne recevoir que les messages concernant cette loco. Le fait que la valeur de la PWM fasse partie de l’identifiant va rendre plus prioritaire le message issu de l’alimentation traction pilotant le canton qui contient la loco. Le premier message entrant est celui qui portent les bonnes informations.

NB : je ne vois rien qui empêcherait de faire la même chose en passant par un bus CAN : un arduino en guise de passerelle CAN-Ethernet, qui se chargerait de récupérer le nouveau code et de le broadcaster sur le bus, en trame de fond et par paquets de 8 octets.

C’est ce que nous faisons. Par exemple sur le réseau de Philippe il y a 40 alimentations de canton, une dizaine de cartes aiguillages, autant de cartes de signalisation, des cartes son. Tout cela est mis à jour via le CAN.

Je ferai une modification du bootloader Arduino pour flasher via le CAN, c’est nécessaire sur mon réseau.