Sujets

1

Modélisation, Architectures logicielles et matérielles / Protocole MFX : Retour d'information des décodeurs

« le: novembre 22, 2024, 12:16:45 pm »

Bonjour à tous,

J’ai présenté une centrale en MFX qui reprend la base matérielle de LaBox et qui fonctionne de manière très satisfaisante.



DCC et MFX sont des protocoles qui sont assez similaires pour ce qui est du codage du signal de voie.

Mais le MFX dans son fonctionnement intrinsèque utilise plus les informations de retour des décodeurs que ne le fait le DCC.

Or je suis bloqué sur ce point pour que cette centrale soit vraiment complète.

Je lance un appel à l’aide aux spécialistes de l’électronique intéressés par le retour d’informations des décodeurs. J’ai pu constater au travers d’autres fils que l’activité était bouillonnante pour ce qui concerne Railcom. Peut-être une opportunité pour moi ?

Pour essayer de faire simple, MFX comme DCC, créent dans les trames de voies une fenêtre pendant laquelle les décodeurs envoient leurs informations retour. Ce signal semble correspondre à la technologie RDS.



Voir ici : https://www.skrauss.de/modellbahn/Schienenformat.pdf 2.3.1 et suivants :

En principe, le canal de retour est codé comme un signal RDS® (codage binaire et modulation). Il est donc possible d'utiliser une puce de décodage RDS® disponible dans le commerce pour décoder le canal retour dans la centrale. C'est d'ailleurs ce qui est fait.

La fréquence porteuse ne correspond pas exactement à la fréquence porteuse définie pour le RDS®. On utilise une fréquence légèrement inférieure qui, contrairement à la fréquence porteuse RDS®, peut être dérivée d'un quartz avec une valeur de fréquence « paire » (par ex. 4 MHz). La fréquence porteuse est de 52,63 kHz (obtenue en divisant 4 MHz par 76, au lieu de 4,332 MHz divisés par 76 = 57 kHz pour le RDS®).

Comme décrit au point 2.2.6, il existe deux types de messages de retour : un simple message de retour de 1 bit et le message de retour de données. Les deux utilisent certes la puce de décodage RDS®, mais de manière différente. Seul le retour de données proprement dit utilise la technique de transmission du RDS®.

On peut d’ailleurs voir à l’intérieur d’une CS2, la puce PT2579 qui est spécifiquement une puce pour le traitement des signaux RDS.



La datasheet du composant est ici : https://mobilluk.com.ua/wp-content/uploads/2024/01/PT2579-SN.pdf?srsltid=AfmBOoqq0ymKa5gb6j-dqeNJvNYznXRjoW_3IB-ZcrYzXdUKD85p4YnY

Sur une autre source, il semble que l’auteur ait réalisé un montage électronique qui permet de décoder le signal retour. Mais là aussi je ne sais pas analyser cela.



Extrait de : https://www.persmodelrailroad.com/mfx_boost.html

Je lance un appel au forum pour qui serait capable de m’aider dans ce projet.

Christophe

2

Modélisation, Architectures logicielles et matérielles / Est-il raisonnable de vouloir construire son propre pont en H ?

« le: octobre 19, 2024, 07:38:39 am »

Bonjour à tous,

J’ouvre ce fil sans aucun préjugé quant à la réponse. De prime abord, on pourrait être tenté de penser que cela est stupide compte tenu des offres assez nombreuses sur le marché (LMD18200, L6203, L298x…) et plutôt économiques.

Mais quelques raisons peuvent nous pousser à aller dans le sens d’une solution totalement DIY ? L’envie de disposer d’une puissance plus importante, d’une solution totalement sur mesure et ergonomique avec une protection des sur intensités (et courts-circuits) gérée de manière autonome et fiable.

Et puis, pourquoi pas, la simple et légitime motivation intellectuelle de chercher à en savoir plus, de comprendre le fonds des choses et de faire soi-même qui sont aussi des composantes de notre cheminement à Locoduino

