LaBox V2

Le V2 du titre ne concerne QUE la partie logicielle, le matériel est reconduit dans l’état.

Premier Jet

Essayant de résoudre les problèmes de qualité de trame DCC et de lecture/écriture de CV de la V1 (vu dans l’article LaBox, Une Centrale DCC polyvalente et abordable (1), j’ai pris contact avec les gens de DCC-EX sur le groupe idoine du logiciel de communication Discord. Ils maintiennent le vieux DCC++ nommé dorénavant BaseStation-Classic, mais aussi quantité d’autres outils périphériques. Après quelques échanges avec eux, dont l’auteur de EngineDriver, et avec Dominique, nous avons décidé de donner une chance à la nouvelle version de DCC++ appelée maintenant CommandStation-EX. Complétement ré-écrit, le principe de fonctionnement de DCC++ est resté, avec un analyseur de syntaxe acceptant les mêmes commandes texte plus quelques ajouts. Ils y ont aussi ajouté la même API que celle développée pour DCCpp, avec des fonctions d’accès direct au pilotage des machines et des accessoires sans passer par le texte. Par exemple pour allumer le courant DCC, il faudrait demander à DCCEXParser::parse() de traiter la chaine <1>, alors que l’on peut maintenant directement appeler TrackManager::setMainPower(POWERMODE::ON) ; . La partie pilotage des broches de l’Arduino est toujours présente, mais avec la possibilité d’utiliser des circuits d’extension de broche. Une partie est également prévue pour gérer un écran Lcd basique. En outre CommandStation-Ex dispose d’origine de la connexion Wifi avec les applications compatibles WiThrottle/EngineDriver. Le fait que l’auteur de ce dernier fasse partie de l’équipe n’y est certainement pas étranger. Enfin, une partie nommé EX-Rail permet d’automatiser des comportements de la centrale, tout comme faisait ma Throttle de LaBox V1 ! Un article sera sans doute nécessaire pour en décrire toutes les possibilités.

Portage
Le portage de LaBox vers CommandStation-EX s’est fait en plusieurs étapes. D’abord, il s’agissait de rendre ce programme compatible avec l’ESP32. La version originale couvrant les AVR (Uno/Mega...), les DUE (SAMD), les Teensy et les STM32, mais pas les ESP ! J’ai vu par hasard un message sur Discord d’un membre de l’équipe DCC-EX qui disait avoir fait une version ESP32 dans une branche dédiée. C’était le point de départ !

Après différents tests, la branche PORTX_HAL CommandStation-EX dédiée à l’ESP32 marchait plutôt bien avec la commande texte. L’intérêt principal de cette version étant de ne plus utiliser des interruptions lancées par un timer, mais une fonctionnalité matérielle de l’ESP32, le mode RMT conçu à l’origine pour faire de la musique !
On le sait, les sons résultent d’une vibration causée par un émetteur, par exemple un haut-parleur. Pour faire bouger la bobine, il faut envoyer du courant alternatif dont la fréquence fixe la hauteur de la note, 440Hz, soit 440 fois par seconde pour un La par exemple. Or faire varier la fréquence d’un signal électrique est exactement ce que faisait la routine DCC++ à base d’interruptions ! Dans le cas du DCC, RMT est simplement légèrement détourné pour faire varier cette fréquence quasiment à chaque impulsion et construire ainsi des séquences de 0 et de 1 à la mode DCC.
Deuxième étape, redonner à LaBox V2 le contrôle de l’écran et des boutons de la V1, avec la gestion des menus HMI. Au passage, j’ai nettoyé le code de CommandStation-EX en retirant les parties qui ne seraient jamais utilisées parce que notre projet est sur une plateforme matérielle dédiée qui fige les besoins. Les extenders de port ou la gestion de l’écran Lcd ont été purement et simplement retirés.

A noter : CommandStation-EX est, tout comme DCC++, un projet à part entière. Ce n’est pas une bibliothèque comme l’est DCCpp. Et à la fois pour respecter le travail des développeurs qui l’ont créé, et parce qu’une bibliothèque suppose une utilisation dans des contextes différents, ce qui n’est pas notre cas, j’ai préféré rester dans l’esprit de l’original. CommandStation-EX-LaBox est donc un projet, avec tous les sources dans le même répertoire que le fichier .ino. Ce qui ne l’empêche pas d’avoir besoin de bibliothèques externes. Elles sont listées à la fin de l’article dans le paragraphe compilation.

Problèmes

Une fois le portage terminé, avec un écran et des boutons fonctionnels, il s’est agit de vérifier que la lecture/écriture de CV était meilleure que pour LaBox V1. Et là grosse déception. Rien ne marchait. J’ai passé plusieurs mois entre essais et renoncements, remise en cause du soft, du matériel, de mes locos... Et puis un jour l’illumination : pourquoi ne pas tester déjà avec la version originale de CommandStation-EX, sans les innombrables modifications apportées par mes soins pour insérer HMI et les nettoyages de code, plus les manips pour tester tout ça ? Et là, surprise, ça marche parfaitement ! Franchement je n’y croyais qu’à peine, et ça l’a fait. Fort de cette excellente nouvelle, j’ai alors comparé les sources des deux versions pour les rapprocher au maximum. Mais LaBox refusait toujours obstinément de lire les CV. J’ai donc fait le chemin inverse, en partant de la version qui ne marche pas et en retirant pas à pas tout ce qui fait la différence entre LaBox et CommandStation-EX dont il est issu. J’ai supprimé le Wifi, supprimé HMI et tout ce que je pouvais. Et ça s’est mis à marcher ! En remontant morceau par morceau, j’ai fini par découvrir que pendant la lecture de CV qui impose de scanner la consommation de courant sur les rails pendant de très courts moments, de l’ordre de quelques microsecondes, on continuait de mettre à jour le contenu de l’écran avec HMI. Et c’est cette mise à jour sans doute trop longue (à l’échelle de quelques microsecondes !) qui mettait à mal les timings de lecture de consommation... Et je pense aujourd’hui que c’est ce qui a aussi empêché la version 1 de fonctionner.
Bref, un grand soulagement : le matériel n’est pas en cause, mes locos fonctionnent, et on va pouvoir avancer. Et là, à nouveau un blocage.
Si le matériel LaBox était prévu pour une seule voie, CommandStation-EX permet lui de commander une voie principale, une voie de programmation, et des boosters dont la broche dédiée sera directement liée à la broche de la voie principale pour y impulser les mêmes signaux DCC que la voie principale. Les fonctions de lecture/écriture de CVs sont donc dédiées à la voie de programmation. J’ai bien tenté de lui permettre de manipuler les CVs sur la voie principale, mais rien n’a marché... Alors aux grands maux, les grands remèdes. J’avais constaté dans mes essais qu’une configuration de CommandStation-EX avec seulement une voie de programmation était possible. Il fallait donc pouvoir basculer d’une configuration ’voie principale’ à une configuration ’voie de programmation’ sans que l’utilisateur ne s’en rende compte. Comme la configuration est fixée dans le code par des instructions en dur, impossible de changer de config pendant le fonctionnement de la centrale.

Solution

Seule solution, redémarrer LaBox à chaque changement de configuration, en trouvant le moyen de fixer la bonne configuration au démarrage, et en masquant le reboot au maximum. Pour y arriver, j’ai inscrit un caractère spécifique à un emplacement bien particulier de l’EEPROM. Si un ’P’ se trouve là au démarrage, c’est que la configuration doit être en mode programmation. N’importe quoi d’autre laisse une configuration normale de pilotage de réseau. C’est une condition aussi pour pouvoir démarrer avec le mode pilotage, même avec une zone mémoire pas encore initialisée ou occupée par d’anciennes données issues d’autres programmes. Ce serait bien un coup du sort qu’un ’P’ se trouve là posé par quelqu’un d’autre...
Une fois ce caractère écrit dans l’EEPROM, on demande à l’ESP32 de redémarrer avec un petit ESP.restart();.

Puis pendant le setup juste après le redémarrage, on remplace immédiatement le ’P’ de l’EEPROM par autre chose, j’y ai mis un ’M’ comme ’Main’, puis on utilise la configuration de programmation pour initialiser CommandStation-EX. Enfin, l’écran d’interrogation de l’adresse du matériel moteur s’ouvre directement et la lecture se lance. Une fois le résultat validé, un autre petit coup de ESP.restart(), et on redémarre à nouveau, cette fois en mode pilotage puisqu’il n’y a plus de ’P’ dans l’EEPROM.

EEPROM ESP32
Stricto sensu, l’ESP32 ne dispose par d’EEPROM embarquée contrairement à un UNO ou un Mega... Elle est donc émulée en utilisant une petite partie de la large mémoire flash du microcontrôleur, celle qui stocke le programme à exécuter. 512 octets y sont dédiés, ce qui ne grève pas trop les 520Ko de mémoire programme disponibles. Bien sûr, la traditionnelle bibliothèque EEPROM fournie avec le package permettant de programmer l’ESP32 a été adaptée pour n’y voir que du feu, et la programmation de cette mémoire est strictement identique à ce que l’on ferait sur un UNO ou un MEGA à microcontrôleur AVR.

Code

Dans CommandStation-EX, il faut configurer les broches pour chaque voie (principale, programmation, boosters) via une structure MotorDriver inscrite en dur dans le fichier config.h . C’est également là que l’on va déclarer puis paramétrer le Wifi, et d’autres choses moins importantes pour nous.

/////////////////////////////////////////////////////////////////////////////////////
//  NOTE: Before connecting these boards and selecting one in this software
//        check the quick install guides!!! Some of these boards require a voltage
//        generating resistor on the current sense pin of the device. Failure to select
//        the correct resistor could damage the sense pin on your Arduino or destroy
//        the device.
//
// DEFINE MOTOR_SHIELD_TYPE BELOW ACCORDING TO THE FOLLOWING TABLE:
//
//  STANDARD_MOTOR_SHIELD : Arduino Motor shield Rev3 based on the L298 with 18V 2A per channel
//  POLOLU_MOTOR_SHIELD   : Pololu MC33926 Motor Driver (not recommended for prog track)
//  POLOLU_TB9051FTG      : Pololu Dual TB9051FTG Motor Driver
//  FUNDUMOTO_SHIELD      : Fundumoto Shield, no current sensing (not recommended, no short protection)
//  FIREBOX_MK1           : The Firebox MK1                    
//  FIREBOX_MK1S          : The Firebox MK1S
//  IBT_2_WITH_ARDUINO    : Arduino Motor Shield for PROG and IBT-2 for MAIN
//   |
//   +-----------------------v
//

#define LABOX_MAIN_MOTOR_SHIELD F("LABOXMAIN"), \
 new MotorDriver(32, 33, UNUSED_PIN, UNUSED_PIN, 36, 0.80, 2500, UNUSED_PIN)

#define LABOX_PROG_MOTOR_SHIELD F("LABOXPROG"), \
 NULL, \
 new MotorDriver(32, 33, UNUSED_PIN, UNUSED_PIN, 36, 0.80, 2500, UNUSED_PIN)

Dans un fichier MotorDrivers.h, des configurations sont déjà proposées pour des shields Arduino bien connus comme les Pololu. Mais dans notre cas, la configuration est ’maison’ et l’on doit donc se créer notre propre ’MotorDriver’ au doux nom de LABOX_MOTOR_SHIELD. Et ceci en deux versions : une version MAIN qui sert au pilotage, et une version PROG qui sert, vous avez deviné, au mode programmation.
Dans le CommandStation-EX original, c’est MOTOR_SHIELD_TYPE qui est utilisé pour configurer les broches associées aux voies. En réalité, parce notre configuration est variable, on ne va pas utiliser ce mécanisme.
Pour comprendre comment ça marche, prenons le cas du shield POLULU :

#define POLOLU_MOTOR_SHIELD F("POLOLU_MOTOR_SHIELD"),                                                 \
                            new MotorDriver( 9, 7, UNUSED_PIN,         -4, A0, 18, 3000, 12), \
                            new MotorDriver(10, 8, UNUSED_PIN, UNUSED_PIN, A1, 18, 3000, 12)

La déclaration du ou des modules de puissance (MotorDriver) est en trois parties : la première est juste un texte F("nom"’) donnant le nom de la configuration, ce qui permet éventuellement de l’afficher quelque part... Vient ensuite le premier MotorDriver dédié à la voie principale avec ses différentes broches et paramètres. Puis on continue avec le MotorDriver dédié à la voie de programmation. Chaque MotorDriver ajouté ensuite serait un Booster dont les broches recevront les mêmes activations que les broches de la voie principale. On voit que par rapport au POLULU, le matériel LaBox n’a pas de voie de programmation, il n’y a qu’un seul MotorDriver à déclarer. Pour n’utiliser QUE la voie de programmation, il faut déclarer son MotorDriver en troisième argument, c’est à dire refuser de donner un MotorDriver pour la voie principale.
LABOX_MAIN_MOTOR_SHIELD définit donc un texte de description, suivi du MotorDriver pour la voie principale.
LABOX_PROG_MOTOR_SHIELD définit aussi un texte de description, suivi de NULL qui signifie qu’aucune voie principale n’est utilisée, puis suivi du MotorDriver pour la voie de programmation.

Dans le nouveau ’CommandStation-EX-LaBox.ino’, ça se traduit par

#include "DCCEX.h"
#include "EEPROM.h"

...

//--------------------------- HMI client -------------------------------------
#ifdef USE_HMI
#include "hmi.h"
hmi boxHMI(&Wire);
#endif
//----------------------------------------------------------------------------

Notez que je vous ai épargné tous les copyrights et les messages d’avertissement de mauvaise configuration. On retrouve dans ce début de fichier les includes, puis la déclaration de l’instance d’objet hmi nommé boxHMI.

Un détail qui a son importance. Afin de ne pas perturber outre mesure le code de CommandStation-EX, j’ai déclaré dans config.h un #define USE_HMI. Ainsi, pour toutes les modifications apportées au code original, il suffit d’ajouter la condition #ifdef USE_HMI   ... #endif pour isoler le code de LaBox. Accessoirement, cela permettrait en retirant ce #define de compiler pour un ESP32 sans écran et boutons, uniquement piloté par la voie série par exemple.

void setup()
{
  // The main sketch has responsibilities during setup()

  // Responsibility 1: Start the usb connection for diagnostics
  // This is normally Serial but uses SerialUSB on a SAMD processor
  SerialManager::init();

  DIAG(F("License GPLv3 fsf.org (c) dcc-ex.com"));
  DIAG(F("Platform: %S"), F(ARDUINO_TYPE)); // PMA - temporary

  DIAG(F("License GPLv3 fsf.org (c) Locoduino.org"));
  DIAG(F("LaBox : 2.4.0"));

  CONDITIONAL_LCD_START {
    // This block is still executed for DIAGS if LCD not in use
    LCD(0,F("CommandStation-EX v%S"),F(VERSION));
    LCD(1,F("Lic GPLv3"));
  }

#ifdef USE_HMI
  EEPROM.begin(512);
  byte mode = EEPROM.read(hmi::EEPROMModeProgAddress);

  hmi::progMode = false;
  if (mode == 'P') hmi::progMode = true;

  DIAG(F("Mode %s"), hmi::progMode?"Prog":"Main");

	if (hmi::progMode) {
		// Reset to Main mode for next reboot.
		EEPROM.writeByte(hmi::EEPROMModeProgAddress, 'M');
		EEPROM.commit();
	}

  // must be done before Wifi setup
  boxHMI.begin();
#endif

Première partie du setup : après les copyrights de rigueur, on va lire un caractère dans l’EEPROM à un endroit bien particulier stocké dans la constante hmi::EEPROMModeProgAddress . Puis on va mettre à true une variable statique progMode de la classe hmi si on a bien trouvé un ’P’ qui réclame un mode programmation. On écrit ensuite immédiatement autre chose à la place du ’P’, ici un ’M’, pour être sûr que quoi qu’il se passe à partir de maintenant, le prochain démarrage de LaBox se fera en mode pilotage. On termine cette séquence avec l’initialisation de HMI.

	// Responsibility 2: Start all the communications before the DCC engine
	// Start the WiFi interface on a MEGA, Uno cannot currently handle WiFi
	// Start Ethernet if it exists
	#ifndef ARDUINO_ARCH_ESP32
	#if WIFI_ON
	WifiInterface::setup(WIFI_SERIAL_LINK_SPEED, F(WIFI_SSID), F(WIFI_PASSWORD), F(WIFI_HOSTNAME), IP_PORT, WIFI_CHANNEL);
	#endif // WIFI_ON
	#else
	// ESP32 needs wifi on always
	WifiESP::setup(WIFI_SSID, WIFI_PASSWORD, WIFI_HOSTNAME, IP_PORT, WIFI_CHANNEL);
	#endif // ARDUINO_ARCH_ESP32

	#if ETHERNET_ON
	EthernetInterface::setup();
	#endif // ETHERNET_ON

	// Initialise HAL layer before reading EEprom or setting up MotorDrivers 
	IODevice::begin();

  // Responsibility 3: Start the DCC engine.
  // Note: this provides DCC with two motor drivers, main and prog, which handle the motor shield(s)
  // Standard supported devices have pre-configured macros but custome hardware installations require
  //  detailed pin mappings and may also require modified subclasses of the MotorDriver to implement specialist logic.
  // STANDARD_MOTOR_SHIELD, POLOLU_MOTOR_SHIELD, FIREBOX_MK1, FIREBOX_MK1S are pre defined in MotorShields.hrr

  if (hmi::progMode) {
    DIAG(F("LaBox Prog mode."));
    TrackManager::Setup(LABOX_PROG_MOTOR_SHIELD);
  }
  else {
    DIAG(F("LaBox Main mode."));
    TrackManager::Setup(LABOX_MAIN_MOTOR_SHIELD);
  }

  //  TrackManager::Setup(MOTOR_SHIELD_TYPE);

Initialisation des différents modes réseau, et de la couche EEPROM utilisée par CommandStation-EX. A noter le commentaire qui fini par un nom de fichier MotorShields.hrr qui manifestement a changé depuis longtemps puisque c’est maintenant MotorDrivers.h . D’où l’importance des commentaires à jour. Un mauvais commentaire est pire qu’une absence de commentaire ! C’est l’inconvénient de l’avantage : les commentaires sont indispensables, mais ils doivent être tenus à jour.
La partie intéressante pour nous arrive juste après ce commentaire. La dernière ligne, en remarque, donne l’ancien mode d’initialisation des voies avec TrackManager::Setup(MOTOR_SHIELD_TYPE); . Je vous l’ai dit, on l’a remplacé pour gérer notre double mode : si hmi::progMode est à true, alors on fait ce Setup() avec LABOX_PROG_MOTOR_SHIELD. S’il est à false, alors on déclare uniquement le voie principale avec LABOX_MAIN_MOTOR_SHIELD.

 // Start RMFT aka EX-RAIL (ignored if no automnation)
  RMFT::begin();

  // Invoke any DCC++EX commands in the form "SETUP("xxxx");"" found in optional file mySetup.h.
  //  This can be used to create turnouts, outputs, sensors etc. through the normal text commands.
  #if __has_include ( "mySetup.h")
    #define SETUP(cmd) DCCEXParser::parse(F(cmd))
    #include "mySetup.h"
    #undef SETUP
  #endif

  #if defined(LCN_SERIAL)
  LCN_SERIAL.begin(115200);
  LCN::init(LCN_SERIAL);
  #endif
  LCD(3, F("Ready"));
  CommandDistributor::broadcastPower();

#ifdef USE_HMI
  if (hmi::progMode) {
    // must be done after all other setups.
    boxHMI.setProgMode();
  }
#endif
}

On termine en laissant CommandStation-EX s’initialiser. Le seul ajout consiste à dire à HMI qu’il est en mode programmation. Cela mettra l’écran dans un mode particulier et lancera immédiatement la commande d’interrogation de l’adresse du matériel moteur placé sur la voie.

La loop() ira ensuite lancer à son tour les loop() des différentes composantes de CommandStation-EX.
On aura juste ajouté le rafraichissement de l’écran avec boxHMI::update();

Voilà pour la version 2 de LaBox, cette fois pleinement opérationnelle !

Pour en profiter c’est en deux étapes :

Utilisation
Récupération
Pour obtenir les sources, ce sera sous la forme d’un fichier zip. Ce type de fichier est directement lisible par Windows, pas besoin d’outil supplémentaire... A voir pour les autres systèmes. Deux options pour le récupérer :

• Le fichier zip ici dans sa version 2.4.0 actuelle
  Décompressez simplement le zip dans le répertoire de vos projets Arduino. C’est simple, mais le danger c’est que le contenu du zip n’est pas forcément la dernière version du logiciel.
• Aller le chercher sur le Github de LOCODUINO
  Nos projets sont stockés et en libre accès sur Github, plateforme de projets collaborative et Open Source. Vous pourrez y récupérer la dernière version du moment.
  • Rendez vous sur notre github.

    

    Figure 3

    Ecran du projet CommandStation-EX-LaBox sur Github. Cliquez pour agrandir

  • Vérifiez que vous êtes bien sur la branche LaBox en haut à gauche (1)
  • Cliquez sur le bouton <> Code (2)
  • Utilisez l’option ’Download Zip’ . (3)
  • Le fichier zip ainsi récupéré portera le nom du projet ’CommandStation-EX-LaBox’ suivi du nom de la branche ’LaBox’, ce qui donnera ’CommandStation-EX-LaBox-LaBox.zip’. Décompressez le dans votre répertoire de projets Arduino.
  • Le répertoire créé sera du même nom que le zip, ce qui n’est pas conforme à ce qu’attend l’IDE Arduino, il faut donc le renommer en ’CommandStation-EX-LaBox’ en retirant un des deux ’LaBox’ .

Configuration
Vous avez maintenant une version installée du projet, mais vous devez y apporter votre touche. Rien de bien compliqué, rassurez vous.
Le seul fichier que vous devez créer est le config.h . Ce fichier contient la configuration de CommandStation-EX. Quelles broches, quel wifi, quelles options... Pour vous simplifier la tâche un fichier d’exemple est inclus, config-labox.h, qui contient déjà l’essentiel du paramétrage bien configuré. Copiez le sous le nom config.h au même endroit. Ouvrez le avec un notepad ou assimilé, et configurez le Wifi comme vous le souhaitez :

• Mode AP
  Ce mode permet de faire de l’ESP32 un petit serveur autonome auquel les appareils Android ou iOS pourront se connecter. Aucune box d’un fournisseur d’accès internet n’est nécessaire. Mais la puissance d’émission du Wifi d’un ESP32 est sans commune mesure avec une Box Wifi moderne, même si elle est déjà correcte. Le config-labox.h livré, donc votre config.h aussi si vous l’avez copié, est déjà dans cette configuration :
  • WIFI_FORCE_AP est à true
  • WIFI_SSID est "LaBox230", c’est ce que vous verrez sur vos appareils lorsque vous tenterez de vous connecter.
  • WIFI_PASSWORD est par défaut à "Your network passwd". Changez le si ça ne vous convient pas, ou videz le "" si vous ne voulez pas de mot de passe. Mais si vous le faites, tout le monde pourra se connecter à votre ESP !
• Mode Box
  LaBox va se connecter à votre réseau local, probablement le Wifi de votre Box Internet. Vous bénéficierez alors de la puissance du Wifi d’une box pour votre réseau ! Vous devrez modifier votre config.h avec les valeurs suivantes :
  • WIFI_FORCE _AP doit être à false
  • WIFI_SSID est celui de votre box, celui que vous voyez lorsque vous tentez de connecter un téléphone.
  • WIFI_PASSWORD est celui de la connexion au Wifi de la box, celui que vous avez utilisé pour connecter votre téléphone au réseau de la maison.

Compilation
Pour que LaBox se compile, vous allez devoir installer quelques bibliothèques :

• OneButton en version 2.1.0 (IDE ou 2.0.3 Platform.IO)
• Adafruit GFX Library en version 1.11.9
• Adafruit SSD1306 en version 2.5.9

Ca pourrait marcher avec d’autres versions, mais avec celles-là, je suis sûr que ça marche !

Il vous suffit maintenant de compiler et uploader le résultat sur LaBox ! C’est possible avec l’IDE Arduino version 1 ou 2, ou avec Platform.IO dans Visual Studio Code. Attention, sur certains ESP32, le téléchargement attend que l’ESP32 soit dans un état réceptif, ce qui se fait en pressant longuement le bouton à droite de la prise USB sur l’ESP32 pendant le défilement des petits points derrière ’Connecting’...

Figure 4

Fin de compilation dans l’IDE, et début de l’envoi du code compilé à l’ESP32

Connexion
Une fois le programme chargé, LaBox va démarrer tout de suite et afficher son Logo. La connexion au Wifi se fait, puis l’écran de lancement apparait

Sur cet écran, on peut voir l’adresse IP de LaBox. Ici 192.168.4.1 . C’est cette adresse que vous devrez spécifier pour vous connecter avec les applications WiThrottle, EngineDriver ou Z21. Dans le cas des deux premières, il faudra aussi spécifier le port 2560 que vous pouvez changer dans config.h s’il ne vous convient pas.

Epilogue
Un programme, c’est comme un réseau, ce n’est jamais terminé ! Il y a toujours moyen d’améliorer, optimiser ou tout simplement de corriger des mauvais comportements détectés tardivement. LaBox, actuellement en version 2.4.0, va évoluer. D’abord en suivant les évolutions de sa base, CommandStation-EX, notamment en intégrant la fonction Railcom dès qu’elle sera disponible. La solution retenue pour le basculement en mode programmation n’est pas très élégante... Je ne désespère pas un jour de trouver un moyen de passer en programmation sans redémarrer l’ESP ! Dans la partie Z21, si le principal, la commande des locos, est entièrement fonctionnel, il reste à piloter les aiguillages comme le font déjà WiThrottle/EngineDriver et la liaison série. C’est déjà en cours, mais ça devrait prendre un peu de temps. Enfin, le CAN devrait aussi faire son apparition. Le matériel a prévu dès le départ cette possibilité permettant à divers acteurs de communiquer avec la centrale en donnant des ordres , DCC ou non, que ce soit pour piloter des locos ou changer l’état d’un aiguillage ou d’une broche de l’ESP32 .
Suivez le forum de LOCODUINO et son Github pour bénéficier des dernières avancées et signaler les problèmes rencontrés.
Pour rappel, il y a une vidéo de démo/mode d’emploi ici.