projet centrale "LaBox" wifi DCC++ Can

[bobyAndCo]

Tu est sur que les xQueue incluent un mécanisme de protection contre les accès simultanés issus de plusieurs taches ?

Bonjour Pierre,

Une fois encore ce n'est pas l'accès simultanés issus de plusieurs taches qui peut poser problème mais que plus d'une tâche puisse modifier les données ou l'ordre des données. Or ici, il s'agit de la base d'un principe de messagerie avec une tâche qui copie les messages reçus les uns derrière les autres dans la file et une autre tâche qui les lit et libère l'espace mémoire une fois fait.

Il s'agit donc avant tout d'un banal sujet de gestion de file et j'espère en effet que les concepteurs ont bien fait le travail dans la classe.

Le code est très proche de l'exemple donné dans la documentation (url au début du programme).

Par ailleurs, les passages des données se fait par référence, ce qui veut dire que les différentes tâches qui peuvent manipuler les données le font toujours sur le même espace mémoire. C'est donc un sécurité pour l'intégrité de la donné. Par contre, ce serait certainement différent si une tâche modifiait l'ordre des données dans la liste et là effectivement il faudrait un mécanisme de sémaphore.

Enfin, il est facile de créer un mécanisme de vérification. Le process 0 envoyant des données incrémentées, il est facile de vérifier dans le process 2 si l'incrémentation est respectée.

Bien amicalement

Christophe

[Dominique]

Bonjour à tous,

Cette discussion sur le multitâche, multi-core de l’ESP32 me conforte sur le bon choix de ce processeur pour ce projet dont la difficulté va se situer dans le logiciel, bien évidemment.

Il est donc important de lister les tâches qui vont résider dans ce processeur et les messages qui devront passer de l’une à l’autre (ou les autres).

• La première est le générateur DCC++ matérialisé dans la bibliothèque DCCpp que Thierry met au point en moment, s’il a le temps. Cette tache comprend le générateur binaire sous interruption qui va traduire sur une broche de l’ESP32 les contenus des registres des trames DCC (traction locos répétitives et fonctions locos non répétitives) en fonctions des commandes DCC++ qui proviendront d’autres tâches :
• Le serveur wifi qui peut avoir 2 types de client : les apps smartphones Wittrottle ou EngineDriver qui envoient des commandes compatibles JMRI mais pas DCC++.
  
• il faut donc insérer un traducteur de commandes entre ce client wifi et DCC++
  
• ou un client gestionnaire si on choisit de piloter les locos depuis JMRI, capable d’envoyer des commandes DCC++, le traducteur n’ayant plus lieu d’être.
  
• les communications sur le bus CAN, soit pour piloter DCC++ à distance (probablement en concurrence avec un/des smartphone/s) à partir d’un gestionnaire sur Can (il n’y en a pas encore sauf chez moi), soit pour accéder à la retrosignalisation des Satellites, ce qui peut induire :
  
• soit un « mini » gestionnaire intégré dans l’ESP32 qui ne serait probablement pas « complet »,
  
• soit une passerelle Can/wifi pour mettre cette retrosignalisation à disposition d’un gestionnaire wifi.
  
• enfin une boîte de configuration de tout cela. Je n’imagine pas tout mettre dans ce pauvre ESP32, je vois plutôt des projets dérivés sur une même plateforme matérielle.
  

Un petit rappel sur le synoptique ci-dessous.

Je n’ai pas forcément listé toutes les opportunités que cette plateforme offrirait, vous pouvez les compléter.

Personnellement j’ai déjà fait le traducteur 3, à refaire au propre dans ce projet. Avec quelque satellites et un micro-gestionnaire, je vois bien le petit réseau que mon petit fils attend dans sa nouvelle chambre 

Bon confinement à tous!
Dominique

[Pierre59]

Bonjour

Pour clore la polémique, j'ai regardé les sources C++ de FreeRTOS, ils utilisent bien des sémaphores pour gérer les "queues". Je pensais bien que c'était indispensable.

Pierre

[msport]

... lister les tâches qui vont résider dans ce processeur et les messages qui devront passer de l’une à l’autre (ou les autres).

Bonsoir,
en ce qui me concerne, j'ai investi sur le bus DCC jusqu'ici (et renoncé à l'I2C), avec donc DCC++ coté manettes et TCO.
Pour me permettre une évolution en douceur vers les satellites en CAN, au moins l'entrée de commandes en serial sur RX/TX me serait nécessaire.

J'ai complété le schéma de Dominique dans ce sens (si je l'ai compris) ...