Cette réflexion a pour origine le besoin de réaliser un petit montage prototype pour piloter un moteur DC « classique » avec de la PWM. Fastoche me dis-je, quelques Mosfets qui trainent dans un tiroir, quelques diodes roues libres, un ou deux condensateurs, des leds témoins, un microcontrôleur et en moins d’une journée, le tout est bâché !

Mais que nenni ! Au fur et à mesure que j’avance, que je potache les « bon » sites sur le sujet, que je me frappe les datasheets avec lesquelles j’ai vraiment beaucoup de mal, je me rends compte que si l’on veut faire les choses dans les règles de l’art, ou tout au moins ne pas tout griller, c’est tout de même complexe et nécessite de prendre en compte de nombreux phénomènes induits par la commande de moteurs.

Alors, j’ai failli renoncer pour un composant « tout fait » mais c’était se priver de pénétrer un sujet qui finalement se révèle selon moi assez intéressant tant le nombre de problèmes à résoudre est important, souvent interconnectés. Je veux dire par là qu’une solution génère souvent un problème, etc… etc…

J’ai une bonne connaissance de base de l’électronique mais je ne maîtrise pas de nombreuses subtilités, et il y en a ici. Dont les réponses dépassent le cadre des moteurs et nous aident à mieux comprendre ce monde fascinant de l’électronique.

Alors j’ai eu envie de solliciter tous ceux qui maitrisent ces questions pour avoir leur opinion, leurs préconisations et sans doute même débattre de conceptions différentes pour résoudre un même problème.

Alors, pour ne pas élargir trop le sujet avec la question : Ca dépend ce que l’on veut en faire, disons qu’il s’agirait de construire une centrale DCC qui nécessite donc des commutations rapides, une tension de 18 volts mini avec des courants pouvant avoisiner 10 à 15 A pour peu que la protection en cas de sur tensions soit particulièrement efficace.

Alors, voilà une première question posée : Est-il raisonnable de vouloir construire son propre pont en H ?

Les réponses devant bien évidement être argumentées. Merci d’avance pour votre participation.

Christophe

3

Bus CAN / Le CAN sur nos réseaux : Pourquoi et comment ?

« le: août 28, 2024, 10:20:22 am »

Bonjour à tous,

J’ouvre ce sujet car le CAN a été mis sur le devant de la scène avec son incorporation récente à l’intérieur de laBox. C’est aussi le moyen de communication des satellites autonomes dont je vous parle de puis quelques temps. Mais enfin et surtout, parce que l’on vous en parle régulièrement dans Locoduino au travers de nombreux projets.

J’ai l’espoir que ce fil permettra au plus grand nombre d’entre vous de comprendre tous les bénéfices qu’il y a à déployer sur nos réseaux une communication en CAN plutôt que toute autre, d’en comprendre les mécanismes fondamentaux pour être capable de déployer progressivement cette technologie avec une totale compréhension plutôt que par copier-coller qui montre rapidement ses limites.

Alors, s’agit-il d’un énième article sur le sujet ? Je ne crois pas. J’ai la chance de discuter avec différents Locoduinistes dont beaucoup sont convaincus que le CAN est effectivement ce qu’il y a de mieux pour un réseau mais ne voient pas comment l’utiliser concrètement, se l’approprier pour développer pour leurs propres besoins.

Oui beaucoup a été écrit (ou dit comme à la conférence de Jean-Luc à Trainmania) et pourtant, force est de constater que les résultats ne sont pas à la hauteur des moyens engagés.

Beaucoup voudraient en faire mais peu se sentent capables et armés pour cela. Et n’osent pas trop avouer que cela leur passe largement au-dessus.

Alors peut-être ce fil aurait pu s’intituler : « Tout ce que vous auriez voulu savoir sur le CAN sans jamais oser le demander ».

Oui, il y a de nombreux articles sur le sujet mais aussi des choses qui manquent et j’espère que ce fil pourra être l’occasion d’exprimer sans tabous vos blocages et vos interrogations car le bénéfice au terme en vaut largement le coup.

J’ai beaucoup réfléchi et depuis pas mal de temps à ce sujet et je pense que le CAN est tellement différent de tout ce que l’on peut connaitre dans notre quotidien qu’il nous est difficile d’en avoir une compréhension par « analogie ».

