Messages

16

Discussions ouvertes / Petit coup de pouce ?

« le: novembre 19, 2021, 10:07:47 am »

Bonjour à tous !

Comme vous le savez, LaurentR et moi avons lancé il y a quelques mois la société Ultimate Models, afin de proposer au plus grand nombre certains montages comme les rampes d'animation lumineuse, des décodeurs Open Source, etc.

Nous avons lancé il y a 3 jours une campagne de financement participatif pour nous aider à "amorcer la pompe".
Cette campagne soutient un projet spécifique : l'adaptation au monde des grandes échelles du contrôleur d'animation lumineuse.

Pour autant, derrière ce nouveau produit c'est bien l'ensemble du projet d'Entreprise dont il est question.

VOUS POUVEZ NOUS AIDER !

Chaque euro compte, tous les soutiens sont les bienvenus. Que vous soyez fan de ce que nous faisons ou que vous ayez simplement envie de soutenir une jeune startup, même les plus petites contributions feront la différence à la fin !

Alors si vous avez 5 ou 10 € à mettre dans un projet, n'hésitez pas à nous soutenir : rendez-vous sur KICKSTARTER et cliquez sur le bouton JE SOUTIEN CE PROJET.



Merci à tous ceux qui nous aideront à avancer, et bon week-end à tous.

Sébastien.

17

JMRI et Arduino / Re : Pas de communication avec décodeur

« le: octobre 18, 2021, 10:46:09 am »

Bonjour : cela signifie que la lecture des CV depuis la locomotive ne fonctionne pas.
Lorsque vous demandez l'ajout d'une loco, l'application tente d'identifier le décodeur en lisant plusieurs CV : 1, 7, 8, etc...

Si la loco "gigotte" durant cette opération c'est que les commandes de lecture lui arrivent bien...mais que le boitier DCC++ n'arrive pas à lire la réponse du décodeur depuis la voie....autrement dit que la mesure du courant consommé sur la voie de programmation ne marche pas.

Quel schéma avez-vous utilisé pour votre montage et, surtout, quel composant pour la mesure de courant ? Et comment l'avez-vous monté ?

18

Composants / Re : Nouveau ATtiny 417, 814, 816, 817

« le: septembre 17, 2021, 08:29:44 pm »

On les trouve un peu partout : mouser, farnell, radio spare....
Tu as deux séries : DA et DB, peu de différences. Quasiment compatibles broches à broche à une broche près, qui se gère avec une seule et unique résistance à implanter ou pas.

19

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 17, 2021, 02:56:54 pm »

Tu as remarqué que tu avais 732 paquets DCC émis, et 732 "second half" d'un bit à UN qui étaient plus longues d'une microseconde ?

Lorsque tu utilises le RMT en mode LOOP, pour envoyer une cyclique une trame unique finie, il "perd" un cycle après le dernier bit de la trame, le temps de repartir au début. C'est dans la doc. Tu as donc un bit à UN (le bit de fin de ta trame je pense) dont la seconde partie dure une uSec de plus.

Normalement, en mode WRAP AROUND, dans lequel le buffer d'émission est saturé, ce phénomène ne se produit pas.
En mode CYCLE (LOOP) que tu as utilisé, le RMT identifie la fin de la séquence par le marqueur 0/0 de la liste, ce qui explique le cycle perdu....en mode WRAP AROUND, le buffer est saturé à 100% et il n'y a pas de marqueur de fin....donc pas d'introduction d'un cycle perdu.

Théoriquement !

A vérifier dans la pratique.

20

Composants / Re : arduino nano : faut-il se dépêcher d'en acheter ?

« le: septembre 17, 2021, 02:50:13 pm »

64DB32 : bon composant, bonne évolution par rapport aux 4680X et quasi identique en brochage. Nos cartes actuelles sont compatibles avec le 64DA, le 64DB et les 480X....

J'ai récupéré un kit d'évaluation STM8 pour jouer avec....juste pour avoir une idée plus précise du gap....

21

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 13, 2021, 04:48:35 pm »

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.

22

Vos projets / Re : Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 10, 2021, 08:39:59 am »

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...

23

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 09, 2021, 06:54:13 pm »

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....

24

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 09, 2021, 06:27:30 pm »

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.

25

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 09, 2021, 06:22:00 pm »

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.

26

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 09, 2021, 05:41:41 pm »

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

27

Débuter / Re : Sortie PWM / DIR

« le: septembre 09, 2021, 03:40:14 pm »

La mesure de 2.3 volts sur la sortie PWM laisse supposer que le signal est bien là et correctement modulé.
S'agissant d'une modulation symétrique ON/OFF, l'intégration faite par le multimètre va relever une tension moyenne de l'ordre de VCC/2, soit environ 2.5 volts.

A partir de là, si l'alimentation est bien présente sur le shield moteur, vous devriez pouvoir piloter vos décodeurs en mode OPERATION : controle de moteur, touches de fonction.

La partie SERVICE (lecture de CV) est plus sensible : elle suppose une lecture de la consommation de courant bien au point, ça reste un sujet délicat...

28

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 09, 2021, 03:38:20 pm »

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.

29

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 09, 2021, 10:54:17 am »

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...

30

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 09, 2021, 10:15:32 am »

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....

Maintenant j'ai pas vu de réponse la question relative à des tests sur ESP en modulant la priorité des task de génération....@Thierry tu peux m'en dire plus sur le code (je n'ai pas regardé, sincèrement...)