décodeur dcc pour signaux sncf complexes, avec arduino nano (et pcb)

[trimarco232]

Bonjour,
le décodeur pour signaux sncf à 4 feux, dont j'ai pu écrire un .ino qui fonctionne, est adapté à beaucoup de situations, et économise aux mieux les adresses
il lui manque la gestion des signaux complexes, du clignotement et de la gradation
je me lance dans ce projet dans le but de remplacer les décodeurs sncf LDT d'un ami : c'est pénible (pour moi) à configurer, je ne suis pas parvenu à les faire fonctionner à partir de sa centrale ECOS
l'avantage de l'arduino (entre autres), c'est le moniteur, on pourra depuis le moniteur, regarder ce que la centrale envoie aux addresses du décodeur, et faire un petit menu qui permettra de configurer confortablement le décodeur
en tant qu'homme du hardware (autoproclamé) , j'ai commencé par dessiner un petit pcb, que je vous joins, si vous aimez les images

[trimarco232]

c'est du très classique : on a un nano avec des résistances et des borniers ; on y ajoute une alim et l'optocoupleur du dcc
j'ai imaginé le système de résistances suivant :
celles (cms) qui sont sous le nano sont là pour la protection ; elles ont une valeur minimum (470R), autorisant toutes les manoeuvres hasardeuses en aval du nano
à côté du nano, en série avec les résistances de protection, il y a en // 2 types de résistances :
- les cms ont la valeur maximum qui correspond aux leds consommant le moins (rouge, jaune, vert) ; j'ai fixé cette valeur maximum à 3k3, ce qui doit correspondre à 1 mA pour les leds rouge, vert et jaune ;
- les tht 1/8w permettent de réduire la résistances selon la consommation des leds (blanc, violet) ou selon la tensions de seuil (blanc, violet, 2 jaunes en série) pour cela, je me munis d'un assortiment de 1/8w, qui me permettra d'ajuster au cas par cas
.
les 2 borniers ont la configuration suivante
côté gauche
9   8   7 +  6   5   4  +  3   2   1  +
USB
+ 10 11 12 + 13 14 15 + 16 17 18
côté droite
les numéros des sorties sont continus entre le bornier de gauche et le bornier de droite
le + peut aussi, globalement par cavalier, être un - selon l'électrode commune
il y a une 9ème broche, réservée pour un fonctionnement avec des nanos à lgt328p, qui peuvent faire fonctionner leurs broches A6 et A7 en sorties
après 2 prototypes à 19 sorties (19 feux), j'ai réalisé une série de 5 en version "définitive", en utilisant le module avec la puce à 48 broches, ce qui me fait 32 sorties (32 feux en tout)
.
plus qu'à faire la mise au point ....
l'idéal, serait d'avoir une souplesse maximale, afin d'économiser au mieux les broches et les adresses ...
j'ai donc défini plusieurs configurations devant devant satisfaire la grosse majorité des besoins :
// pm les 14 indications (sauf combinées): 00Se, 01Ve, 10Av, 11Vc, 20Sc, 21Ac, 30Ca, 31Cv, 40Pe, 41Pc, 50Ra, 51Rc, 60Ma, 61Mc
// les config sont :
// 8 : 8 feux, 7 adresses : 1fV, 2fS, 3fA, 4fC, 5fO, 6fP, 7fR, 8fM //
// 7 : 7 feux, 6 adresses : 1fV, 2fS, 3fA, 4fC, 5fO, 6fP, 7fR //  00Ve, 01Se, 10Av, 11Vc, 20Sc, 21Ac, 30Ca, 31Cv, 40Pe, 41Pc, 50Ra, 51Rc
// 6 : 6 feux, 5 adresses : 1fV, 2fS, 3fA, 4fC, 5fO, 6fP //  00Ve, 01Se, 10Av, 11Vc, 20Sc, 21Ac, 30Ca, 31Cv, 40Pe, 41Pc
// 5 : 5 feux, 4 adresses : 1fV, 2fS, 3fA, 4fC, 5fO //  00Ve, 01Se, 10Av, 11Vc, 20Sc, 21Ac, 30Ca, 31Cv
// 4 : 4 feux, 4 adresses : 1fV, 2fS, 3fA, 4fC  //  00SV, 01Se, 10Av, 11Vc, 20Sc, 21Ac, 30Ca, 31Cv /// pertinent ?
// 41 : 4 feux, 3 adresses : 1fV, 2fS, 3fA, 4fC //  00Ve, 01Se, 10Av, 11Vc, 20Ca, 21Cv // ligne spéciale
// 42 : 4 feux, 4 adresses : 1fV, 2fS, 3fA, 4fR //  00Ve, 01Se, 10Av, 11Vc, 20Sc, 21Ac, 30Ra, 31Rc // traitement spécial
// 3 : 3 feux, 3 adresses : 1fV, 2fS, 3fA       //  00Ve, 01Se, 10Av, 11Vc, 20Sc, 21Ac
// 31 : 3 feux, 2 adresses : 1fV, 2fS, 3fA      //  00Ve, 01Se, 10Av, 11Vc
// 2 : 2 feux, 2 adresses : 1fV, 2fS //  00Ve, 01Se, (10Av) 11Vc typiquement pour M, Cv, et Mcli // (10Av) interdit
// 21 : 2 feux, 1 adresse : 1fV, 2fVS  //  00Se, 01Ve  pour Cv, M
// 1 : 1 feux, 1 adresse : 1fV // nécessite une condition de nombre de feux, /// comme pour le 3ème Cv et l'A
// 10 : 1 sortie permanente à LOW
// 11 : 1 sortie permanente à HIGH
.
je partage très en amont du projet, c'est pour recueillir vos questions, suggestions, scuds ...

