SPROG, Arduino et électronique

[notix]

Merci pour ta réponse. Mais je ne serai pas aussi aventureux que toi. J'ai vu les articles de train35 qui m'ont incités à envisager cette voie. Je partirai plutôt d'un module tout fait à base de LMD18200 (plus cher mais apparemment fournissant un signal de meilleur qualité qu'un L298N).

[Patgo]

Bonjour NOTIX,
Effectivement le LM18200 est plus récent, mais si je puis me permettre, en lisant les différents articles sur l'arduino et le LM18200 (je n'ai pas fouillé dans tout le net) ceux qui arrivent en 1er font référence à un arduino qui pilote un lm18200 pour 1 seule loco via un potentiomètre sur une entrée. C'est bien mais un peu short. Le site "Train35" fait aussi une impasse sur la commande de plusieurs locos ou alors cela devient très lourd avec des envois successifs du style: "Envoi adresse loco 1, attente 200ms, envoi adresse loco 1, attente 100ms, envoi vitesse loco 1, attente 100ms, envoi vitesse loco 1", puis on reprend tout pour la loco 2, etc...).
Si tu veux monter un Arduino+ booster pour un circuit avec plusieurs locos, il te faudra réaliser un programme avec une commande plus directe du style "O- espace- adresseenhexa-espace-3F-espace-vitesseenhexa-espace-BytedeControle" avec pour la vitesse: 128 (=0) à 255(FF)(=Vmax) pour la marche avant et 0 (=0) à 127(=Vmax en marche arrière). Voir la norme NMRA S-9.2 DCC Communication Standarts (2004)).
J'ai réalisé un programme de ce style et si tu veux je peux te l'envoyer sur ta messagerie mais sache que j'envoie les commandes à l'arduino via un programme en VB6 et que si tu n'as pas VB6 il te faudra programmer quelque chose d'équivalent.
PatGo

[notix]

Effectivement de nombreux exemples sont fait à partir d'un potentiomètre car ils ne vont pas dans le sens d'une informatisation complète du système. C'est aussi le cas des exemples fournis avec la librairie CmdrArduino, mais le principe est là : au lieu de lire la valeur du potentiomètre il suffit d'interpréter les commandes arrivant sur le port série.
Pour commander plusieurs locomotives, la question que je me pose est plutôt de savoir s'il faut gérer la répétition des commandes sur l'Arduino (tâche trop importante pour le CPU de la carte ? taille de la mémoire limitée sur ma UNO ?) et du côté de l'ordinateur (goulot d'étranglement au niveau du port série/USB ?). Je pencherais plutôt pour la deuxième solution pour soulager la CPU de l'Arduino (d'autant plus qu'elle doit aussi dans mon cas gérer les commandes de la signalisation, des aiguillages et de la rétro-signalisation) et ainsi assurer une bonne temporisation de l'envoi des commandes vers le booster.

On fait côté ordinateur un programme gérant un thread par locomotive. Ce thread traite les commandes produites par l'utilisateur manipulant l'IHM et se charge de la répétition de celles-ci avec un timer. Tous les threads envoient leurs commandes vers un scheduler chargé de les envoyer sur le port série/USB. Puis côté Arduino, les commandes reçues sont interprétées et envoyées au scheduler de la librairie CmdrArduino pour finalement être envoyées au booster.
Pour le format des commandes entre l'ordinateur et l'Arduino, on peut s'inspirer des commandes envoyées au SPROG par DecoderPro, elles sont visibles dans la console. Malheureusement je n'arrive pas à trouver une doc listant toutes ces commandes SPROG et fouiller dans le code de JMRI s'avère un peu fastidieux ... mais s'il faut en arriver, ça pourra se faire. As-tu eu accès à ces infos avant de faire ton programme en VB ?

La norme NMRA n'est pas très prolixe en information, il faut tâtonner un peu ... voir beaucoup

[Aldayo]

