Les SATELLITES AUTONOMES: évolutions du socle initial

[laurentr]

Je voudrais aussi revenir sur la TOPOLOGIE "vision satellite".

C est une architecture distribuée ( elle n est pas concentrée en un endroit du réseau mais repartie au long du tracé)) et regroupée ( au moins à ce stade) qui inclue sur un socle les fonctions de:
a/identification des trains
b/gestion des aiguillages (par servo)
c/détection d'occupation et de mouvements
d/affichage de la signalisation
e/interaction avec ses "voisins" selon les tracés
f/commandes des engins (arret, ralentissement, démarrage...)

Les bloc fonctionnels sous forme de bouclier sont bien sure utilisables dans d'autres contextes ( ils ne seront pas moins chères pour autant!)  mais cela ne se fera qu'au compromis d'approches différenciées au niveau topologie.

Par exemple sur une ligne CAN avoir des décodeurs locaux par usage ( ex signaux, servo, ...) Mais c'est la une autre paire de manches à traiter surtout pour facilement mettre cela en "musique" sans passer des heures à coder... Ou alors il faut une IHM sur un système central qui assure les arbitrages... autre vaste sujet!


Ltr

[laurentr]

Une extension au "NORD" des RJ45 est possible sous cette forme...

A vous de me dire ou va votre préférence...

Ltr

[bobyAndCo]

Bon tu vas vraiment me prendre pour un ch*eur mais l'avantage du RJ45 (dans la version initiale) c'est que l'on fait passer également le courant. Dans la dernière version, j'utilise 6 fils sur 8 pour cela (les 2 autres pour le CAN).

Mais bon, je donne juste mon avis !

Christophe

[laurentr]

Non ne t inquiète pas!

Si je demande c'est bien que je ne suis pas fermé à toutes adaptations! La preuve! ( mais je l ai glisse hors du CPB 10x10 pour des raisons de place/volume sinon il faut passer à un peu plus grand...)
Tu penses qu'il faut passer à plus grand et les mettre en natif sur le socle principal?

J ai bien utilisé le même mapping que toi sur les utilisations de broches RJ45.

J'en profite pour glisser l'EXTENDER "SUD" gérant les 74HC595 pour le signaux. (EXTENDER SHIFT REGISTER 74HC595)
Ici réalisé en composants traversants, pour le plaisir de monter quelques cartes et d'utiliser mes stocks!

En complément du bouclier principal voici ce qui complète à merveille ce dernier avec l'EXTENDER RJ45 pour s'assimiler pratiquement à un "V1" dont le mapping des I/O est juste modifié pour le routage.

Ltr

[bobyAndCo]

Ah je trouve ça super pour l'extender des 74HC. Et celui qui ne veut pas mettre de signalisation ou pas tout de suite n'est pas pénalisé.

Du coup avec la place gagnée, peux tu mettre les RJ45 sur la carte principale. Mieux selon moi pour des raisons de fiabilité de connexions.

[laurentr]

C est un peu trop juste pour les ajouter nativement sauf à forcer en 130x100mm minimum.

Avec les connecteurs mis en place les contacts sont "sérieux", il n y a pas trop d'inquiétude à avoir et on passe jusqu'à 3A par broche si besoin...