Nous connaissons les communications téléphoniques « de point à point », un appel un. En composant un numéro, je m’adresse à une personne en particulier et cette personne m’identifie grâce à mon numéro d’appel. Ce sont les communications dites de point à point.

Depuis le COVID, nous connaissons mieux le principe des visos ou plusieurs personnes peuvent échanger et se voir mais il faut rapidement organiser la prise de parole car cela devient vite un capharnaüm.

Nous connaissons bien aussi le principe de la communication hiérarchisée du professeur vers sa classe, du conférencier vers son auditoire. Dans nos systèmes, il est bien connu au travers de l’I2C avec les maîtres et les esclaves

Mais du principe du CAN, où tout le monde peut envoyer des messages librement et écouter tout ce qui se dit sur le bus nous n’avons que peu d’exemples depuis mai 68 hormis les réseaux sociaux mais on voit avec quels résultats.

Alors je crois qu’il faut chercher à connaitre quels sont les principes fondamentaux et les spécificités qui font que le CAN répond si bien aux besoins sur nos réseaux. Et ayant compris ces spécificités originales, comment vous pourrez petit à petit les maitriser et les mettre en place.

Aussi, j’espère aussi que vous serez nombreux à vous exprimer sans tabous et sans fausse pudeur et que les « experts » du sujet à Locoduino joueront le jeu pour vous éclairer le mieux possible.

En parallèle de ce fil, nous avons envisagé avec Catplus (Marcel) de réaliser de petites visio-conférences qui permettraient d’apporter des réponses plus personnelles et interactives. Nous avions déjà réalisé des visios sur ce même sujet et avec succès il y a un an ou deux maintenant.

Voilà donc le cadre posé, à vous de vous en saisir si vous le souhaitez.

Christophe

4

Composants / Raspberry PI Pico : Difficultés de mise en œuvre.

« le: août 16, 2024, 09:19:23 am »

Bonjour à tous,

Je cherche de l’aide concernant l’utilisation du Rasbperry PI Pico suite à l’article de Jean-Luc : https://www.locoduino.org/spip.php?article319

Tout d’abord, j’ai un problème avec l’utilisation de Serial. Problème qui était intermittent mais maintenant permanent et qui me pose de sérieuses difficultés car je n’ai pas de debugge via cette interface ce qui est tout de même gênant. Je précise bien ce point car c’est assez déroutant. J’ai eu des problèmes assez vite au début puis j’ai fait un programme complet avec un module CAN et des Serial.ptin() pour le débug et ça a fonctionné. Puis maintenant avec un bête programme « Blink  + Serial» ça ne fonctionne plus

Pour faire simple, le même programme sans Serial fonctionne alors qu’avec Serial il ne fonctionne plus.

Sur les conseils de Jean-Luc j’ai ajouté

Code: [Sélectionner]

while (!Serial)
  {
    delay(50);
  }
Mais rien n’y fait

Il est ensuite impossible de faire un nouveau téléversement, le port est déclaré comme « busy ». Même mon utilitaire CollTerm qui fonctionne à merveille depuis des années fini par planter. Le seul moyen (heureusement) de récupérer mon RP est d’effacer totalement la carte, appui sur « bootsel » en même temps que de brancher le câble USB. Il faut alors formater le volume mais cela ne règle pas le problème de fond.

Voici avec le simple programme de blink qui fonctionne sans serial et ne fonctionne plus avec Serial !!!

Code: [Sélectionner]

