Les livres de Pascal Barlier : "ARDUINO: Faites le jouer au train"

[chris_bzg]

Je sais ce que cela représente de sortir un livre technique ou un cours (j'ai écrit le cours de météorologie pour pilote de ligne édité conjointement par l'ENAC et l'IAJM, publié de 1994 à 2020 (deux versions : française et anglaise) et aujourd'hui, cédé à une nouvelle équipe d'enseignants de l'ENAC car étant à la retraite, je ne suis plus trop dans le coup pour suivre les évolutions des réglementations).

Je viens de commander ta V2 ; bizarre, j'ai choisi Chronopost à la place de Collissimo mais cela n'a pas changé le prix total. J'espère l'avoir demain ; il devrait quitter le stock ce soir. 

[bobyAndCo]

Pour ce qui est du cutout, il est généré par la centrale DCC, puisqu'elle doit mettre en court-circuit la sortie de l'amplificateur pour permettre la lecture du signal Railcom. Le signal d'activation du cutout est par ailleurs transmis de la centrale vers le décodeur Railcom pour que celui-ci se synchronise précisément avec la centrale.

Merci, c'était bien l'info que je recherchais et le mode de génération du cutout que je présentais. Comme la plupart d'entre nous sommes en DCC++, ce qui m'intéresse c'est la manière dont nous pourrions modifier DCC++ pour justement générer le cutout.

J'ai acheté votre livre (comme j'avais acheté le 1°) et je potache actuellement ce que vous appelez "décodeur". De prime abord, cela est séduisant.

[bobyAndCo]

Je viens de commander ta V2 ; bizarre, j'ai choisi Chronopost à la place de Collissimo mais cela n'a pas changé le prix total. J'espère l'avoir demain ; il devrait quitter le stock ce soir. 

Mon cher Christian, si tu es impatient, sache que tu peux consulter la version en ligne en attendant. Il faut que tu ailles sur le compte que tu as créé.

[chris_bzg]

Mon cher Christian, si tu es impatient, sache que tu peux consulter la version en ligne en attendant. Il faut que tu ailles sur le compte que tu as créé.

Salut Christophe,
Je crois que je peux bien attendre jusqu'à demain pour avoir le plaisir de feuilleter un objet bien réel ! 
Odeur de l'encre fraiche, bruissement des feuilles qu'on tourne, poids de l'objet tenu en mains, etc. Je dois être un grand nostalgique... mais pas au point de faire des automatismes à la Chennevez (bien utiles en son temps et son travail, novateur à l'époque, avait été considérable, donc respect de ma part envers l'auteur).
Mais si je craque avant demain, j'aurais l'honnêteté de te le dire. 

A quand le deuxième volet de ton article sur ton pont tournant ? J'y ai repensé en revisionnant dernièrement la vidéo que j'avais faite pour Trainsmania 2021 et en voyant ta tablette pour le commander.

[Dominique]

Six mois de travail tous les soirs 

Sans doute en plus du temps pour la réalisation, les circuits imprimés, les logiciels, les tests sur un réseau réel.. On sent bien que ce qui est décrit dans ce livre a été réalisé et testé. D'ailleurs je viens de l'acheter chez Cultura et je me plonge dans le décodeur RailCom.

[Pascal Barlier]

Plus j'y pense et plus je me dis que j'aurais du écrire le générateur DCC sous forme de librairie. j'ai hésité à le faire, et le résultat, c'est que le même code est présent dans le programme des deux centrales DCC présentées dans le livre, c'est un peu dommage. Il va falloir que j'envisage une refonte du générateur DCC, il pourrait avoir d'autres usages, par exemple pour la régulation des circulations.

J'ai aussi pris quelques photos des circuits :
https://github.com/EditionsENI/Arduino-et-le-train/tree/master/V2/images

[msport]

Il ne faut peut-être pas regretter tout de suite ...
Rien n'est plus énervant que de revenir quelques mois plus tard sur un programme qui fonctionnait parfaitement et qui brutalement ne se compile plus. Et qu'après moult recherches infructueuses sur base de messages improbables, on découvre que la faute est à imputer à une bibliothèque modifiée arrivée discrètement à l'occasion d'une mise à jour ...

[Dominique]

On a échangé un peu sur le bus I2C par rapport au bus Can. Voici un petit développement sur ce sujet :

il y a des discussions sur la comparaison entre ces bus ici et ici, et des discussions sur le Bus Can et aussi la rétrosignalisation. et il y en a quantité de cas concrets en passant par la case "recherche".

Il y a aussi les articles de Jean-Luc sur la mise en oeuvre du bus Can, et, plus moderne : la bibliothèque ACAN.