C est du contact au pas de 2,54mm très standard (type connecteur IDE).
Chaque platine bien fixée aucun soucis à prévoir. ( la languette du câble RJ45 aura rendu l'âme avant!)

Pour les expenders c est selon les besoins "à la carte". On a besoin on utilise, on a pas besoin on fait bien sans

Idem pour les boucliers ( encore que...!) on bouchonne avec un PCB "dummy" afin de ponter les I/O entrées/sorties ( faut que je les dessine ceux la!)

Pour le moment je vais me glisser à l"OUEST" avec les expenders optionnels.

Ltr

[laurentr]

Bonjour

Ma méconnaissance de certaines subtilités de l'ESP32 m'avait amener à faire des choix de mappings pour la distribution des usages.

En effet lors de la phase de boot du CPU il est impératif que certaines broches soient dans des états très précis (hauts ou bas)

C est le cas des PIN suivantes qui doivent alors être lors du BOOT dans une configuration précise:

source : https://lastminuteengineers.com/esp32-wroom-32-pinout-reference/

PIN13 IO:12 BAS
PIN35 IO:15 HAUT
PIN34 IO2: BAS
PIN33 IO0: HAUT
PIN29 IO5: HAUT

Bien sure, je n'ai pas vu cette subtilité initiale et je vais devoir revoir certains mappings pour me conformer avec cette impératif.

2 états hauts peuvent être trouvés facilement avec le bus I2C et les résistances de tirage.
un état bas aussi en lui attribuant la broche TX du RAILCOM qui n'est pas utilisée.

Il reste alors 2 broches, une de chaque état à trouver.

Pour les broches en état haut une astuce peut être utilisée via la détection/signal railcom qui est par défaut en état HAUT si il n y a pas de détection ou si le circuit gérant la protection n'est pas encore basculé pour rendre actif la distribution du DCC vers ses consommateurs! Subtile oui mais si on bouchonne ces modules on perd cette opportunité...

Je vais donc me pencher sur ce qui est optimisable à ce niveau... et revoir en conséquence les mappings et le routage qui en découle.

C est la phase troubleshooting!

Ltr

[bobyAndCo]

Attention avec le mapping. On parle ici du WROOM. Tu ne donnes pas le bon lien qui est celui-ci :

https://lastminuteengineers.com/esp32-wroom-32-pinout-reference/

J'ai attribué GPIO17 à Railcom TX (qui ne sert pas) car elle n'est pas utilisable autrement. Pas plus que GPIO16 sans que l'on sache vraiment pourquoi mais je l'ai moi-même constaté !!!

Voir ici : https://esp32.com/viewtopic.php?t=3390

Et quand tu regardes ici : https://www.upesy.com/blogs/tutorials/esp32-pinout-reference-gpio-pins-ultimate-guide

il est bien spécifié :

16 YES YES Not available on WROVER
17 YES YES Not available on WROVER

[CATPLUS]

@  Mr Etienne66
Polémiques.

Bonjour Monsieur,

Je viens de lire votre intervention sur le travail de Christophe, vos remarques sont très pertinentes et surtout en dehors du sujet.
Si le coût est élevé (pour vous) personne oblige personne de faire ce ou ces montages.
Comme tous les forums, ici les contributeurs donnent et surtout partagent leur modeste savoir.

[laurentr]

Bonjour

J ai identifié l'origine des numéros de broches (pas des IO ESP32) liée à une empreinte KIKAD n'ayant pas la même distribution.

Je vais agencer celle ci pour respecter la convention utilisée dans les liens indiqués.

Par ailleurs, j'ai donc un peu repris les MAPPINGS et le routage correspondant afin de respecter les contraintes des broches lors du BOOT de l'ESP32.

Avec cette disposition les contraintes sont normalement couvertes dans les différents cas de figure. ( notamment sur la PIN IO15 qui peut sortir des états fluctuant lors du boot, ici sans incidence sur le SCL (CLK)  de l'I2C)

Le switch de changement d'état du module de protection n'est volontairement pas lié à EN ni a CMD_SW_STATE ce qui aurait pour conséquence dans le premier cas de rebooter l'ESP32 ( pourquoi pas dans l'absolu!) ni de passer en mode PROG dans le second cas.

Les servos 1 et 2 sont "sacrifiés" en cas de module WROVER mais devraient normalement fonctionner avec un module WROOM 32.

On alors à disposition en standard sur modèle WROOM 3 servos :Servo 0, Servo1 et Servo2  et la signalisation sur les 74HC595.

On monte jusqu'à 6 servos sans 74HC595( sans signalisation sur ce canal)  avec un WROOM: 0 1 2 3 4 5.

Avec un WROVER on alors 1 servo : servo0 et les sorties signalisation sur 74HC595 ou 4 servos sans le 74HC595 ( sans signalisation via ce canal).

Tout ceci ouvre aussi la voie à une intégration simplifiée de modules ESP32 en natif (sans le support) mais avec ajout d'un connecteur de programmation, d'une régulation 3V3 et de minima 1 bouton(RST), rien de trop ardu d'autant que la place sera la pour ces éléments.

En cas de besoin de ressources HARD supplémentaires ou d'indispo un swap de module CPU devient alors plus facilement possible.

A noter qu'avec la compilation du code natif de Christophe les ressources sont en sortie de compilateur pour run ESP32 WROOM 4Mo ( CPU de type S3) :
RAM : 6.8%
FLASH: 17,1%

Pour un CPU de type WROVER
RAM:6.8%
FLASH: 18.1%

Un portage sur une version mono CPU serait intéressante ( core version C3)  mais comme le code alloue des taches au second core... il faut vérifier les impacts si retour sur le premier...

Christophe saura mieux que personne nous dire si cela tient du domaine du possible ou non.

Ltr

[laurentr]

Question subsidiaire:

Que se passe t il si on met les GPIO16 et 17 en usage ( ex RAILCOM TX ) avec un WROVER dépourvu de connexion "IO17" ( et"16) ?

En principe de ce que j ai lu c est la connexion physique qui n'est pas reliée aux sorties du module mais en interne... quelle est la "cuisine"  si on fait ce mapping?

BIG question!


 @Christophe: tu penses que de mettre les servos 1 et 2 sur les pins 16 et 17 du WROOM passe finalement? Tu semblais laisser entendre que non...

Ltr

[bobyAndCo]

Le double cœur est primordial mais la mémoire flash ne constitue normalement pas un problème. 4Mb, c'est peu et beaucoup.

De plus il existe des moyens pour répartir la mémoire flash différemment, en prenant par exemple sur la mémoire allouée par défaut à l'OTA qui est je crois de l'ordre d'1Mb. Pas d'OTA donc, mais de toutes façons, en exploitation, le satellite autonome n'a pas de WiFi !!!

Dans ton calcul de la mémoire flash, il faudrait aussi prendre en compte les fonctions qui sont programmées pour "tourner" en mémoire flash et il y en a quelques unes dont la plus importante "void IRAM_ATTR GestionReseau::loopTask(void *pvParameters)" signalé par "IRAM_ATTR"

Evaluer cela sur ESP32 n'est pas très simple et, pour moi en tous cas, plutôt empirique et résultat de tests avec des "charges" de plus en plus importantes pour trouver les limites.

Christophe

[bobyAndCo]

Question subsidiaire:
 @Christophe: tu penses que de mettre les servos 1 et 2 sur les pins 16 et 17 du WROOM passe finalement? Tu semblais laisser entendre que non...

En fait, il ne se passe rien ! Si tu fais par exemple un digitalWrite sur l'une ou l'autre de ces deux pins, et bien rien ne changera !!!

Par contre, tu peux les utiliser pour certaines instances comme justement Serial.begin() qui peut n'avoir que le paramètre de débit comme c'est souvent le cas ou quatre paramètres comme mySerial->begin(250000, SERIAL_8N1, m_rxPin, m_txPin); pour Serial1 et Serial2 mais pas trois paramètres.

Christophe

[laurentr]

Re

Hormis le futur ESP32 P4 qui doit arriver cette année et qui sera un monstre coté CPU en sacrifiant au passage le WIFI!... on reste bien dans le besoin absolu de 2 cœurs ( jusqu'à démo du contraire)

Donc tout module de type "S3" peut convenir.( ou module ESP32 " historique" à base de double cœur)

J'ajoute que pour les SAT V2 à ce stade  il faut un modèle avec 38 broches! ( le même que sur la V1) (ce qui cible les achats d ESP32 avec ces caractéristiques)

Ltr

[laurentr]

Question subsidiaire:
 @Christophe: tu penses que de mettre les servos 1 et 2 sur les pins 16 et 17 du WROOM passe finalement? Tu semblais laisser entendre que non...

En fait, il ne se passe rien ! Si tu fais par exemple un digitalWrite sur l'une ou l'autre de ces deux pins, et bien rien ne changera !!!

Par contre, tu peux les utiliser pour certaines instances comme justement Serial.begin() qui peut n'avoir que le paramètre de débit comme c'est souvent le cas ou quatre paramètres comme mySerial->begin(250000, SERIAL_8N1, m_rxPin, m_txPin); pour Serial1 et Serial2 mais pas trois paramètres.

Christophe

J aurai alors tout intérêt à laisser IO17 avec serial TX pour le RC... et substituer les servos avec. Ca fait gagner 1 servo.

En revanche il faut être sur que cela ne vas pas influer sur les accès du CORE vers le module PSRAM... ( d après ce que tu dits ca semble bon)