Pour les commande qu'envoie JMRI au SPROG, demande à Ferrari, c'est celui qui a développé un ''concurrent'' en français de JMRI et il œuvre sur ce forum (centre de programmation DCC)

[Patgo]

Bonjour à tous,
Désolé de ne pas vous avoir lu avant, mais ya pas que le train il y a aussi qq vacances .
Donc pour la programmation de l'arduino, il ne faut pas que le signal sur les rails soit à 0 ou à 1 trop longtemps (on est en numérique tout de même!...) donc j'envoie un ordre sur la loco (via une commande "void serialEvent()") puis dans la boucle ('void loop()')je l’exécute 5 fois (pour être sûr que le décodeur a bien compris la commande) et enfin je boucle sur une suite non stop de bit 0 (mais cela pourrait être aussi des bits 1) tant que l'arduino ne reçoit pas de nouvel ordre; pour la définition des bits 0 ou 1 voir par exemple le site "Train35". Donc l'arduino envoie 80- 95% du temps des bits 0 et l'UC est chargée à quasi 100%.
Une autre solution utilisée entre autre par quelques uns est d'envoyer toujours le même ordre jusqu'à ce que l'arduino reçoive un ordre suivant. Dans les résultats cela revient au même (ou en tout cas je n'ai pas vu de différence sur les locos).
Enfin je suis en train de programmer une autre solution qui est d'utiliser le "void setupTimer2()"; Ce Timer2 joue sur les interruptions; voir à ce sujet les nombreux documents sur le site Arduino. L'avantage est que l'arduino exécute une boucle avec un certain programme (éventuellement autre que la génération d'un signal DCC) et aprés quelques cycles d'horloge (58 ou 116 microsecondes) génére une interruption qui va mettre la sortie DCC à 1 ou 0. L'UC doit être moins chargée mais je vous le dirais dans une semaine environ car je n'ai pas fini le programme.

[Patgo]

Ah les commandes DCC !...