Coté matériel, les UNO, Nano, Micro, Mega ont besoin d'une carte CAN qui s'interface en SPI alors que les DUE et ESP32 n'ont besoin que d'un amplificateur de ligne (donc comme l'I2C aussi).

Coté utilisation, le Can est 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.

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.
- la mise en oeuvre avec l'Arduino IDE est simple car toute la complexité est dans le contrôleur Can (voir les articles).
- Les composants CAN sont fabriqués en grand nombre, donc peu chers.

Personnellement mon premier réseau était architecturé autour d'un bus I2C, mais il faut bien étudier l'ordonnancement des échanges entre maitre et esclaves, ce qui n'est pas toujours évident.

Dans mon réseau actuel, chaque capteur émet un message dès qu'il y a un événement (ou périodiquement si c'est un état). Chaque message identifie le type de message et les données contiennent les détails. Le gestionnaire recoit tous les messages au fur et à mesure, n'a pas à les demander, ni interroger les capteurs. Un simple "switch" permet de les traiter individuellement.

Cela permet une grande modularité qui m'a permis de construire les éléments de mon réseau à mon rythme.. et il en reste encore à faire !

Pour revenir à l'I2C il faut reconnaitre que le livre de Pascal Barlier donne une foule de détails de mise en oeuvre du bus I2C qui devraient permettre a tous ceux qui l'utilisent de trouver leur bonheur.

[Pascal Barlier]

Coté matériel, les UNO, Nano, Micro, Mega ont besoin d'une carte CAN qui s'interface en SPI alors que les DUE et ESP32 n'ont besoin que d'un amplificateur de ligne (donc comme l'I2C aussi).
...
Coté utilisation, le Can est bien adapté au modélisme ferroviaire :
- Insensible aux parasites (2 fils, différentiel), 100 m à 500kb/s, ou 500 m à 125 kb/s
...
- 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.
...
Dans mon réseau actuel, chaque capteur émet un message dès qu'il y a un événement (ou périodiquement si c'est un état). Chaque message identifie le type de message et les données contiennent les détails. Le gestionnaire recoit tous les messages au fur et à mesure, n'a pas à les demander, ni interroger les capteurs. Un simple "switch" permet de les traiter individuellement.

J'ai opté pour le bus I²C dès le début de mon projet (le 8/10/2014). A cette époque, je considérais le bus CAN comme un bus destiné à l'automobile, et je n'avais par trouvé d'informations pertinentes concernant des interfaces bus CAN pour Arduino.

Par la suite, le CAN m'a été suggéré par un lecteur, je me suis documenté sur le sujet, même si je dois reconnaître que j'ai toujours du mal à changer ce qui fonctionne. De plus le CAN nécessite une carte additionnelle et je voulais éviter de complexifier les montages proposés dans le livre. Je suis donc resté en I²C. Et finalement, j'ai trouvé le PCA9615, qui est un driver différentiel de bus i²C, il permet de résoudre le problème de la sensibilité aux parasites et permet la terminaison du bus.

Donc, le seul inconvénient que je trouve au bus I²C est le fait qu'il soit mono-maître, ce qui ne permet pas de signaler facilement la présence de données à lire. Le signal INT (interruption) disponible sur les périphériques I²C est destiné à cet usage, mais il ne fait pas partie de l'implémentation présente sur les µP Atmel. Je dois donc scanner le bus régulièrement.

[Dominique]

Le choix de l’I2C est aussi un bon choix retenu par une grande partie des modélistes. Ton livre va intéresser ceux-ci grâce aux détails techniques et aux programmes donnés.

Il est vrai que les premières cartes Can étaient très chères. C’est pour cela que la carte Can Locoduino a été conçue :

Mais par la suite des cartes bon marché sont apparues comme celle-ci :

Maintenant il y a le clan I2C et le clan CAN, sans que je sache dans quelles proportions.

Je suis d’accord que quand le projet est bien avancé il n’est pas bien de changer de techno. Mon réseau précédent était basé sur I2C aussi.

Ton livre est agréable et facile à lire : je suis en plein dedans 

[msport]

... j'ai trouvé le PCA9615, qui est un driver différentiel de bus i²C ...

ce qui permet à l'I2C d'avoir une immunité aux parasites comparable au CAN, et peut le réhabiliter aux yeux de certains déçus.
Mais ce composant est réservé aux amateurs avertis, à qui la soudure des CMS (SSOP10) ne pose pas de problème.

J'ai vu des modules avec ce composant mais à des prix curieux (>25€ chez Aliexpress).
Produit trop récent ?, la fiche technique rev. 2 est de septembre 2021.

[bobyAndCo]

J’ai une question qui s’adresse à Pascal Barlier. Sur le Github, la lience est donnée pour « GNU General Public License v3.0 ». Si je ne fais pas erreur, il est donc possible de modifier le code (en citant bien sûr la source) et de le publier le code modifé sur Locoduino par exemple, non ?

J’ai en effet modifié le code de la centrale pour la rendre pilotable par des applications externes comme JMRI en Serial, Ethernet et même en WiFi.

Ce qui m’intéressait moi, c’est tout d’abord de voir si la bibliothèque FlexiTimer2 apporte un progrès quant à la lecture et l’écriture des CVs par rapport à DCC++ (DCCpp).

