projet centrale "LaBox" wifi DCC++ Can

[AmadeusHF]

J'ai trouvé quelques remarques relatives à la gestion précise de délais sous FreeRTOS....en particulier pour un utilisateur qui cherche à réaliser des délais de quelques microsecondes dans une tache :

A Semaphore that is given in an ISR and waited for in the delay function is one good way to implement shorter than a tick delays/periods. If the operation to be done is simple/quick enough, it could even be done in the ISR.

This works well for delays on the order of a 100us or longer (depending on the speed of your processor). Note that the actual delay in the function will be a bit longer than the timer setting as you have the ISR processing delay, and the subsequent task switch (and possible additional delays if a higher priority task becomes ready)

This doesn’t work well for short (like 5us) delays  where you really need a precise value. That isn’t the time frame that an RTOS is aimed at. For that you either need “hardware” to do it, or you disable interrupts and do precisely timed stand alone code.

S'agissant d'une méthode courante (un wait fait sur un signal) pour séquencer du code, vous noterez la remarque précisant que le scheduler assurera une précision suffisante pour des timings de l'ordre de 100 uSec, mais que la précision sera très relative en deça.....Avec comme conséquence de de voir bypasser les fonctions usuelles de l'OS pour mettre les mains dans le cambouie...

[Dominique]

Si effectivement on arrive pas à générer un signal stable directement avec l'ESP, oui il faut confier ça à un composant externe. Plutot qu'un FPGA j'aurais tendance à garder un petit CPU 8 bits facilement sourçable et que tout le monde sait programmer....

Un petit ATtiny pourrait être retenu (ou un modèle compact plus approvisionnable a moyen/long terme).
Le fait  que le principe des registres dans DCC++ et DCCpp permet de construire et mettre en file d’attente les commandes DCC. Le transfer dans le microcontroleur annexe sans contrainte de temps réel (celui-ci émet des IDLE quand son tampon est vide) soulagerait l’ESP32. Évidemment une nouvelle version du PCB serait à faire.

Dans une version antérieure du projet que j’avais tenté avec un ESP8266, j’utilisais un Nano avec un DCCpp minimal alimenté par des commandes DCC++ via I2C. Là ce serait encore plus simple, je pense. 

[AmadeusHF]

Oui ça revient à faire un sous-système autonome qui gère le bus, donc une version simplifiée de ce que fait DCC++.
SPI, UART, I2C, le moyen de communiquer est assez large de choix. En prototypage, une version UART me semble facile d'accès puisqu'il n'y a pratiquement rien à coder de particulier et que quelques cables dupont suffisent à valider.

Par contre effectivement ça impose une nouvelle carte.

[AmadeusHF]

J'ai continué à explorer en détail la spec de l'ESP32 et je suis tombé sur un périphérique que je n'avais jusque là pas regardé : le transmetteur RMT (normalement prévu pour envoyer/recevoir des codes de télécommande, d'ou son nom).

Ce périphérique est prévu pour générer une suite de pulsations sur une broche de sortie, à partir d'une liste qu'on lui fourni dans un buffer.

Chaque élément de la liste indique la durée de la pulsation ainsi que l'état haut ou bas du signal durant cette pulsation. A priori très exactement ce que l'on cherche à faire pour émettre une trame complète.

Vous avez expérimenté ce générateur ? Sachant qu'il peut fonctionner aussi en récepteur (décodeur), pour lire un signal. Je vais le mettre en oeuvre pour la réception du DCC à priori....des retours à ce sujet ?

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/rmt.html

[Thierry]

Bonjour

La partie RMT de l'ESP32 est maintenant utilisée par l'Esp32CommandStation d'Atany https://github.com/atanisoft/ESP32CommandStation pour la génération des trames DCC. Ca semble bien correspondre au besoin, mais je ne me suis pas penché dessus. C'est un peu le même principe que le PWM qui lui aussi utilise des alternances bien calibrées... On peut imaginer que l'adoption de cette fonctionnalité de l'ESP32 est intervenue pour corriger les mêmes problèmes de timing que nous.

[AmadeusHF]

De ce que j'en lis dans la doc, c'est assez trivial à utiliser.
Tu configures le diviseur d'horloge à 80 pour avoir une unité de pulsation de 1 uSec.

Tu fournis une liste de demi-pulsations exprimées en uSec...la taille de la liste en émission n'est pas limitée, donc tu peux fournir la séquence de bits complète d'un paquet.

Tu démarres l'émission et ta trame est générée dans son coin.
Tu boucles sur le "wait done" pour passer à la suite, ou tu fournis une callback qui sera appelée sur fin d'envois.

Lorsque tu n'as rien à envoyer tu peux demander au RMT de boucler sur une liste. Il suffit de charger une liste contenant un "1" et tu as ta modulation de repos....

