D18: Un décodeur d'accessoires DCC à réaliser soi-même

Les commandes numériques du réseau (appelées à tort "digitales") sont l'avenir du train miniature. Mais comment choisir, comment sauter le pas, avec ou sans ordinateur ? Autant de questions dont les réponses se trouvent dans l'expérience des uns et des autres…

Modérateur : MOD

Répondre
Avatar du membre
papat400
Messages : 14
Enregistré le : mer. 19 juin 2019, 20:19
Echelle pratiquée : HO
Prénom : Thierry
Localisation : Florennes - Belgique
Âge : 55

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par papat400 » sam. 06 juil. 2019, 15:38

Autre souci potentiel pour la sauvegarde sur l'arduino :

Le cycle d'écriture en EEPROM dure 3,3 ms par octet.
Or, dans le code d'Ulysse, l'appel à la fonction fast_loop() doit être effectué au minimum toutes les 5 ms ; il y a d'ailleurs plusieurs appels à cette fonction dans le croquis pour garantir cela.
Ma crainte est que le temps restant (disons 1,6 ms) soit un peu court pour le reste du programme. Et vu mon niveau, pas facile d'estimer si cela est suffisant. Je sais que ça va vite, mais sans certitude chiffrée la crainte persiste.
Il n'y a apparemment pas de Watchdog natif sur arduino. De ce qui me reste de mes connaissances en assembleur (ça fait 35 ans quand même :roll: ), le système va planter par débordement du stack pointer si on ne lui laisse pas boucler la fonction loop().

Reste la piste de la centrale, mais là faudrait que je m'attaque au Python ... pfff sale bête ça ! :lol: :lol: :lol:

Qu'en pensent les spécialistes ?
Merci pour votre aide. :wink:

Trimarco232
Disert
Messages : 420
Enregistré le : ven. 23 févr. 2018, 14:02
Echelle pratiquée : HO
Prénom : marco

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par Trimarco232 » sam. 06 juil. 2019, 16:35

le système va planter par débordement du stack pointer si on ne lui laisse pas boucler la fonction loop()
normalement non
ce que tu crains, c'est la saturation de la ram ; la ram se remplit :
à partir de son début pour les variables et choses du genre
à partir de sa fin pour la pile
si les 2 se télescopent vers le milieu, ça plante

pour que la ram ne sature pas depuis son début, il faut éviter de multiplier les variables, comme des tableaux qui devraient rester en flash
pour que la ram ne sature pas depuis sa fin, il faut éviter de multiplier les appels récursifs à des fonctions, qui à chaque fois rempliront la pile avec la sauvegarde des variables et des registres, sans la vider

si tu ne laisse pas le temps à une fonction de se boucler, elle mettra simplement + de temps pour se boucler ... la pile n'est pas impactée par cela, mais peut-être ce qu'on attend du programme
"Il n'y a apparemment pas de Watchdog natif sur arduino"
rien n’empêche sa mise en oeuvre
si c'est inutile car on a évité tous les risques de plantage, c'est mieux ...
Reste la piste de la centrale, mais là faudrait que je m'attaque au Python ... pfff sale bête ça !
ça se passera bien, le plus pénibles c'est c, c++ !
avec quel mcu la centrale ?

Avatar du membre
papat400
Messages : 14
Enregistré le : mer. 19 juin 2019, 20:19
Echelle pratiquée : HO
Prénom : Thierry
Localisation : Florennes - Belgique
Âge : 55

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par papat400 » sam. 06 juil. 2019, 20:52