void setup() {
  Serial.begin(115200);
   while (!Serial)
  {
    delay(50);
  }
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  Serial.print("ok ");
  digitalWrite(LED_BUILTIN, HIGH);  // turn the LED on (HIGH is the voltage level)
  delay(1000);                      // wait for a second
  digitalWrite(LED_BUILTIN, LOW);   // turn the LED off by making the voltage LOW
  delay(1000); 
J'avoue que de l'aide serait bienvenue car je suis assez désespéré.

Je suis sur Mac M2 avec Sonoma 14.6

J’ai le problème sur l’IDE Arduino 2.3.2 mais c’est exactement la même chose avec PlateformIO.

Christophe

5

Les réseaux / Et vous vous faites quoi pendant vos vacances ?

« le: août 14, 2024, 05:39:55 pm »

Et bien moi, j'ai réunis une partie de la famille dont les trois grands-mères 241 !

6

Composants / Beaucoup de problèmes avec la V3.x.x de la carte ESP32

« le: août 06, 2024, 07:52:13 pm »

Bonsoir à tous,

Ce fil pour vous signaler que la mise à jour en v3.x.x par Espressif de la carte ESP32 pose de nombreuses difficultés. J'en ai rencontré pas mal avec le WiFi en particulier.

DCC-EX (laBox) met bien en garde sur le fait que la version 3 ne fonctionnera pas.

Pour ceux qui ont déjà fait le mise à jour, il est facile de revenir en arrière :
https://randomnerdtutorials.com/esp32-migrating-version-2-to-3-arduino/

Cela va très loin car il ne m'est par exemple pas possible de me connecter en WiFi à laBox avec mon Mac M2 (à jour). Seules les versions 10.4, 10.6 fonctionnent.

Mais il semble qu'il ne s'agisse pas de bugs mais d'évolution et il y a peu de chances que Espressif revienne en arrière. Un jour ou l'autre, il faudra bien mettre à jour les codes (ou alors jongler avec deux machines comme je le fais).

Christophe

7

Trucs & astuces / Comptage des essieux

« le: mai 12, 2024, 06:25:15 pm »

J'ouvre ce nouveau fil sur ce sujet qui a été lancé ailleurs par Brunotoutsimple mais qui mérite à mon avis d'être plus mis en avant et en lumière.

Je rappelle ici le lien sur la vidéo :



Il faut également regarder les autres vidéos de ce youtubeur elles aussi intéressantes et parfois complémentaires à la première.

La technique qui est proposée est certainement délicate mais réalisable par un modéliste aguerrit. De ce que j’en vois, c’est que la détection est parfaite et rapide.

Personnellement je ne vois pas pourquoi la technique du comptage des essieux, plus complexe, serait plus satisfaisante que la technique par détection de consommation de courant avec des wagons équipés de résistances ! Mais il ne s’agit pas d’une critique, juste de l’ignorance de ma part.

Au-delà de faire connaitre cette technique, ce fil aura le mérite de discuter de ce point et je l’espère, d’apporter des éclairages.

N’hésitez donc pas à faire par de vos expériences et commentaires.

Et merci à Bruno (Brunotoutsimple) pour cette très belle trouvaille.

Christophe

8

Vos projets / DÉPLACÉ: DCC : Détection par consommation avec des courants faibles

« le: mars 23, 2024, 08:49:31 am »

Ce sujet a été déplacé vers Modélisation, Architectures logicielles et matérielles.

https://forum.locoduino.org/index.php?topic=1656.0

9

Aide / DÉPLACÉ: Carte ESP32 universelle + CAN

« le: février 26, 2024, 04:31:01 am »

Ce sujet a été déplacé vers https://forum.locoduino.org/index.php?topic=1648.msg18513#msg18513

10

Modélisation, Architectures logicielles et matérielles / DCC : Détection par consommation avec des courants faibles

« le: janvier 19, 2024, 09:33:44 am »

Bonjour à tous,

J'avais rapidement testé les détecteurs par consommation de courant que nous avions réalisé à Locoduino à base de diodes et opto. Il m'a semblé que ceux ci-étaient incompatibles avec notre détection Railcom. Donc j'ai aussitôt abandonné pour aller vers des solution à effet Hall.

Je n'ai pas de certitude sur ce que j'avance et je n'ai malheureusement pas le temps de faire des tests. Cependant, si certains parmi vous ont besoin de cette réponse, CATPLUS est certainement en mesure de faire le test, il a tout sous la main.

Christophe

11

Vos projets / Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.

« le: janvier 10, 2024, 01:03:40 pm »

Bonjour à tous,

En répondre au challenge proposé sur le topic : Projet partagé d'un gestionnaire de réseau https://forum.locoduino.org/index.php?topic=1645.0
je propose pour ma part une solution que j’ai nommée satellites autonomes.

L’ambition des satellites autonomes est d’offrir une solution de gestion de réseau simple et rapide à déployer et ne nécessitant par la suite aucune intervention particulière durant l’exploitation. Priorité est donnée au plaisir du jeu en libérant le modéliste d’opérations fastidieuse ou encore de programmation.


Principes généraux :

Les satellites autonomes sont à la base des satellites Locoduino tels qu’ils ont été présentés en 2018. Ce sont des cartes qui reçoivent des commandes en entrée : commandes de mouvement d’aiguille ou de signalisation lumineuse par exemple, et qui envoient en sortie, des informations d’état concernant les équipements de réseaux sous sa responsabilité : Etat d’occupation, état des capteurs en entrée ou en sortie de canton…

Ces satellites auxquels nous avons donné la dénomination v1 sont ainsi des alliés précieux pour un gestionnaire de réseaux puisqu’ils lui apportent les informations nécessaires à la prise de décisions et en retour, exécutent les commandes demandées par ce gestionnaire.

Mais les gestionnaires de réseaux existants sont assez compliqués à programmer et cela rebute nombre d’entre nous à commencer par moi. Je parle de JMRI ou Rocrail pour les logiciels gratuits ou encore Train Controller mais il y en a beaucoup d’autres. Ce sont par ailleurs des solutions qui nécessite pour la plupart un ordinateur dédié (ou un Raspberry).

Mon travail a donc consisté à demander à chaque satellite de réaliser en plus, pour le canton qui est sous sa responsabilité, les fonctions de gestion de réseau : Sécurité et régulation des trains, commandes de ralentissement et/ou d’arrêt des locomotives, gestion de la signalisation lumineuse. J’ai donc introduit comme disent certains, une forme d’intelligence dans le système.

D’où aussi le nom de satellites autonome dans la mesure où il n’y a pas de gestionnaire centralisé.

Les objectifs :

Les objectifs que je me suis fixés avec les satellites autonomes étaient :

1° - Que la phase de description du réseau, des équipements, du nommage de zones ou des cantons, le choix des cibles de signalisation soient simplifiés autant qu’il serait possible. Et je pense que sur ce point l’objectif est largement atteint, voir dépassé comme vous pourrez en juger par la suite.

2° - Que pendant l’exploitation, le modéliste soit totalement libéré des contraintes de sécurité en particulier pour pouvoir pleinement profiter du plaisir du jeu.

3° - Que le modéliste n’ait rien à écrire ou modifier dans le code des programmes. Que les programmes à télécharger sur chaque carte soient tous rigoureusement identiques. De fait, hormis le nom du réseau Wifi et son mot de passe à renseigner une fois, il n’y a rien d’autre à faire.

4° - Offrir une interface simple et intuitive pour les quelques opérations de réglage comme par exemple pour les butées des servo-moteurs d’aiguilles.

5° - Mettre en œuvre les solutions techniques privilégiés par Locoduino comme le protocole DCC (que l’on retrouve aujourd’hui dans LaBox) ou l’adoption d’un bus de communication CAN.

6° - Simplifier autant que cela serait possible le câblage du réseau, nombre et longueur des câbles en particulier. Cela est en partie grandement réalisé par les liaisons en RJ45 qui véhiculent le bus CAN et l'alimentation électrique.

Dans la version actuelle, les possibilités offertes sont particulièrement bien adaptées pour une mise en œuvre simple sur des petits et moyens réseaux, des dioramas, des va-et-vient sur lesquels je dirais, il n’y a qu’à poser les satellites à proximité des cantons, souder quelques fils, procéder à la reconnaissance mutuelle, régler le cas échéant les valeurs de servos moteurs d’aiguilles et c’est tout. Il est possible d’utiliser son réseau avec trois satellites pour en tester le comportement et d’ajouter un quatrième, puis un cinquième puis tous les autres. Rien de ce qui a déjà été fait n’est remis en cause.
Les satellites autonomes permettent donc de couvrir les besoins de la grande majorité des modélistes Je suis bien conscient et j’assume le fait que cela ne répondra pas par exemple aux besoins d’une vaste gare cachée avec de nombreuses aiguilles ni encore à ceux d’un grand réseau complexe.

Point important à noter : Pour rester cohérent avec mon objectif de simplification, j’ai retenu la technologie Railcom pour la détection et l’identification des locomotives. Cela nécessite donc que toutes les locomotives disposent de cette technologie. La reconnaissance par RFID est aussi incluse (mais optionnelle) mais elle ne peut pas se substituer à Railcom.

Voilà donc posés les principes généraux et la philosophie de ces satellites autonomes. Je vous présenterai par la suite les différents matériels, la mise en œuvre concrète et bien sûr, pour ceux que cela intéresse le code des programmes.

En attendant, voici ce à quoi ressemble un satellite autonome :

Je répondrai volontiers à toutes les questions que vous voudrez me poser, mais n'anticipez pas trop sur ce que je dois vous présenter par la suite.

Christophe

12

Bus DCC / Détection RailCom© : Des solutions complètes, matérielles et logicielles.

« le: octobre 14, 2023, 03:39:57 pm »

Bonjour à tous.

J’avais déjà parlé dans divers fils du forum du travail réalisé en commun avec Marcel (Catplus) pour réaliser une solution complète de détection Railcom.

Un article du site éditorial présente en détail cette réalisation : https://www.locoduino.org/spip.php?article334
mais il ne peut malheureusement pas aborder tous les points et/ou les aborder avec tout le niveau de précision que certains auraient pu souhaiter.

L’objectif de ce fil créé en parallèle de l’article est justement de permettre à chacun de s’exprimer, de proposer, de poser des questions.

Ainsi, nous l’espérons, nous pourrons faire évoluer encore les choses et probablement apporter des compléments à la publication de base.

N’hésitez surtout pas à vous mettre au clavier !

Christophe

13

Bus DCC / EX-DCCInspector

« le: septembre 28, 2023, 11:25:42 am »

Bonjour à tous,

Catplus et moi travaillons sur un projet qui nécessite de « sniffer » les trames DCC envoyées sur un réseau. En précisant que nous souhaitons utiliser l’ESP32 comme plateforme.

EX-DCCInspector semble faire l’unanimité pour le job. Il en est plusieurs fois question sur le forum mais rien pour en parler de manière un peu exhaustive. C’est l’ambition de ce fil.

Tout d’abord, la page traitant de EX-DCCInspector se trouve ici : https://dcc-ex.com/ex-dccinspector/index.html#gsc.tab=0

Il y a deux manières de se procurer le fichier, soit en téléchargeant un fichier .zip, soit sur le GitHub.

J’ai rencontré plusieurs problèmes :

1° - Le scketch ne compile pas avec une version de l’IDE Arduino inférieure à 2.0
2° - J’essaye alors avec PlatformIO et je rencontre aussi un problème à la compilation.

Avec l’IDE Arduino, la solution a été d’installer la dernière version, pour moi la 2.2.2 (au 28 sept 2023)

Avec PlatformIO, les fonctions doivent être déclarées avant leur première utilisation. Or plusieurs fonctions utilisées dans le loop() sont définie après dans le code.

J’ai donc ajouté le prototype des fonctions juste avant le setup() et ça fonctionne.

Code: [Sélectionner]

void clearHashList();
bool processCommands();
void UpdateLED();
void DecodePacket(Print &, int, bool);
bool processDCC(Print &);

void setup() {
Pour utilisation avec un ESP32, il vous faut renseigner le réseau WiFi utilisé ainsi que son mot de passe dans le fichier Config.h

Code: [Sélectionner]

#define WIFI_SSID "myssid"
#define WIFI_PASSWORD "mypassword"
Nous commentons la ligne

Code: [Sélectionner]

//#define USE_OLED car nos n(utiliserons pas d’écran OLED.

En contrepartie, l’ESP32 autorise l’affichage des données dans un navigateur web à l’adresse http://DccInspector.local/



Voilà quelques précisions pour pouvoir utiliser EX-DCCInspector sur un ESP32 avec visualisation des données dans une page web.

14

Vie du site rédactionnel et du forum / Il y a des jours où chatGPT est fatigué ! Ou quand c'est nous qui faisons le taf

« le: juin 23, 2023, 12:47:50 pm »

J'utilise assez souvent chatGPT pour avoir un retour sur du code que j'ai pu écrire et je dois avouer que souvent, je trouve des suggestions intéressantes. Mais alors ce matin, je lui ai soumis un vieux code (2012) qui n'incorporait pas des évolutions intéressantes de C++ 11 comme les listes d'initialisation par exemple. Voici le texte de nos échanges (sans le code que je pourrais poster si cela vous semble intéressant). C'est assez éloquent :

Moi
Bonjour Chat

ChatGPT
Bonjour! Comment puis-je vous aider aujourd'hui?

User
Dis moi comment tu écrirais ceci en C++ moderne ?

ChatGPT
Voici le code en C++ moderne pour la classe TrackController que vous avez fournie :

Ce code utilise les fonctionnalités du langage C++ moderne, telles que l'initialisation de membres dans la liste d'initialisation du constructeur (mHash(hash), mDebug(debug), etc.), ainsi que l'inclusion de la bibliothèque Arduino (<Arduino.h>) pour utiliser Serial.println(F(...)) avec la macro F() pour économiser de la mémoire.

User
Je suis d'accord avec toi qu'il faut utiliser des listes d'initialisation mais tu ne le fais pas !

ChatGPT
Je m'excuse pour l'omission dans ma réponse précédente. Vous avez raison, il est préférable d'utiliser des listes d'initialisation pour initialiser les membres de la classe. Voici le code mis à jour en utilisant des listes d'initialisation :

Dans ce code mis à jour, les membres mHash, mDebug, mLoopback et mGbxBoot sont initialisés dans les listes d'initialisation des constructeurs correspondants, plutôt que d'être assignés dans le corps du constructeur init(). Cela améliore l'efficacité et la lisibilité du code.

User
tu dois être fatigué aujourd'hui car la fonction init n'est plus nécessaire :  void init(word hash, boolean debug, boolean loopback, boolean gbxBoot) {
        mHash = hash;
        mDebug = debug;
        mLoopback = loopback;
        mGbxBoot = gbxBoot;
    }

ChatGPT
Je m'excuse pour la confusion précédente. Vous avez tout à fait raison, la fonction init() n'est plus nécessaire puisque nous pouvons initialiser directement les membres dans les listes d'initialisation des constructeurs. Voici le code mis à jour sans la fonction init() :

Je m'excuse à nouveau pour l'erreur précédente et je vous remercie de votre patience. Le code ci-dessus initialise maintenant directement les membres dans les listes d'initialisation des constructeurs, sans avoir besoin de la fonction init().

User
Je me demande si je peux te faire confiance

ChatGPT
Je comprends que mes erreurs précédentes ont semé le doute. En tant qu'IA, je m'efforce de fournir des réponses précises et fiables, mais il peut arriver que des erreurs se produisent. Je suis constamment en apprentissage et j'essaie d'améliorer mes performances.

Je vous recommande de toujours vérifier les réponses que je vous donne et d'utiliser votre propre jugement et connaissance pour prendre des décisions. N'hésitez pas à poser des questions de suivi ou à demander des éclaircissements si quelque chose ne semble pas correct.

Mon objectif est de vous aider du mieux possible, et je ferai de mon mieux pour répondre à vos demandes.

15

Bus CAN / Pénurie de MCP2562

« le: août 01, 2022, 07:56:09 am »

Bonjour à tous,

Comme il est écrit dans le titre du sujet, il y a depuis quelques semaines une pénurie sur les approvisionnements des petits MCP2562, transceiver bien pratiques et économiques sur nos montages à base d'ESP32 entre autres.

Quelqu'un a t'il une proposition d'approvisionnement (fiable et économique) ou une solution de remplacement ? Plus particulièrement en montage traversant.

Merci par avance