En second lieu, je cherche aussi à générer des cutout pour tester la détection RailCom. Il faut que je fasse réaliser les PCB proposés et que je soude les composants !

C’est donc dans le but de partager ce code sur Locoduino que je pose la question.

Merci par avance pour la réponse.

[bobyAndCo]

Je me suis lancé pour la détection RailCom telle que la propose Pascal Barlier.

J'ai lancé la fabrication de PCB chez JLCPCB pour 9€49 les 10 et en prime, j'ai pris en plurple (disponible depuis environ 6 mois) mais il n'y plus de délais supplémentaire comme avant.

Si ça intéresse quelqu'un, je n'utiliserai pas les 10 cartes, c'est à ce stade essentiellement pour faire des tests. A ma connaissance, ce serait le premier detecteur RailCom DIY à base d'Arduino. Celui de Paco est à base de PIC.

A suivre...

[Pascal Barlier]

Mais ce composant est réservé aux amateurs avertis, à qui la soudure des CMS (SSOP10) ne pose pas de problème.
J'ai vu des modules avec ce composant mais à des prix curieux (>25€ chez Aliexpress).
Produit trop récent ?, la fiche technique rev. 2 est de septembre 2021.

Il est un peu difficile à souder, mais j'y suis arrivé avec un simple fer équipé d'une grosse panne plate. Cela permet de souder toutes les pattes à la fois, il faut juste utiliser du flux de soudure pour que ce soit possible. Avec une grosse loupe et sans trembler, c'est tout à fait réalisable. J'explique la méthode dans le livre.
Effectivement le circuit est très récent, puisque la rev 1 de la datasheet est de 2019. Les circuits du même type, mais plus anciens, sont classés obsolètes, et c'est dommage car il y avait des versions DIP plus faciles à souder.
On le trouve pour 3€66 chez Mouser (hors taxes et frais de douane, on peut ajouter 50% pour le prix réel), il tombe à 3€28 si on en prend 10. Et une dizaine est suffisante pour équiper tout un réseau puisque l'on peut ensuite déployer un bus I²C classique à partir du circuit, c'est ce que j'ai fait.

[Pascal Barlier]

J’ai une question qui s’adresse à Pascal Barlier. Sur le Github, la lience est donnée pour « GNU General Public License v3.0 ». Si je ne fais pas erreur, il est donc possible de modifier le code (en citant bien sûr la source) et de le publier le code modifé sur Locoduino par exemple, non ?
J’ai en effet modifié le code de la centrale pour la rendre pilotable par des applications externes comme JMRI en Serial, Ethernet et même en WiFi.

Ce qui m’intéressait moi, c’est tout d’abord de voir si la bibliothèque FlexiTimer2 apporte un progrès quant à la lecture et l’écriture des CVs par rapport à DCC++ (DCCpp).
En second lieu, je cherche aussi à générer des cutout pour tester la détection RailCom. Il faut que je fasse réaliser les PCB proposés et que je soude les composants !

Le projet est hébergé sur le GitHub de mon éditeur, qui a choisi la licence GNU, que j'ai également choisie pour mes autres projets, qui sont hébergés sont mon compte GitHub perso. Cela signifie en effet, que les sources qui sont sur le GitHub peuvent être modifiées et republiées sous licence GNU.

J'ai prévu (page 174) un emplacement sur le circuit imprimé de la centrale pour un circuit d'interface USB (composant XA2) basé sur un circuit FT232RL. C'est une façon pratique d'interfacer la centrale avec un PC. Ce n'est qu'une option, je n'ai pas eu l'occasion (ni le temps) de développer le code nécessaire (le pilotage par PC n'est pas ma priorité).
Le circuit d'interface est disponible pour 6€99 sur Amazon :
https://www.amazon.fr/ElectroWorldFR-FT232RL-Serial-Adapter-Module/dp/B09JMCKLXX

Flexitimer2 est une bibliothèque qui permet de gérer les interruptions avec plus de précision que la bibliothèque standard, rien de plus. Elle n'est pas la seule à pouvoir le faire, mais elle permet de calibrer l'interruption à 29µs, ce qui est nécessaire pour réaliser proprement le cutout. Franchement, je me demande bien pourquoi les créateurs de la norme Railcom ont décidé de décaler de 1/2 période d'horloge DCC le début et la fin du cutout, si ce n'était pas le cas, une interruption à 58µs suffirait pour générer un signal DCC avec cutout.

C'est en répondant à cette question que je viens de réaliser qu'il y a une erreur dans le code de la centrale (at-dicicino.ino  ligne 1917), je me suis trompé pour la valeur de l'interruption
Il est écrit ceci :
FlexiTimer2::set(1, 0.000028, dccInterrupt);
Mais la bonne valeur est 29µs :
FlexiTimer2::set(1, 0.000029, dccInterrupt);
Ça fonctionne quand même avec mes décodeurs, mais il vaut mieux mettre la bonne valeur.
La même erreur est présente dans le code de la petite centrale (at-multi2.ino ligne 2061).