normalement non
ce que tu crains, c'est la saturation de la ram ; la ram se remplit :
à partir de son début pour les variables et choses du genre
à partir de sa fin pour la pile
si les 2 se télescopent vers le milieu, ça plante
C'était ce que je voulais dire :) si la loop ne boucle pas, dans mon esprit cela comprenait des appels successifs à d'autres fonctions ; donc le stack "monte" (ou se remplit c'est comme on veut) et vient dire bonjour à la partie de la ram qui contient des données (variables, programme ... je n'ai pas étudié l'architecture mémoire du bestiau) en l'écrasant joyeusement. Et plantage donc :cry:

Pour le watchdog, en effet d'autres l'ont déjà "inventé" pour arduino. Et si c'est bien programmé en effet il n'est pas nécessaire. Mais je bosse dans l'électricité / automation industrielle et je ne connais pas un automate qui existe sans ! Principe de précaution sans doute.
avec quel mcu la centrale ?
Ma centrale est un laptop avec le logiciel Desktop Station de Yaasan reliée à un UNO avec shield Can Bus pour faire la liaison avec le boîtier 60113 Märklin. Ce dernier sert juste à générer les signaux MFX - DCC.
Des infos sur le shied Can Bus sont disponibles ici. A savoir : c'est une page Wiki réalisée par un commerçant (avec lequel je n'ai rien à voir) mais très bien détaillée techniquement.
C'est le logiciel Desktop Station qui est programmé (principalement si j'ai tout compris) en Python.

Lulu_ho
Causant
Messages : 280
Enregistré le : ven. 16 déc. 2016, 12:24
Echelle pratiquée : HO
Prénom : Ulysse

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par Lulu_ho » dim. 07 juil. 2019, 13:33

Une petite précision sur l'écriture en eeprom de l'arduino. Écrire en eeprom prend bien 3.3ms d'après la datasheet, mais cela ne veut pas dire que la fonction EEPROM.write(adresse,data) prend 3.3ms avant de retourner ... Si on regarde comment cette fonction fonctionne, elle attend que l'eeprom soit libre, demande la programmation puis retourne. S'il n'y a aucune opération en cours sur l'eeprom avant l'appel de la fonction, elle retourne presque immédiatement. Le matériel se chargeant de finir l'écriture tout seul... Bien entendu il faut écrire qu'un octet (byte), sinon pour un int, composé de plusieurs byte, il y a plusieurs écritures d'où l'attente de 3.3ms entre les bytes.

Il est préférable d'utiliser EEPROM.update qui n'ecrit la valeur que si elle est différente de celle déjà écrite.

Comme un paquet DCC dure plus de 3.3ms, a la réception d'une demande de déplacement d'un aiguillage, il suffit d'appeler EEPROM.update pour stocker la nouvelle position. Comme il n'y a pas d'écriture en cours avant l'appel la fonction retourne presque immédiatement...

Je pars en vacances, j'espère qu'à mon retour tout cela marchera correctement :-) Bonne chance ...

Avatar du membre
Deimos_epIV
Intarissable !
Messages : 9247
Enregistré le : ven. 23 déc. 2011, 21:25
Echelle pratiquée : HO/DCC
Prénom : Claude
Club : MMF
Localisation : Montpellier (34)
Âge : 61

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par Deimos_epIV » dim. 07 juil. 2019, 14:40

Trimarco232 a écrit :
sam. 06 juil. 2019, 16:35
ça se passera bien, le plus pénibles c'est c, c++ !
Que lui trouves tu de pénible au C/C++ ? J'en suis arrivé à ne plus utiliser que ca ! ;)
Lulu_ho a écrit :
dim. 07 juil. 2019, 13:33
... un paquet DCC dure plus de 3.3ms, ...
Mais paquet de commande accessoires émis qu'une seule fois à chaque changement d'état.
Amicalement

Avatar du membre
Bug Killer
Éloquent
Messages : 338
Enregistré le : ven. 08 sept. 2017, 12:46
Echelle pratiquée : H0
Prénom : Jean-Michel
Site Internet : http://jmdubois.free.fr/dcc/
Localisation : Loir et Cher
Âge : 64

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par Bug Killer » dim. 07 juil. 2019, 15:25

C/C++ est mon langage de programmation majoritaire et préféré. Je ne l'ai jamais trouvé pénible, au contraire, j'apprécie la grande liberté et les grandes responsabilités qu'il confie à ceux qui l'utilisent.
Que la vapeur soit avec toi.