[Dominique]

Oui c'est ça, le trait sous le traducteur est bien le lien "transparent" comme l'entrée USB série. La Box serait comme une SProg.
La question qui se pose est "sous quelle forme donner accès au port USB de l'ESP32" : faut-il ajouter sur le PCB un convertisseurs serie/USB et une prise USB sur le boitier ?

Cédric demande également de pouvoir rendre accessible le bus I2C avec un prise 3pins (SDA, SCL, GND) et probablement en 5V donc avec des convertisseurs de niveau (2N7000)..

[msport]

Pour l'USB, je verrais simplement une découpe dans le boitier pour accéder au port USB de l'ESP32. Ce que je fais dans mes Base Stations (mais est-ce bien la question ?)
Pour l'I2C on peut prévoir un level shifter comme :
https://www.ebay.fr/itm/New-IIC-I2C-Logic-Level-Converter-Bi-Directional-Module-5V-to-3-3V-For-Arduin-SN/153844938771
comme il y a 4 ports, 2 peuvent servir au RX/TX, mais dans mon cas le module radio HC12 fonctionne en 3,3V, quid de l'I2C pour Cédric (le module peut être coté "esclave", donc externe)

[Dominique]

Ou plus simple avec 2 transistors et 4 résistances :
A noter : When using the ESP32 with Arduino IDE, the default I2C pins are GPIO 22 (SCL) and GPIO 21 (SDA)

[bobyAndCo]

Pour bien comprendre, sur le schéma, ce qui est encadré par un rectangle et qui inclus Centrale DCC++, connecteur passerelle, traducteur, système de gestion de circulation et SAM ..., vous voyez tout cela sur un seul ESP32 ou cela désigne pour vous un ensemble qui lui même peut contenir plusieurs cartes : un ESP32, un Arduino Nano...

Pour me permettre une évolution en douceur vers les satellites en CAN, au moins l'entrée de commandes en serial sur RX/TX me serait nécessaire.

C'est aussi la raison pour laquelle je posais la première question.

La passerelle que j'ai développée sur la base d'un ESP32 inclus également le port série. Il n'y aurait donc pas de problème pour satisfaire cette demande.

Mais si tout ce qui est décrit ci-dessus devait tourner sur un seul ESP32, je crains fort que la pauvre bête ne crève à la tâche.

Pour ma part, je pense qu'il faut concevoir un système modulaire : Centrale DCC++ et passerelle d'une part, système de gestion de circulation, SAM et satellites d'autre part. Tout ceci pouvant faire l'objet d'un seul PCB ou pas.

Il y a une solution simple à réaliser, je veux dire par là qui réutilise des éléments déjà existants :

- Mettre DCC++ sur un Arduino Nano (en attendant DCCpp sur ESP32)
- La passerelle sur un ESP32 (déjà existant), reste à développer le traducteur, long à faire mais pas si complexe
- Système de gestion de circulation et SAM sur une autre carte (ESP32, Mega, Uno, Nano )

Merci pour les précisions apportées.

Christophe.

[DDEFF]

A mon avis, le gestionnaire, même mini, doit être à l'extérieur de la Box.

Dans un monde uniquement DCC, on peut changer la position d'une aiguille en envoyant un ordre DCC (par exemple depuis la Multimaus).
Vu de l'utilisateur, il y a une seule interface (un seul clavier, un seul "écran" d'affichage, un seul bus)
Ici, il n'est pas prévu d'envoyer cet ordre vers le DCC, mais vers le CAN. On est tous d'accords là dessus.

C'est donc plus conséquent : il faut que le clavier et l'écran puissent s'adresser à deux bus, deux bus qu'il faut gérer.
Je ne dis pas que ce soit la partie la plus complexe (loin de là...), mais ça fait des choses en plus à faire.

Et, pour moi, gestionnaire = TCO. Même un TCO basique (3 boutons et 4 LED). A fortiori si le gestionnaire est sur un ordi.
Je ne considère pas que la possibilité de modifier la position d'une aiguille soit de la gestion.

Ce n'est que mon avis.

Je pense qu'il faut raisonner en modulaire et éclater le schéma. Proposition :
1°) On dessine un module par fonction. Au départ, une fonction = un processeur.
2°) On adducte le module au bon bus (DCC ou CAN) et on termine sur un ESP32 (le seul qui soit commun aux deux bus)
3°) S'il reste de la place sur l'ESP, on intègre la fonction directement dans l'ESP. Et on gagne des processeurs, des connecteurs et des CI.

