Parlons Arduino > Vos projets
décodeur dcc pour signaux sncf complexes, avec arduino nano (et pcb)
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
Navigation
[#] Page suivante
[*] Page précédente
Utiliser la version classique