Avatar du membre
Deimos_epIV
Intarissable !
Messages : 9247
Enregistré le : ven. 23 déc. 2011, 21:25
Echelle pratiquée : HO/DCC
Prénom : Claude
Club : MMF
Localisation : Montpellier (34)
Âge : 61

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par Deimos_epIV » dim. 07 juil. 2019, 17:08

+1000
Et les pointeurs sont une vraie bénédiction ! :)
Amicalement

Trimarco232
Disert
Messages : 420
Enregistré le : ven. 23 févr. 2018, 14:02
Echelle pratiquée : HO
Prénom : marco

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par Trimarco232 » dim. 07 juil. 2019, 20:36

Que lui trouves tu de pénible au C/C++ ? J'en suis arrivé à ne plus utiliser que ca !
tout est relatif et tout est subjectif
simplement je dirais que pour moi, par exemple, le passage de visual basic à c/c++ a été douloureux au niveau de l'ergonomie ...
j'ai aussi eu l'occasion de faire un peu de micro python sur RPi, assez pour pouvoir rassurer papat400
Et les pointeurs sont une vraie bénédiction ! :)
je ne m'en sers pas ...
Les MCU que j'utilise pour mes décodeurs
c'est quoi (si ce n'est indiscret) ?

Trimarco232
Disert
Messages : 420
Enregistré le : ven. 23 févr. 2018, 14:02
Echelle pratiquée : HO
Prénom : marco

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par Trimarco232 » dim. 07 juil. 2019, 20:45

Ce dernier sert juste à générer les signaux MFX - DCC
ah le mfx ...

Avatar du membre
Deimos_epIV
Intarissable !
Messages : 9247
Enregistré le : ven. 23 déc. 2011, 21:25
Echelle pratiquée : HO/DCC
Prénom : Claude
Club : MMF
Localisation : Montpellier (34)
Âge : 61

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par Deimos_epIV » dim. 07 juil. 2019, 21:10

J'utilise les 9S08 de NXP ex Freescale ex Motorola, tout simplement parce que j'ai commencé avec leurs descendants au début des 80' donc... Je les connais bien !

Les pointeurs en C/C++... C'est la base ! Je suis passé du premier VB à Delphi (Pascal) mais je suis très vite passé au C/C++, en particulier pour les API Windows et l'énorme potentiel de ce langage (je fais abstraction de PHP pour les sites WEB).
Amicalement

Trimarco232
Disert
Messages : 420
Enregistré le : ven. 23 févr. 2018, 14:02
Echelle pratiquée : HO
Prénom : marco

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par Trimarco232 » dim. 07 juil. 2019, 23:12

en tant qu'amateur isolé, je n'ai pas touché aux API, je me suis débrouillé pour le rs232, le // et l'usb

merci pour le tuyau 9S08, ils ont l'air très bien vis à vis des stm8 que j'utilise ; ne leur manquerait que le qfn20 3x3mm ...
en tous cas mieux que les pic et les avr !

Avatar du membre
Deimos_epIV
Intarissable !
Messages : 9247
Enregistré le : ven. 23 déc. 2011, 21:25
Echelle pratiquée : HO/DCC
Prénom : Claude
Club : MMF
Localisation : Montpellier (34)
Âge : 61

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par Deimos_epIV » lun. 08 juil. 2019, 00:29

Je ne connais pas bien les AVR mais un peu les PIC. Les 9S08 sont plus simples: Un seul espace mémoire, ils sont très simples à mettre en œuvre et - cerise sur la gâteau - ils ne coutent pas bien cher, moins d'1 € HT pour le PL4 à l'unité !
(Trier par prix croissant les 420 références en stock chez Mouser !)

Pardon pour le hors sujet... Marco, si les 9S08 t'intéressent on continue en MP ou par mail.
Amicalement

