LOCODUINO
Parlons Arduino => Le logiciel DCC++ => Discussion démarrée par: Matth_76 le novembre 22, 2024, 12:16:07 am
-
Bonjour,
Dans le cadre de mon projet de construction d'un mini réseau automatisé à l'échelle N, j'ai trouvé intéressant de pouvoir travailler avec la carte Arduino Uno R4 WiFi. En effet avec son processeur plus rapide, le WiFi intégré, la matrice LED et le support du Bus CAN natif, cette carte semble bien adaptée pour mon projet.
Le problème est que malgré son nom très similaire à l'Arduino Uno Rev3 le processeur n'est pas le même et la librairie DCC++ ne la supporte pas.
J'ai donc travaillé sur la modification de la Base station DCC++ de Gregg E. Berman pour cette carte. Ma base station se compose uniquement d'un Arduino Uno R4 Wifi et d'un Arduino Motor Shield (clone de Deek Robot en réalité). Le signal DCC sort par les pin 12 (voie principale) et 13 (voie de programmation) de l'Arduino donc aucun câble jumper n'est requis!
Avec cette configuration, le pilotage des locomotives fonctionne bien soit via Serial ou WiFi. Je ne vous cache pas que cela n'a pas été sans effort!
Pour l'instant la lecture des CVs ne fonctionne pas. Il semblerait qu'il y ait une différence entre les 2 cartes Uno Rev3 et R4 au niveau des pins analogiques utilisés pour la lecture. Etant donné que la programmation des locomotives n'est pas une priorité pour moi je ne vais pas trop investir du temps sur ce sujet pour le moment.
Pour les éventuels intéressés, le code (livré sans garantie) de ce projet se trouve ici https://github.com/moverney/DCCpp_UnoR4/tree/develop. Ce code est nettement perfectible mais c'est un premier jet sur lequel je vais pouvoir m'appuyer pour mon projet.
Bien à vous.
-
le processeur n'est pas le même et la librairie
Je ne vous cache pas que cela n'a pas été sans effort!
Il semblerait qu'il y ait une différence entre les 2 cartes Uno Rev3 et R4 au niveau des pins
Bonjour,
Il est assez courant qu'un sketch ou une librairie développée sur un Arduino à CPU de modèle X ne fonctionne pas sur d'autres modèles.
D'un modèle de CPU à un autre, les fonctionnalités des pins ne sont pas forcément les mêmes. C'est notamment le cas pour des pins supportant ou non des interruptions.
Ca oblige d'aller voir un peu la doc des CPU pour lesquelles un sketch ou une librairie a été développée. Ou de s'intéresser plus aux pins utilisés. Puis de réaffecter les pins dans le sketch, voir dans les librairies qu'on utilise.
Parfois, réaffecter des pins permet de "porter" du code d'un modèle de CPU à un autre.
-
Bonjour,
J'arrive ... tardivement sur ce topic intéressant : merci pour le partage !
A la sortie de l'UNO R4 , comme beaucoup , je l'avais balayé du revers de la main : trop cher , trop lent , gaspillage des broches du microcontrôleur Renesas.
Mais il avait des choses intéressantes , comme un fonctionnement en 5v , pratique pour le S88 , l'I2C, et les accessoires de mon cru , à base de 74HC595 ou de 74HC165 , entre autres ; ainsi que la présence d'un comparateur analogique , qui me sert pour l'interface avec Loconet.
Depuis peu , on trouve des clones chinois pour cette carte , dont les prix sont abordables ; concernant la lenteur (48MHz pour un cortex M4 , c'est très peu , comparé aux 133MHz double coeur d'un Pi Pico , imbattable en prix) . Là aussi , on doit pouvoir s'en sortir en utilisant la richesse des périphériques HW , le DMA , en hiérarchisant les priorités des interruptions ...
Je me suis donc -rapidement- (lire : même si ça m'a pris du temps , je n'ai fait qu'effleurer) , penché sur le code de Matth_76 , dans l'optique de voir si on ne peut pas le faire évoluer afin d'y incorporer un cut-out Railcom , proprement réalisé.
Le code est brillant (pour peu que mon niveau définitivement crasse en C/C++ ne me permet pas d'en juger) , et surtout , très important pour moi , il respecte l'excellent travail de de Gregg E. Berman , en faisant générer des signaux nickels par un HW maîtrisé , ceci à l'opposé de certains qui on cru bien faire de le réécrire en SW , ce qui génère des approximations plus ou moins acceptables.
Pour générer le cutout avec le motor shield (officiel ou clone) , si on prend par exemple le canal A , il faut faut pendant le cutout , mettre la broche DIRA à LOW , en même temps que le la broche BRAKE-A soit au niveau HIGH. Je pense que c'est faisable , car le signal DIRA est sur le canal timer GTIOC6B , alors que le BRAKE-A est sur GTIOC7B . Il "suffit de" démarrer les timers 6 et 7 simultanément , et s'assurer par la suite qu'ils comptent les mêmes périodes : ainsi , les 2 timers resteront synchronisés . Pendant le cut-out , le BRAKE-A est donc à HIGH , et il reste sur LOW (duty=0) le reste du temps.
Le problème , c'est que le timer 7 est aussi (le seul) utilisé pour le signal BRAKE-B , donc sa sortie GTIOC7A : on ne peut donc pas également faire fonctionner le cutout sur la voie de programmation , c'est l'une où l'autre. (on pourrait faire fonctionner quand-même , en synchronisant les packets "main" et "programm" mais ce serait lourd , je préfère ne pas en parler).
Une solution , c'est de se passer du shield moteur , utiliser par exemple le POLOLU MC33926 MOTOR SHIELD . On n'est plus dans le mécaniquement stackable , mais on peut arranger le câblage pour trouver un timer libre pour le signal BRAKE-B ; le plus élégant serait de mettre DIRA et BRAKE-A sur le même timer , et pareil pour le B (sur le Pololu , ça s'appelle autrement , mais au final , ça marche pareil) . Dans ce cas , il serait aussi intéressant d'utiliser la carte genre gros NANO de chez WeAct , ce qui permet de retrouver les broches perdues du Renesas ; il faudrait alors aussi y raccorder un ESP32-S3 , en considérant les tensions différentes.
Voilà juste une 1ère réflexion , je n'ai rien testé.