Messages

1

Vie du site rédactionnel et du forum / Re : Msport (Michel GOYARD) nous a quitté Samedi 16 Mars

« le: avril 11, 2024, 10:58:44 am »

Bonjour Dominique,

J'ai peu l'occasion de venir sur Locoduino depuis pas mal de temps, aussi je viens de découvrir la nouvelle.

Quand je pense aux piliers de la communauté Locoduino, Michel est bien entendu l'un des noms qui apparait dans le haut de la liste et, bien que n'ayant pas eu autant d'échanges que j'aurais pu le souhaiter, je n'oublie pas qu'il m'a accueilli avec beaucoup de sympathie quand j'ai repris le modélisme en 2021 et qu'il a spontanément participé aux quelques travaux que j'avais amorcé ici, tout comme tu l'as fait. Et je suis persuadé que nombreux sont ceux auxquels il a consacré de son temps ici ou ailleurs.

Qu'il repose en paix.

Seb

2

Bus DCC / Re : Bus DCC réitération des trames

« le: octobre 12, 2022, 07:57:07 pm »

La plupart des Command Station modernes (enfin .... pas trop vieilles) répètent de base l'ensemble des trames traction et les fonctions 0 à 12. C'est notamment le cas des Z21, Lenz 100 et 200, DR5000 et d'autres encore.

Pour beaucoup de ces centrales, des réglages permettent de choisir l'étendue de la répétition. On peut ainsi étendre souvent jusqu'aux fonctions 28...mais pas jusqu'à 68 dans la plupart des cas.

Maintenant il faut distinguer QUI prend l'initiative de la répétition : ça peut etre la centrale qui répète les trames DCC mais aussi la commande (MultiMaus, LH 100...) qui répète les commandes XpressNet ou LocoNet.

3

Bus DCC / Re : Re : paquet de diffusion générale d'arrêt

« le: mai 19, 2022, 07:33:49 pm »

de : doit accepter la commande DCC quelque soit l'adresse qui lui a été attribuée.

je comprends adresse courte ou adresse longue, reste à tester ...

donc pour l'arrêt d'urgence avec  < t 1 0 -1 1> sauf erreur.

Non ça ne fait pas partie des possibilités.
La commande "IDLE" = "Ne rien faire" sert à remplir le bus (à le moduler) en permanence même quand il n'y a rien à émettre. Ca fait "tourner" le décodeur qui identifie des trames valides et en déduit qu'il y a bien un système DCC actif sur la voie....ce qui lui indique de ne pas commuter en mode "compatibilité analogique".

La norme recommande d'émettre un IDLE  sur la voie au moins toutes les 30 millisecondes en l'absence de toute autre commande utile à destination d'une adresse donnée. Comme c'est une trame broadcast, elle sera vue par toutes les adresses.

4

Bus DCC / Re : paquet de diffusion générale d'arrêt

« le: mai 19, 2022, 04:31:27 pm »

Si : c'est une exigence de la norme que d'écouter les broadcast, peut importe la configuration (adresse courte ou longue) du décodeur. Deux commandes sont acceptées sur broadcast  : IDLE et EMERGENCY STOP.

5

Infos et bonnes affaires / Re : Création d'Ultimate Models

« le: février 20, 2022, 09:56:54 am »

Bonjour Dominique, je viens juste de voir ton message
Oui on est très fiers de l'article qu'a fait LocoRevue, ça nous amène beaucoup de visibilité, pas mal de monde nous découvre à cette occasion. Si les stocks de produit suivaient ça pourrait même faire des ventes !
Mais ça reste compliqué de sourcer certains composants : à plusieurs reprises on a du stopper des batchs de fabrication en raison d'une référence introuvable. Du temps et de l'argent immobilisés pour rien : pas simple.
En tout cas on avance du mieux qu'on peut. Régulièrement on nous demande d'adapter nos produits sur d'autres séries : il y a de la demande. C'est encourageant.

Seb

6

Composants / Re : Benchmark MCU

« le: janvier 21, 2022, 10:05:44 am »

Le nano every utilise un ATMEGA 4809 ce qui fait qu'on a 6 Ko de RAM au lieu de 2 Ko un fonctionnement "MEGA"....il faut utiliser un kit de base différent de celui du 328 pour compiler. La conséquence pouvant être que certaines librairies ne compilent pas.

Nous utilisons son petit frère le 4808 (32 broches au lieu de 48) sur nos rampes d'éclairage et décodeurs de loco. Le surplus de RAM est une bénédiction : ça permet une bien meilleur efficacité notamment de la partie décodage de flux, en autorisant un buffering que le 328 a du mal à supporter : entre la pile, les variables des 16 à 19 canaux d'éclairage et leurs animations...le 328 sature.