[trimarco232]

même pas 1 scud ...
j'ai déniché une version rallongée de nano à lgt8f328p ; elle utilise le même mcu, mais en 48 broches
j'ai dessiné dans la foulée une carte pour celui-ci, en voici une image avec placement des composants en vue d'une réalisation par le service PCB Assembly de chez jlcpcb :
(il y a quand même dans les 70 résistances, on comprendra que j'ai préféré confier cela à un robot)

[trimarco232]

les 2 1ers prototypes fonctionnent, ils seront mis en service sur le réseau prochainement
Edit : suite à l'adoption définitive de la technique "capture" du timer1 pour mesurer la durée des 1/2 bits DCC, les prototypes sont disponibles à la vente grâcieuse, (ou à la casse)
j'ai finalement opté pour + de souplesse
un petit dessin pour illustrer le principe : les leds des signaux se raccordent à la suite, il n'y a pas de séparation gauche droite, mais une continuité :
à gauche leds 1 à 10  ↓_↑  leds 11 à 19 à droite
exemple de câblage des signaux sur la 2ème carte dans l'illustration

[trimarco232]

les différents signaux peuvent avoir de 1 à 8 feux (les ralentissement et rappels comptent pour 1 feu, car leurs 2 leds jaunes sont câblées en série)
avec les variantes, ça me fait 14 types de signaux différents, c'est peut-être suffisant
la configuration de chaque arduino se fait au moniteur (arduino ou émulation terminal), je trouve dommage de devoir configurer des CV depuis une centrale quand on dispose de l'USB !
il y a un petit menu ; on saisit une lettre pour dire qu'on veut configurer, puis on saisit :
- l'adresse de base
- le type (parmi 14) du 1er signal raccordé
- puis le type des signaux suivants, j'usqu'à ce que toutes les sorties soient occupées
au fur et à mesure des saisies s'affichent les types, l'adresse de chaque indication, le branchement de chaque led, le nombre de leds qui peuvent encore être branchées
dans mon exemple, à la fin, il restait une sortie libre, j'y ai représenté une led, qui peut servir dans le décor, par exemple, en utilisant une adresse ; on peut aussi configurer en sortie permanente, HIGH ou LOW, donc pas besoin d'adresse
quand la config est terminée, le menu propose d'appuyer sur une touche pour sauvegarder la config  ... is that simple
il y a quelques sorties CV (commun voltage, en orange sur le dessin) réparties le long des borniers

au démarrage l'arduino va rechercher la config dans l'eeprom et la place dans la ram
après mûre réflexion, et lecture studieuse du réglement S1A, j'ai retenu l'odre suivant pour les indications :
Ve,Se, Vc,Av, Sc,Ac, Ca,Cv, Pe,Pc, Ra,Rc, M,Mc (Pe c'est le rapPel 30 et Pc le rappel 60, c pour clignotant)
on a donc 14 indications, soit 7 adresses pour le signal le + complexe
Et que c'est pas fini
bien entendu, l'oeilleton est géré, il s'alume et s'éteind en fonction des indications
il y  a aussi les indications combinées : Pa+Av, Pa+Ac, Pc+Av, Pc+Ac, et Rc+Ac, ; elles s'obtiennent simplement en commandant à leur tour les indications compatibles, par exemple si on veut le rapPel 60 + l'Avertissement, on commande d'abord le Pc, puis on commande l'Av, et on obtient Pc+Av
Pc+Av peut aussi être obtenu en commandant d'abord Av, puis Pc
si maintenant on commande le rappell 30, Pe, on obtient Pe+Av, car les 2 indications sont compatibles, il n'y a pas lieu d'effacer l'Av
par contre, si on commande par la suite, par exemple le Ralentissement 30, Ra, le R s'affiche tandis que le A doit s'éteindre progressivement

progressivement ? of course ! alors un peu de technique
bien qu'il doit être possible de lui adapter mon code, j'ai laissé de côté le nano classique au profit du LGT8F328P, car il permet de faire + pour moins cher
j'ai notamment besoin de + de vitesse (32MHz) et d'un 2ème timer à 16 bits, le timer 3
le timer3 me sert à piloter le pwm des leds (19 ou 32 leds suivant le modèle) , selon une rampe de type exponentielle avec une précision de 10 bits sur 45 pas
le timer1 me sert à mesurer les durées des impulsions DCC, avec une précision de 1/2us ; j'utilise l'entrée capture du timer : cela me permet d'avoir une mesure exacte, même si une autre interruption est en cours au moment de la transition du signal DCC, et aussi de disposer d'un filtre qui élimine automatiquement les éventuels parasites du signal ; la suite du décodage se fait selon la bibliothèque d'Aiko Pras, que j'ai adaptée (facilement) pour avoir la fonction capture sur un AVR de type classique

en vrac :
l'ordre de câblage des feux des signaux est le suivant (ça suit peu ou prou l'ordre des indications) : V, S, A, C(ouCv), O, P, R, M ; dans l'exemple , j'ai des signaus de type S,A,V, R (ou S,A,R,V, je ne sais pas, en tous cas chez moi c'est V,S,A,R) : si on suit l'odre des feux comme indiqué ci avant, il faudrait laisser libres les sorties correspondant aux feux C(carré) et O(oeilleton) : j'ai donc créé un type (le 42), qui permet d'éviter ça et de câbler le R directement à la suite du A (on économise 4 sorties dans l'exemple)
j'ai laissé tomber le choix alim par DCC ou dédiée par cavalier : comme le montre l'illustration, si on veut alimenter par le DCC, il suffit de ponter les sorties DCC et alim sur le dernier bornier en bas (notons que chez trimarco232, le câblage des modules suivants est évident, pas besoin de faire de dérivation...)
pour avoir des feux qui s'allument alors que d'autres s'éteignent sur un même signal, on peut avoir jusqu'à 5 leds qui s'alument ou s'éteignent simultanément et progressivement (par exemple, l'indication Ca qui suit l'indication Pe+Av : on a les feux P+A+O qui s'éteignent progressivement, alors que les feux S+C s"allument pareil) ;  j'ai donc 5 tableaux de 8 lignes (le nombre de feux) et 19 colonnes (le nombre d'indications), en PROGMEM, qui me donnent instantanément ce que chacune des 5 leds doit faire, sans que l'AVR n'ait à effectuer le moindre calcul ; c'est un peu fastidieux, mais comme la CPU doit aller vite c'est la bonne méthode ; en principe perso, alors que certains en sont à l'intelligence artificielle, je programme complètement à plat, c'est l'intelligence zéro, tous les cas sont listés, puis pour chaque cas j'ordonne au cpu ce qu'i doit faire

on va terminer par un petit quizz :
dans l'illustration il y a une petite erreur au niveau du câblage, laquelle ?
dans l'ordre des indications, j'ai mis Vc (vert clignotant) dès la 3ème position (2ème adresse, 1ère position), pourquoi ?

[laurentr]

Bonsoir Marc

Très joli travail de réflexion et de réalisation! ( comme toujours!)

La bibliothèque d AK a été actualisée le mois dernier et elle est très optimisée pour les AVR et ATTINY serie 0/1/2 dont aussi les AVR yyyDXzz. ( avec MEGACOREX, DX CORE, et MEGATINYCORE).

Il a notamment ajouter le classes TIMER et LED dans son projet de décoder et ces éléments doivent pouvoir être utilisés séparément.

Voir ici:
https://github.com/aikopras/AP_DCC_Decoder_Core



C est donc plus le NANO EVERY à base d ATMEGA480X qui est privilégié pour des usages plus "musclés".

Par ailleurs par rapport à la génération ou l exploitation des timers je t invite a jeter un oeil aux libraries de  https://github.com/khoih-prog.

SLOW PWM est utile... ainsi que les zzzz_Timer Interupt entre autre! Peut etre cela t aidera t il a ameliorer encore ton projet... avec des gestions PWM via ces lib....

A dispo pour en discuter très bientôt.

Amicalement
Laurent

[trimarco232]

Bonsoir Laurent,
merci,
merci pour les liens
en fait j'ai choisi un AVR classique (quoiqu'un peu exotique), pour pouvoir fonctionner en 5V : les 2 feux jaunes du  Ralentissement, comme ceux du rapPel sont en série, donc 3v3 ça suffit pas
pour les timers et le pwm, je connais (il y a longtemps, j'ai commencé à programmer les AVR en assembleur, bare metal total), donc une bibliothèque autre ne m'apportera rien (il y a désormais beaucoup de gens qui font des bibliothèques sans trop maîtriser leur sujet)
j'ai signalé à Aiko Pras la possibilité, voire la pertinence et la facilité, d'utiliser la fonction capture sur des AVR classiques ; il fera ce qu'il voudra
le nano every est chouette, mais même en clone, c'est 3x le prix des modules à LGT ... alors par les temps qui courent ...

[laurentr]

Hello Marc

Tu peux très bien fonctionner en 5V sur les nouveaux AVR et ATTINY. Donc pas de sujet la dessus

C est en effet diffèrent avec l autre puce qui est susceptible d etre un "must have" la RP2040... mais là, la lib d AK n'est pas compatible et il faut donc soit la faire évoluer soit repasser vers la DCC NMRA pour en profiter. (ou une autre mais laquelle?)

Pour moi je vois 2 points à ajouter a la classe LED d AK:

sur le mode flashsingleserie la possibilité de sortir de la série avec un état haut ou bas au choix du paramètre à configurer. ( en bas éteint, en haut allume) avec cela on sait alors générer un start de néon et rester allumer à la fin.

l autre modifs consiste a avoir un PWM sur le "ON" ou "OFF" pour gérer le level d intensité lumineuse en "ON" ou "OFF" et ne pas être sur du tout ou rien 0/1 mais sur un setPWM level...

Je pense que cela doit être combinable avec les lib précédemment évoquées...

Je m interroge en fait sur un point: la gestion des PWM avec la lib de Khoih via les ISR ( dont on voit la pertinence) et l utilisation de la gestion soft du PWM par la classe led de AK dont on voit une grande proximité mais qui n est pas dans un ISR...

Je vois bien que selon la charge CPU si on est pas dans une ISR on a un risque d irrégularité de traitement du signal en sortie...
D ailleurs comment visualiser cette charge CPU dans le monde Arduino?

Si quelqu un peut exposer les + et - de chaque cas pour la gestion de ces PWM... je suis preneur d info...

J ai récemment été exposé à un cas analogue dans un petit programme de gestion d effet de démarrage de tube néon.
Avec 95 CHAR de serial print dans la boucle principale les effets sont "fabuleux" et visuellement "parfait"
Sans les serial print la boucle est "trop rapide" et les effets visuels sont différents et ne reflètent pas l attendu.
Donc ou identifier la charge et les temps d exécution pour savoir ou ajuster... les meilleurs timing!???

Mais on est un peu en dehors du thème de ce fil sur ce dernier sujet.

Merci
Laurent

[trimarco232]

Tu peux très bien fonctionner en 5V sur les nouveaux AVR et ATTINY. Donc pas de sujet la dessus
oui, mais il y a peut-être d'autres personnes qui seront intéressées par cette réalisation : il est souhaitable de simplifier les choses en utilisant un module tout fait, avec alim, interface et prise usb ; cela n'existe pas, dumoins à un prix décent, avec les nouveaux avr
C est en effet diffèrent avec l autre puce qui est susceptible d'être un "must have" la RP2040... mais là, la lib d AK n'est pas compatible et il faut donc soit la faire évoluer soit repasser vers la DCC NMRA pour en profiter. (ou une autre mais laquelle?)
je ne pense pas qu'on puisse parler de must have : pour chaque projet, on peut se contenter de "l'arduino" qui suffit ; j'ai cité le RP2040 car il a des atouts : d'abord, d'abord ... c'est un arm : ça ne se programme pas comme un avr ; pour les avr, il faut toujours se dépêcher de sortir rapidement des isr en plaçant des flags si besoin ; pour un arm, c'est l'inverse : si 90% du programme peut être placée dans un isr, éh bien tu le laisse dedans ; si d'autres isr doivent intervenir en priorité, il suffit de leur attribuer une priorité plus haute, et ils viendront interrompre l'isr en cours, qui reprendra quand l'isr prioritaire est terminé
 ... de +, le RP2040 a 2 cœurs ! ça veut dire qu'on peut affecter un cœur à la seule tâche du décodage dcc ; cela permet d'nvisager des améliorations, comme la réparation de messages endommagés par un cc, un faux contact, ou des parasites ; on serait sur un autre niveau de qualité, et il me semble qu'aucune bibliothèque existante n'offre de telles possibilités ; malheureusement la flash externe fait revenir le truc + de 30 ans en arrière, complètement inadapté à des décodeurs embarqués, quand la place est comptée
on peut utiliser la bibliothèque nmra dcc pour le RP2040, c'est juste un peu dommage : j'aprécie beaucoup des auteurs comme Aiko Pras car ils se restreint aux mcu qu'il connait bien, ou l'incroyable et Khoi Hoang, qui décline des bibliothèques en autant de catégories, voire de sous catégories de mcu qu'il connait, et il y en a un paquet ; cela permet d'optimiser le programme au mieux, au contraire des gens de la bibliothèque nmra dcc, qui ont plutôt tendance à régresser sur ce point, afin d'augmenter la portabilité du truc ; mais restons pragmatiques, l'important finalement, c'est que ça fonctionne
 
Pour moi je vois 2 points à ajouter a la classe LED d AK:
sur le mode flashsingleserie la possibilité de sortir de la série avec un état haut ou bas au choix du paramètre à configurer. ( en bas éteint, en haut allume) avec cela on sait alors générer un start de néon et rester allumer à la fin.
l autre modifs consiste a avoir un PWM sur le "ON" ou "OFF" pour gérer le level d intensité lumineuse en "ON" ou "OFF" et ne pas être sur du tout ou rien 0/1 mais sur un setPWM level...
ben faut lui en parler, lui expliquer : il décidera s'il veut l'implanter ou non, mais il faut déjà qu'il ait l'info ; j'ai su le faire ici, donc il saura aussi
Je pense que cela doit être combinable avec les lib précédemment évoquées...

Je m interroge en fait sur un point: la gestion des PWM avec la lib de Khoih via les ISR ( dont on voit la pertinence) et l utilisation de la gestion soft du PWM par la classe led de AK dont on voit une grande proximité mais qui n est pas dans un ISR...
j'ai pas regardé, mais Khoih, comme tout le monde, doit aussi sortir le + rapidement possible de l'isr, sous peine de bloquer le reste

Je vois bien que selon la charge CPU si on est pas dans une ISR on a un risque d irrégularité de traitement du signal en sortie...
exact, mais on n'a pas le choix ; tout l'art, c'est de maîtriser ou pallier ce risque
D ailleurs comment visualiser cette charge CPU dans le monde Arduino?
c'est fastoche, il faut d'ailleurs commencer par ça ; l'arduino n'est qu'une couche qui s'ajoute au dessus du reste ; il faut utiliser quelques broches qui à l'aide de l'analyseur logique, moucharderont ce qui se passe dans la bête : par exemple ici, j'ai pour chacune des 2 isr une broche qui change de niveau au début et à la fin de l'isr, et une troisième qui change de niveau sans la loop (par ex.: PINB = _BV(3)) ; on voit le début et la fin de chaque interruption, et l'impact que ça a sur la durée de la boucle 

Si quelqu'un peut exposer les + et - de chaque cas pour la gestion de ces PWM... je suis preneur d info...
ben faut faire le test et mesurer, intuitivement je penserais que c'est peu ou prou pareil, le principal c'est que tu utilises le capture pour le dcc

J ai récemment été exposé à un cas analogue dans un petit programme de gestion d effet de démarrage de tube néon.
Avec 95 CHAR de serial print dans la boucle principale les effets sont "fabuleux" et visuellement "parfait"
Sans les serial print la boucle est "trop rapide" et les effets visuels sont différents et ne reflètent pas l attendu.
Donc ou identifier la charge et les temps d exécution pour savoir ou ajuster... les meilleurs timing!???
il faut t'afranchir de la durée aléatoire de la loop, et piloter ça par un timer ; le serialWrite, c'est la merdre, il est indispensable pour déboguer, mais quand c'est fait, il faut le virer

[laurentr]

Bonsoir Marc

Je te remercie pour tes observations.

J ai identifie un exemple qui illustre bien ton propos avec le RP2040.
On y comprends bien l attribution des cores ou chacun joue un role.

https://github.com/gab-k/RP2040-Decoder

Il y a peut être plus riche sur le sujet... mais c est une base. Il y a dans l approche peut être des choses similaires avec les ESP32... Les aficionados de ce hardware pourront nous en faire part.
(ps desolé de polluer ton post sur le décodeur de signaux avec ces généralités)

Pour ce qui est du hard et des Attiny et autres AVR récents on a en effet des choix plus limités car en dehors des "Curiosity Nano XXXXXX"  en tout monté et prêt a utiliser c est un peu "pauvre" en offre.

Donc il faut s y coller! => Done!

Passage nécessaire pour simplifier l'upload (via UDPI) au MICROCHIP ICE. (des alternatives restent néanmoins possibles)

 J ai trouve ceci qui sera utile au plus grand nombre des ceux qui se sentent "assez inspirés pour bricoler un peu" : des PCB adaptés à différents brochages dont des ATTINY XX6 ou XX7 ( existe en SOIC assez facilement soudable!) Avec quelques ajustements pour mettre un régulateur de tension en FRONT si besoin par exemple on résous une bonne partie de la dispo.

https://github.com/sirboard

Perso j ai mis sur un petit PCB un LDO D2PACK en 5V afin d avoir de quoi alimenter sorties et usages pour des besoins de petits montage locaux mais c est déclinable.

voir ici ce que cela donne:
https://forum.locoduino.org/index.php?topic=1404.0

A partir de là... bcp de choses deviennent possibles!
On voit aussi que le RP2040 et ses déclinaisons a en outre l'avantage du prix et de la dispo.
La aussi son PCB "maison" est déjà prêt mais pas encore passé au tirage...

Laurent

[trimarco232]

les 2 1ers prototypes fonctionnent, ils seront mis en service sur le réseau prochainement
j'ai finalement opté pour + de souplesse
un petit dessin pour illustrer le principe : les leds des signaux se raccordent à la suite, il n'y a pas de séparation gauche droite, mais une continuité :
à gauche leds 1 à 10  ↓_↑  leds 11 à 19 à droite
exemple de câblage des signaux sur la 2ème carte dans l'illustration

Edit : les prototypes sont abandonnés suite changement de principe de mesure de la durée des bits DCC, ils sont disponibles à la vente grâcieuse (en échange d'une adresse), ou à la casse ...

[trimarco232]

la carte est en service depuis quelques jours, à la grande satisfaction de l'utilisateur, alors quelques photos
- carte terminée (on voit les pattes des leds sur le connecteur, qui m'ont servi à tester la carte)
- carde raccordée et en service (reste à la fixer et à arranger les câbles)
- tableau qui reprend le câblage
reste à corriger un bug qui fait des fausses indications au démarrage ... le programme fonctionnant très bien par la suite