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 aussiJe 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
Voir les contributions