A noter que, avec son boitier de 48 broches, le 4809 du NANO EVERY propose un timer "B" de plus que le 4808.
Les AVR64 DA et DB, leurs successeurs, vont encore un peu plus loin en augmentant la fréquence maximale de 20 Mhz à 24 (mais souvent on restera sur 16 Mhz pour avoir la compatibilité avec beaucoup de bibliothèques !) et peuvent pousser jusqu'à 7 timers de trois types (A, B et C)

Dans tous les cas, le développement "Arduino" avec ces CPU ne pose pas de soucis particulier, surtout pour un usage courant. Et dès qu'on veut faire un peu plus que le tout venant, le pack MegaCoreX de MCUDude permet de s'affranchir des limites de l'offre de base Arduino et d'aller un peu plus loin en finesse.

L'équivalent n'existe pas encore à ma connaissance pour les AVR64...ce qui m'amènera probablement à faire le portage puisque nous allons utiliser ces CPU très bientot.

7

Composants / Re : Benchmark MCU

« le: janvier 18, 2022, 08:47:08 am »

C'est un peu le piège de tout ce "business" : la simplicité apparente qui caractérise aujourd'hui le monde de l'Arduino n'en élimine pas intrinsèquement la complexité sous-jacente : nous parlons de systèmes qui sont fondamentalement très complexes !

Par exemple pour déterminer si un timer peut ou ne peut pas servir à générer ou faire l'acquisition d'un signal DCC, il ne suffit pas de savoir qu'il y a X timers dans le processeur: il faut encore regarder comment ils fonctionnent !

On peut dégager quelques généralités, mais vraiment pas des tonnes....

Le fait est que l'ESP32 est plutot un processeur "généraliste" destiné à faire tourner de gros programmes peu techniques mais faisant appel à de la communication WIFI ou BT par exemple. Pour des fonctions techniques de bas niveau il lui faudra des coprocesseurs connectés.

Les petits CPU type ATMEGA ont, à l'inverse, toujours été très doués pour le traitement ou la génération de signal. Il y a des centaines de montage en ce sens sur le Net. En revanche ils sont peu efficients pour faire une IHM riche : pas assez de RAM ni de vitesse CPU.

8

Composants / Re : Benchmark MCU

« le: janvier 17, 2022, 03:46:17 pm »

De nos jours il y a très peu de compilateurs fondamentalement différents. GCC, le Gnu C Compiler communautaire est massivement utilisé comme base de fabrication des "déclinaisons" propres à chaque noyau de CPU.

Cela signifie que les fabricants de "CORE" versent à la communauté les éléments de très bas niveau permettant de générer un code (instructions machines) et que, à la fin, la compilation d'un programme donné sera toujours du ressort de GCC (tout comme son optimisation).

Par ailleurs, tout comme le choix d'un langage, le choix d'une architecture CPU dépendra de ce que l'on veut lui faire faire, et aussi de ce que l'on peut en attendre sur d'autres dimensions....comme par exemple le fait de s'intégrer dans une communauté dynamique Open Source ou pas.

Il faut aussi comprendre que les composants dont nous parlons ne sont pas de simples CPU : ce sont ce que l'on appelle des System On Chip (SOC), qui embarquent de nombreux périphériques dédiés à telle ou telle tâche...ce qui à la fin rend la comparaison de la partie CALCUL PUR du composant peu représentative de sa capacité à résoudre tel ou tel problème.

Exemple : un ATMEGA à 8 Mhz est parfaitement capable de décoder un flux DCC avec une précision chirurgicale. Un ESP32 devant traiter le même signal, pourtant de basse exigence (8 Khz environ) ne sera pas aussi fiable dans une telle tâche, ce malgré ses deux cores à 240 Mhz....

L'ATMEGA utilisera pour ça ses timers flexibles, capables de mesurer le signal en continu....ce que l'ESP ne sait tout simplement pas faire ! Aucun de ses composants périphériques n'est prévu pour mesurer EN CONTINU un signal....en revanche pour faire du BLUETOOTH, l'ATMEGA sera à la ramasse là ou l'ESP se la coulera douce.

9

Bus DCC / Re : DCCpp et décodeur de fonctions

« le: janvier 15, 2022, 09:52:41 am »

La norme demande à ce que le décodeur génère une sur-consommation de 60 mA par rapport à son courant de "repos", peu importe la façon dont cette consommation est générée. Pour un décodeur multi-fonctions de traction le plus simple reste d'activer le moteur qui est un gros consommateur naturel...mais sur la plupart des équipements tiers ce ne sera pas aussi simple.

Donc pour respecter la norme il faut ajouter un circuit qui consomme artificiellement du courant et "dose" le phénomène proprement. Sur les rampes d'éclairage, nous utilisons une résistance 3W pilotée par un MOS que nous activons au bon moment. La consommation intrinsèque des LEDs, qui n'excède pas 1 mA au max de leur puissance compte tenu de nos choix, ne permettrait au mieux que de consommer 15 à 20 mA (15 à 20 leds par rampe), soit trop peu par rapport à ce que demande la norme.