Denis

[Pierre59]

Bonjour

Je pense comme Christophe et Denis que l'aspect modulaire est essentiel, ne fabriquons pas une usine à gaz.

Je pense aussi que les communications entre modules doivent êtres aussi "modulaires". Il serait extremement souple de pouvoir utiliser le maximum d'outils de communications entre les modules.

Pas mal de modules auront en pratique à disposition plusieurs moyens de communications dans une vaste palette :  CAN, WIFI, DCC, Bluetooth, USB, série, I2C, …

Pour pouvoir utiliser indifféremment un moyen ou un autre , il faut avoir un protocole de communication de haut niveau pouvant être implémenté sur tous les outils de communications.

Cela nécessite un format de messages bien précis, simple mais souple. Ce n'est pas le moment de faire des listes de messages, mais plutôt chercher un  format adapté.

Cordialement

Pierre

[Dominique]

Un mot pour dire que vos réactions vont dans le sens attendu : on ne vise pas une usine à gaz, on définit les modules nécessaires et les extensions probables ou souhaitables.
On en déduira les types et formats de messages d’échanges et les messages ensuite.

Je comprends ces 3 avis car nous avons des points communs dans nos projets. Mais j’aimerai avoir 2 autres avis :

- celui de la communauté JMRI qui est concernée par le fait que DCC++ est compatible et qui n’a pas encore manifesté son intérêt pour les satellites.

-celui des experts en programmation/performances pour évaluer la faisabilité de l’intégration de plusieurs processus dans l’ESP32 ( avec DCC++ ou pas).

Je rappelle que, si j’imagine à la cible une petite plateforme pour petits/moyens réseaux, simple à utiliser pour élargir l’attrait de notre discipline, il est tout à fait possible de passer par des stades de prototypes.

[Thierry]