Effectivement je me suis gratté la tête plus d'une fois et pour être sûr de la solution j'ai monté "un mouchard" (un arduino d'ailleurs!...) qui espionnait les commandes reçues et me les convertissait pour affichage sur le "moniteur Arduino". En fait c'est à la fois compliqué et simple; Si on ne veut pas se tromper, il y a 2 modes à connaitre:

1 - Pour l'adresse, la vitesse et la direction, on envoie:
"O", Adrhexa, 3F, Vitessehexa, Ctrlhexa avec Adrhexa l'adresse de la loco en hexa, "3F" pour indiquer que la vitesse est codée sur 128 pas, Vitessehexa = vitesse de la loco en hexa et Ctrlhexa = mot de contrôle intégrant dans des fonctions XOr (Ou exclusif) l'adresse, 3F et la commande. Pour la vitesse, de 0 à 127 (donc de h0 à h7F) la loco marche en marche AR de plus en plus vite, et de 128 à 255 (h80 à hFF) en marche avant. 1 et 129 (h81) sont des stops rapides.
On envoie donc qqchose du genre ""0 03 3F FF C3" pour adresse 3, MAV max. Nota: l'en-tête est la lettre O majuscule pas un zéro!...
Le message binaire a envoyer sur les rails est donc: preambule, adresse, bit0, 3F, bit0, commande, bit0, controle, bit1, pausetemps avec preambule = 14 - 15 fois bit1 puis bit0 et en fin une pausetemps = 25 fois bit0 apres un bit1

2 - Pour les fonctions, on envoie:
2 - 1 Fonctions de F0 à F12 (groupe 1 et 2)
O, Adrhexa, fonctionhexa, Ctrlhexa
Donc un message: preambule, adresse, bit0, commande, bit0, controle, bit1, pausetemps

2 - 2 Fonctions F213 à f20 (groupe 3)
O, Adrhexa, DE, fonctionhexa, Ctrlhexa
Donc un message = preambule, adresse, bit0, DE, bit0, commande, bit0, controle, bit1, pausetemps
Voilà c'est un résumé rapide et spécifique (car 128 pas et vitesse,et fonctions) de la norme DCC.

[notix]

Bonjour,

Concernant, ta première solution, la répétition de la commande à traiter est une bonne initiative mais pourquoi envoyer ensuite autant de zéros ? Quelques uns suffiraient non ?

Pour l'utilisation des interruptions, je ne vois pas trop où tu veux en venir ? Si l'ordinateur ou l'opérateur envoie une commande à l'Arduino, celui n'a qu'à gérer un compteur. A chaque boucle, il envoie la commande puis la répète tant que le compteur (dans ton exemple précédent 5) n'est pas écoulé ? Dans les boucles suivantes, il envoie un certain nombre de zéros puis s'arrête jusqu'à la réception de la prochaine commande.

Attention, le code contenu dans la fonction d'interruption doit être le plus court possible pour ne pas gêner le fonctionnement global du programme. Souvent il vaut mieux uniquement modifier un flag qui déclenchera le traitement dans la fonction loop().

[Patgo]

Cher Notix,
1 - Pourquoi des zéros (ou des uns): parce que le DCC fonctionne en alternatif, on ne peut laisser le niveau à 12 Volts (marche plein pot de la loco dans ce cas) ou 0 Volt (arrêt); il faut donc commuter le signal sur les rails en permanence.
Donc soit on envoie des bit0 (ou 1), soit on exécute la commande X fois jusqu'à ce qu'un ordre suivant la remplace.
2 - Première idée: poser des bit1 et bit0 dans la boucle "loop" (comme dans "train35" par exemple): pendant que la fonction "delay" attend 58 ou 116 us l'UC ne fait rien sauf attendre.
Deuxième idée: Utiliser la fonction interruption et la fonction "TIMER2", l'UC compte des cycles d'horloge pour atteindre 58us (ou 116) et pendant ce temps là, la "loop" continue de se dérouler et exécute un autre programme. A la fin de la boucle, si un "SerialEvent" a été généré, le programme à l'intérieur de "l'event" s'exécute et envoie un mot (composé de 0 et de 1) au TIMER2 qui générera en temps mort le signal DCC. Après le "SerialEvent" on sera revenu au début de la boucle "loop".
J'ai fini le programme (commandé par le PC et non par des potentiomètres comme dans certains exemples sur le net), cela fonctionne mais encore une fois j'ai fais cela pour le fun car le SPROG3 me semble plus sûr à utiliser sur mon circuit avec plusieurs locos (et je l'utilise plutôt que l'arduino + ampli); mon arduino 2560mega me sert surtout pour les sorties aiguillages et feux de signalisation.

[notix]

Merci Patgo pour ces éclaircissements

Pour le point 1, effectivement j'avais lu par ailleurs qu'il faillait renvoyer la commande à intervalle régulier, mais je n'avais pas capté que c'était pour ne pas laisser la tension en permanence à 12 V. Ce que tu dis c'est qu'en fait on peut se contenter d'envoyer des zéros ?

Pour le point 2, quand tu parles de Timer2 tu évoque la librairie MsTimer2 ? On peut dire qu'en absence de commande tu envoies des zéros; quand une commande arrive sur le port série, tu stockes sa valeur binaire dans un coin, et lors de la fonction d'interruption tu dépiles cette valeur bit par bit; puis une fois la command envoyée, tu renvoies des zéros. Ai-je bien compris ?
Effectivement c'est plus optimal de jouer avec les interruptions pour générer les impulsions DCC. Mais il n'y a pas trop d' "interférences" entre la loop et la fonction d'interruption ?

Pour le moment, je me contente aussi de gérer aiguillages, signalisations et rétro signalisation. Le DCC ce sera pour plus tard ... mais je me renseigne