Et si aucun paquet à envoyer durant 30ms....et bien il faut insérer l'inévitable IDLE de la norme.

[Dominique]

UN rapide coup d'oeil sur les exemples montre l'utilisation de l'ESP-IDF.

Comment intégrer un driver RMT dans le code Arduino ?

[AmadeusHF]

Tu as toujours accès aux fonctions de l'API meme avec le framework Arduino : le framework est une surcouche aux API, donc il suffit de faire les bons #include pour bypasser Arduino.

[Dominique]

effectivement le fichier RMTTrackDevice.cpp fait tout le boulot !
https://github.com/atanisoft/ESP32CommandStation/blob/master/components/DCCSignalGenerator/RMTTrackDevice.cpp

[AmadeusHF]

Effectivement.
Un poil compliqué vu qu'il implémente un virtual file system pour ça....mais en tout cas le code y est.

A noter que ce code est sous-optimal niveau DCC : la trame génère plusieurs bits 1 inutiles en fin de paquet.

Je rappelle ce que j'ai déjà dit : la transmission du dernier octet se terminant par un bit à 1 qui indique qu'il n'y a plus d'octet à suivre (sinon on aurait un bit BYTE START = 0), ce bit à 1 peut faire partie du préambule du paquet suivant.

Ici le code génère un 1 marqueur de fin d'octet
+ un 1 marqueur de "fin de paquet" qui n'existe pas dans la norme
+ insertion d'un 1 supplémentaire annoté "RMT" dans le code

Suivra le préambule du paquet suivant....constitué de 1 !

Donc trois bits de perdus à chaque trame....

[trimarco232]

"on" (le monde est petit) m'avait parlé du RMT, mais j'en suis resté au PWM parce qu'il m'a semblé que le RMT ne permet pas de générer le cutout du railcom (je suis dans le principe de réserver cette possibilité) ... mais si Atani l'a fait, on va y jeter un coup d'oeil

[trimarco232]

Donc trois bits de perdus à chaque trame....

qui peut mieux faire ?

[AmadeusHF]

il m'a semblé que le RMT ne permet pas de générer le cutout du railcom

Ca n'est qu'un moyen de moduler l'état d'une PIN. En qui cela t'empeche-t-il de décider périodiquement de forcer l'état bas de la broche pour couper le jus ? C'est même exactement l'inverse ici : tu pourrais très bien imaginer insérer un état bas de 488 uSec dans la séquence que tu émets.

Enfin bref....

Il reste néanmoins un point que ce dispositif ne gère pas c'est la continuité du signal en dehors d'une trame donnée. Je vais aller en profondeur dans le code voir ce que ça donne...

[AmadeusHF]

Quelques retours sur l'usage du RMT après expérimentation intensive.

Le système n'est PAS utilisable pour RECEVOIR du DCC, meme si la spec pourrait le laisser entendre.
Sa mise en oeuvre est relativement simple et on peut arriver rapidement à faire une acquisition de signal fiable MAIS....

Mais ce composant ne PEUT PAS réaliser une acquisition d'un signal continue : il stocke ses mesures dans un buffer limité en taille, et il ne livre ce buffer à l'application (via interruption) qu'une fois qu'il s'est arrété de traiter le signal...ce qu'il fait uniquement quand le signal passe à un état de repos : signal stable plus longtemps qu'un délais configurable.

Or en DCC, le signal est modulé et continu : sauf en cas de cutout, on a pas d’arrêt des alternances puisqu'entre deux paquets on doit remplir avec des UN.

De fait, si on demande au RMT de faire la lecture du signal il se bloque en erreur après quelques 100ème de secondes.

Si on le configure pour considérer les ZERO (plus long) comme délais d'arret, il arrive à échantillonner parfaitement tous les UN.

Bref : pas fait pour ça, il est conçu pour faire l'acquisition de trames finies, telles que celles d'une télécommande !

En revanche, en émission, il possède un mode à buffer CIRCULAIRE qui permet d'injecter un flux en continu dans le système...avec une interruption levée quand une fraction du buffer est consommée (ce qui permet de le recharger).

Je n'ai pas essayé ce mode....mais ça doit le faire.

[Dominique]

En revanche, en émission, il possède un mode à buffer CIRCULAIRE qui permet d'injecter un flux en continu dans le système...avec une interruption levée quand une fraction du buffer est consommée (ce qui permet de le recharger).

Je n'ai pas essayé ce mode....mais ça doit le faire.

Merci Sébastien : c’est dans ce mode émission que la solution aux problèmes de timing de LaBox devrait se trouver.
J’ai vu qu’il existe des bibliothèques Arduino à base de RMT. Je n’ai pas pu essayer mais cela doit pouvoir s’implémenter dans l’environnement Arduino.