10

Le logiciel DCC++ / Re : Problème de lecture et programmation de CVs avec DCC++

« le: janvier 08, 2022, 01:44:06 pm »

La question du choix d'un CI est effectivement liée à ce point.

La série des ACS712 permet  bien de lire une consommation de courant, mais ce composant a une résolution de mesure très faible (car il peut mesurer des courants relativement forts !)

L'intéret du MAX471 était qu'il proposait une résolution de mesure assez élevée, avec 1 volt / ampère...et comme la résolution de la conversion du processeur est sur 1024 pas, on arrive à avoir une lecture fiable. Le MAX472 permet d'obtenir la meme chose. C'est plus compliqué avec un ACS712 même si ça marche dans l'absolu.

Personnellement, avec mon propre code (pas avec les libs DCC++ et dérivées), j'ai réussi à faire de la lecture de CV sur un ACS....mais il est clair que c'est bien plus efficace avec un MAX472 par exemple. Raison pour laquelle on déconseille l'ACS...surtout qu'il en existe trois variantes et qu'il faut à chaque fois adapté le code en conséquence...

11

Le logiciel DCC++ / Re : Problème de lecture et programmation de CVs avec DCC++

« le: janvier 07, 2022, 05:56:34 pm »

Le DCC est un protocole UNI DIRECTIONNEL : seul la centrale émet des données vers les décodeurs. (On ne parle pas du cas RAILCOM).

Un mécanisme trivial de réponse est néanmoins prévu : sur envois d'une commande, le décodeur peut volontairement provoquer un pic de consommation de courant sur la voie de programmation de 60 mA au moins durant un certain temps.

S'il veut répondre TRUE, il génère le pic. S'il veut répondre FALSE il ne fait rien.
Ce que la plupart des décodeurs produisent en actionnant la commande du moteur, avec comme conséquence les tremblements des locomotives.

Ainsi, pour lire un octet d'un CV, la centrale émet huit trames d'interrogation, un pour chaque bit du CV...en demandant si le bit vaut 0 (par exemple, mais elle peut aussi demander si le bit vaut 1...). Les réponses TRUE ou FALSE du décodeur sont assemblées par la centrale qui reconstitue ainsi la valeur de l'octet lu.

Une neuvième commande sera alors envoyée pour demander si l'OCTET vaut la valeur déduite, et là encore le décodeur répondra true ou false, confirmant ou infirmant la bonne lecture d'un CV.

On comprend donc que si la mesure de la consommation de courant sur la ligne n'est pas parfaitement maitrisée, la lecture de CV est inopérante...

12

Trucs & astuces / Re : La fonction printf() en Arduino

« le: janvier 03, 2022, 12:12:34 pm »

C'est bien l'idée, mais cette écriture ne fonctionnera que si le programme ne comporte qu'un seul sketch et pas de librairies ou fichiers inclus...ce qui est rarement le cas pour un programme d'un certain niveau de complexité.

Dans ce cas il faut utiliser un define passé au compilateur comme argument...

13

Trucs & astuces / Re : La fonction printf() en Arduino

« le: janvier 03, 2022, 10:10:26 am »

Tout code qui est compilé est exécuté, qu'il y ai un périphérique connecté ou pas au port série de l'Arduino.
Il émet vos "traces" même en production. Ce qui veut dire qu'il "fuite" de l'information et, surtout, qu'il consomme du temps de calcul pour faire une activité LOURDE inutile (la génération de traces sur la console est un traitement assez lourd toutes proportions gardées !)

Une bonne pratique quand on fait un usage sérieux de la chose consiste à utiliser des MACROS + compilation conditionnelle pour ne pas produire ce code quand on fait une compilation RELEASE du projet, mais à l'inclure seulement lorsqu'on fait une compilation DEBUG lors d'une phase de mise au point. Cela nécessite de passer des options au compilateur qui changent en fonction des circonstances....et là l'IDE ARDUINO c'est pas le panard...

Par contre ça se fait simplement dès qu'on utilise un outil plus sérieux comme Plateforme IO.

14

Discussions ouvertes / Re : Petit coup de pouce ?

« le: novembre 20, 2021, 11:22:48 am »

On a plutot imaginé passer le vendredi  ou le samedi, pas trop le dimanche....donc on se verra

15

Discussions ouvertes / Re : Petit coup de pouce ?

« le: novembre 19, 2021, 09:32:18 pm »

Hello Domi !

Oui, Laurent et moi passeront une journée complète. Pas encore décidé quel jour. Mais dans tous les cas on viendra !