Pour ce qui est de la performance, deux threads, c'est à dire deux coeurs qui marchent simultanément, c'est équivalent à deux Nano (à la vitesse d'un coeur ESP...) complètement séparés. La seule contrainte serait le partage de données qui obligerait un thread à attendre l'autre. Mais si on répartit les choses logiquement, c'est à dire un thread pour DCCpp avec ses propres données, et un autre pour la communication vers l'extérieur, ou même un gestionnaire, ça peut tout à fait fonctionner. A moins qu'il n'y ait quelque chose que je ne vois pas.

A noter que ces jours ci je travaille, mais je vais très probablement me remettre à l'ESP ce week end...

[Dominique]

Dans cette image, il ne faut pas voir le mot "Arduino" comme un seul et unique processeur ! Mea Culpa si ça vous enduit d'erreur 



Je démultiplie et je donne des exemples :

• boite verte, la centrale DCC++ : on a tous plus ou moins réalisé une ou plusieurs centrales minimales avec un Nano et le logiciel DCC++ de Gregg ou celui DCCpp de Thierry. Nous avons là un processus (générateur DCC) qui peut être aussi un processeur dédié. Généralement on utilise DCC++/pp soit en système autonome (comme mon Va-et-vient) ou piloté par une ou des manettes (comme Antoine avec un éméteur/récepteur), ou par un PC (avec JMRI ou le gestionnaire de Pierre). Dans cette application, on a besoin de piloter uniquement des locos (traction et fonctions) et/ou aussi piloter des accessoires de voie (aguilles). DCC++ sait le faire sous forme de trames DCC (NMRA) sur les rails. Un peu de rétrosignalisation est aussi possible
• Donc attaquer DCC++ par le port USB/série à la mode SProg est un minimum syndical !
• Je n'ai pas fait figurer de port Ethernet RJ45 mais j'ai plutôt privilégié l'accès Wifi. Il faut donc un serveur wifi qui assure la connexion sans fil et transmet dans les 2 sens les ordres DCC++. C'est le mode de fonctionnement de JMRI. Les messages échangés sont ceux de DCC++ . Le serveur wifi (en jaune sur le schéma) peut être séparé du processeur DCC++ (comme je l'ai montré sur la photo du post ici : https://forum.locoduino.org/index.php?topic=922.msg9656#msg9656 avec un ESP8266 et un Nano.
• On peut évidemment profiter du serveur Wifi pour traduire les commandes de manettes "non DCC++" en commandes DCC++. C'est déjà fait pour ma part avec les applications Withrotle et Engine Driver (au passage on découvre un autre type de messages, format et contenus différents). C'est le mot "traducteur" sous la boite jaune "Connecteur Passerelle"
• Après il y a 2 gros trucs qui ne parlent pas à tout le monde de la même façon : le CAN et le gestionnaire
• Pour le Can, l'idée simple est l'utilisation des satellites présentés à Orléans et Lille mais malheureusement peu utilisés. Rappel : c'est l'interface la plus simple possible et fiable entre le système de gestion et la rétrosignalisation (capteurs et actionneurs). Mais cela apporte des contraintes :
  - Il y a l'interface SAM (boite orange - une bibliotheque ou pas) qui gère les communications Can et présente les appareils de façon standardisée en masquant les détails (quelle led dans quel signal par exemple)
  - JMRI n'a pas encore d'interface compatible SAM, ce qui pousse ses utilisateurs vers d'autres interfaces décrites dans le sujet ad hoc http://forum.locoduino.org/index.php?board=22.0. C/MRI est probablement une brique à ajouter dans cette architecture (après étude de faisabilité et prototypes).
  - Le système de gestion n'est pas forcément intégré dans ce projet, comme le soulignent Denis et Pierre, ce qui est le cas de JMRI évidemment, mais ce qui n'empêche pas d'en mettre un comme un automate qui serait très utile si nous trouvons un système de configuration simple et efficace : zone de forte créativité possible ici !
• Maintenant il est envisageable de remonter la rétrosignalisation par le Wifi ou l'USB : je ne sais pas si JMRI en est capable, ou d'autres gestionnaires sur PC. Il faudrait surement une interface spécifique type C/MRI déjà mentionné.
• Enfin, le Gestionnaire (en bleu) qui peut être complètement extérieur ou simple et interieur ou une combinaison des 2 si on imagine une extension des commandes DCC++ : encore une zone de créativité possible ici !

Voilà une première tentative pour décortiquer ce projet et vous demander ce qui vous semble indispensable ou qu'il manque dans cette boite !
On ne peut pas encore affirmer s'il faudra 1, 2 ou 3 Arduinos pour y parvenir mais, après un phase de maquettes et prototypes, j'espère fortement qu'on aboutisse à une plateforme "Locoduino" assez universelle pour couvrir de nombreux cas d'usage et peu onéreuse.

Bien cordialement et bonne santé surtout.

Dominique

[msport]

A mon avis, le gestionnaire, même mini, doit être à l'extérieur de la Box.

Dans un monde uniquement DCC, on peut changer la position d'une aiguille en envoyant un ordre DCC (par exemple depuis la Multimaus).
Vu de l'utilisateur, il y a une seule interface (un seul clavier, un seul "écran" d'affichage, un seul bus)
Ici, il n'est pas prévu d'envoyer cet ordre vers le DCC, mais vers le CAN. On est tous d'accords là dessus.

...

Denis,

de mon coté, je vois ce projet comme une centrale et non comme une console.
j'ai déjà réalisé nombre de manettes et mini TCO permettant de commander respectivement locos, aiguilles et accessoires avec DCC++
Dans mon optique si il y a plusieurs locos sur le circuit, il y a autant de manettes. Plus celle(s) pour les aiguilles, la plaque tournante, les PN, les rails décrocheurs.
j'aimerai bénéficier du CAN pour fiabiliser les échanges entre le réseau et la centrale via les satellites et la signalisation. Surtout pour la rétrosignalisation.
j'aimerai utiliser JMRI (ou CDMrail) pour automatiser mes circuits, donc avec DCC++.
de là, l'IHM (OLED, boutons, ...) sur cette centrale doit juste permettre de la configurer (et de tester à minima sa fonctionnalité, cf Dominique)

[DDEFF]

Pour les démos, je propose trois modules :

1°) un module CAN avec un servo, une LED et un détecteur de consommation (on n'a pas besoin d'autre chose)
2°) un autre module CAN avec trois BP et une LED (c'est un TCO, si, si !) Je mets 3 BP : 2 pour commander le servo et un pour arrêter le train.
3°) une interface DCC

On branche "tout ça" à un ESP32 et on voit comment gérer.

Puis on augmente progressivement : plusieurs modules pour voir si on on gère bien les adresses.

Et après, le wifi, les bus I2C, USB ....

Denis
Pour Michel :
Dès que l'on aura une idée précise des messages sur le CAN, je ferai tout pour que mon gestionnaire soit compatible.