LOCODUINO

LaBox, la centrale DCC de Locoduino

LaBox, Une Centrale DCC polyvalente et abordable (3)

Enfin le bon logiciel !

.
Par : Thierry

DIFFICULTÉ :

Après la V1, on passe à la ... V2 ! J’en vois qui ne suivent pas. Tant pis, je continue.

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 !

Image du modèle d'ESP32 utilisé pour LaBox.
Figure 1
L’ESP32 DevKit utilisé pour LaBox. Notez les 30 broches et la position des trous de fixation pour le reconnaitre.

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();.

Ecran OLED du mode programmation
Figure 2
Ecran du mode programmation. Les options en bas permettent de recommencer la lecture ou de sortir...

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

Figure 5
Figure 5
Logo, puis connexion Wifi, puis écran de lancement.

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.

7 Messages

  • LaBox, Une Centrale DCC polyvalente et abordable (3) 15 décembre 2023 17:25, par Erik Arckens

    Si je vous comprends bien c’est que le logiciel DCC-EX est trop chargé avec des options/extras/extensions/... souvent inutiles (ce qu’est mon idée déjà avent d’avoir lû votre article) ?

    Par example les options I2C surpasse les restrictions du hardware I2C, c’est à dire les messieurs de -EX ont décidé qu’il faudrait pouvoir acceder des I/O à des distances de plus que quelques dizaines de cm, voire des dizaines de mètres dans leur cas ?

    Répondre

  • LaBox, Une Centrale DCC polyvalente et abordable (3) 15 décembre 2023 17:46, par msport

    Bonjour,

    Certaines options/extras/extensions dont on ne sert pas, sont effectivement inutiles dans le cas de LaBox qui est une plateforme hardware spécifique.
    Mais plus généralement, les développeurs de DCC-EX ont prévu des options/extras/extensions qui sont ou non sélectionnées quand on utilise leur Installer.
    Et comme ils n’ont développé que du software, il n’y a aucune chance qu’ils aient pu modifier les caractéristiques physiques de l’I2C. Pouvez vous préciser votre pensée ?

    Répondre

    • LaBox, Une Centrale DCC polyvalente et abordable (3) 16 décembre 2023 08:26, par Erik Arckens

      Bonjour, merci pour ta réponse.
      1. L’utilité "Installer" je ne veux pas utiliser, par contre je préfère avoir le code pour faire une programmation directe du ESP32 (ou cela pour n’importe quel microcontroleur et pour n’importe quelle porgramme). Donc j’utilise ce qu’il y a disponible sur leur Github pour avoir accès directe au programme.
      2. Le groupe de DCC-EX utilise I2C sans regard avec les contraintes du protocol I2C. C’est à dire que Philips (l’inventeur du I2C) a conçu I2C pour communications à courtes distances comme l’on a sure des platines à circuit imprimé. Le fait de vouloir l’utiliser à des distances alant aux dizaines de mètres à contraint la diminution artificièle des fréquences d’origine au I2C. Voire d’inombrables discussions sur leur discord entre des gens exaspérés par des erreurs de communication avec I2C.
      Donc j’estime les développeurs du DXX-EX à ne pas avoir assez d’astuce pour les aspectshardware du projet.

      Le même s’applique à leur commande des tables rondes (turntables) oú ils utilisent un détecteur HAL pour la calibaration de cette table ronde. Un détecteur HAL n’a pas la précision requis pour continuellement positioner la table à la position exacte nécessaire pour un bon allignement.
      J’ai fait des tests inombrables avec des détecteurs pour mes propres "turntable" et en fin de compte je suis arrivé à un détecteur optique spécifique. Avec lequel la précison répétitif de calibration se trouve dans un maximum de déviation de 0.1mm environ, mesuré avec un micromètre.

      Donc pour en revenir à notre sujet, si je comprends bien, il n’est que possible d’éliminer les options non-voulues en utilisant leur "Utilité d’installation" ?

      En plus ce qui m’intéresse à votre project ce qu’il utilise cette possibilité d’éliminer des partis du software DCC-EX que je considère comme "bloated" (ne connsaissant pas de mot applicable français, excusez-moi svp).

      Répondre

      • LaBox, Une Centrale DCC polyvalente et abordable (3) 16 décembre 2023 09:48, par Thierry

        Bonjour. Le retrait des parties sans intérêt pour LaBox s’est fait à la main avec trois objectifs : simplifier le projet en retirant les parties inutiles, limiter l’occupation mémoire, et respecter autant que possible le codage d’origine. Ce dernier point est important parce qu’il me permet de comparer notre branche LaBox avec la branche Master originale de CommandStation-EX pour intégrer les corrections/améliorations qu’ils y apportent avec un minimum de travail. Le retrait de ces sources ’inutiles’ serait sans doute encore perfectible, mais la volonté de laisser les autres sources intacts ou presque a imposé la présence de certains fichiers .h ...

        Répondre

  • LaBox, Une Centrale DCC polyvalente et abordable (3) 17 décembre 2023 08:04, par Erik Arckens

    Bonjour Thiery, est-il possible d’installer votre verions (reduite) du code de DCC-EX sur un ESP32 et la faire fonctioner comme Station Commande DCC, avec une carte moteur connectée ?

    Les signaux DCC ne seront ils pas "déformés" par les interruptions internes au ESP32, liés au fonctionement du Wifi à bord ?

    Erik

    Répondre

    • LaBox, Une Centrale DCC polyvalente et abordable (3) 17 décembre 2023 15:34, par Thierry

      Bonjour
      Comme je l’explique dans l’article, ce ne sont pas les interruptions, mais le mode RMT qui est utilisé pour générer les trames DCC. Et vu la bonne qualité des trames reçues et testées par notre sniffer DCC, ce mode RMT, destiné à la base à faire de la musique ou à traiter des signaux de télécommande, ne semble pas être affecté par le Wifi...

      Répondre

  • Bonjour.

    Cette évolution logiciel garde t-elle la compatibilité avec les modules HC-12 utilisés pour la manette radio prévue pour LaBox V1 et décrite dans Locoduino ?

    Répondre

Réagissez à « LaBox, Une Centrale DCC polyvalente et abordable (3) »

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)

Rubrique « Projets »

Les derniers articles

Les articles les plus lus