Avatar du membre
papat400
Messages : 14
Enregistré le : mer. 19 juin 2019, 20:19
Echelle pratiquée : HO
Prénom : Thierry
Localisation : Florennes - Belgique
Âge : 55

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par papat400 » jeu. 18 juil. 2019, 17:41

Me revoici,

J'ai opté pour la solution EEPROM finalement, plus facile à mettre en œuvre rapidement que de potasser Python. Je m'y mettrai certainement un jour, en attendant cette solution a le mérite de fonctionner :)

Pour faire simple, voici le lien Github vers la page dédiée : https://github.com/papat400/DCC-accesso ... and-EEPROM

Les fichiers disponibles au téléchargement sont :
* LICENCE : j'ai inséré la même licence GNU qu'Ulysse, histoire de faire ça dans les règles.
* Nano...Eagle.zip : fichier archive concernant le PCB, contient les fichiers Eagle ainsi que le schéma et le design du PCB au format PDF.
* Readme.md : notes explicatives
* d188acc...eeprom.ino : croquis arduino pour le D18 modifié.
Au fait, l'avais-je dit ? Un ÉNORME merci à Ulysse pour son boulot !

Retour au sketch :
En résumé, seule une action sur un servo ou sur une sortie génère un upgrade de l'EEPROM. Et comme dit plus haut dans ce sujet, vu qu'on dispose d'au moins 100.000 écritures avant de claquer un byte de l'EEPROM, il y a de la marge !

Pour les servos pas de souci, je sauvegarde la consigne de position dans un byte par servo.
Les sorties, elles, sont sauvegardées dans un double octet (si aucun servo n'est utilisé, 16 sorties binaires sont disponibles).

Seule petite interrogation : considérant un byte de valeur quelconque, si un seul bit est modifié et que l'on fait un EEPROM.update : le byte entier est-il réécrit ou seul le bit modifié le sera-t-il ? Je crains que ce ne soit le byte entier, mais pas assez cherché pour trouver la réponse correcte ... :oops: :P
La "durée de vie" de l'EEPROM pour les sorties binaires dépendra assez bien de la réponse à cette question. En effet, une seule sortie affecterait un byte contenant 7 autres sorties ... ce qui diviserait par 8 la "durée de vie" de l'EEPROM, ce n'est pas rien.
Solution envisageable : utiliser un byte par sortie. Vu qu'il y a 1024 bytes disponibles en EEPROM, ce n'est certainement pas un souci.

Voilà, tout commentaire ou avis est le bienvenu :wink:
Bonne journée et à plus,
Thierry.

Avatar du membre
Deimos_epIV
Intarissable !
Messages : 9247
Enregistré le : ven. 23 déc. 2011, 21:25
Echelle pratiquée : HO/DCC
Prénom : Claude
Club : MMF
Localisation : Montpellier (34)
Âge : 61

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par Deimos_epIV » jeu. 18 juil. 2019, 18:17

Au minimum c'est l'octet mais la première chose à faire avant de mettre en œuvre de tels composants est de "potasser" leur datasheet ! ;)
Donc bien vérifier car certaines Flash/EEPROM ne s'écrivent que par "bloc" de x octets. Quelle est la référence exacte de l'EEPROM utilisée ?
Amicalement

Avatar du membre
papat400
Messages : 14
Enregistré le : mer. 19 juin 2019, 20:19
Echelle pratiquée : HO
Prénom : Thierry
Localisation : Florennes - Belgique
Âge : 55

Re: D18: Un décodeur d'accessoires DCC à réaliser soi-même

Message par papat400 » jeu. 18 juil. 2019, 21:39

Deimos_epIV a écrit :
jeu. 18 juil. 2019, 18:17
Au minimum c'est l'octet mais la première chose à faire avant de mettre en œuvre de tels composants est de "potasser" leur datasheet ! ;)
Donc bien vérifier car certaines Flash/EEPROM ne s'écrivent que par "bloc" de x octets. Quelle est la référence exacte de l'EEPROM utilisée ?
C'est celle du Nano, tout simplement (ATmega328).

Répondre