projet centrale "LaBox" wifi DCC++ Can

[DDEFF]

Bonsoir Dominique,

Je reste un fervent défenseur du CAN. Je ne vais pas me renier (et j'ai même fait un article dessus et j'en reste très fier)
Mais entre le gestionnaire et le réseau.

On peut le garder pour la centrale DCC. Pourquoi pas ?
Je dis simplement que c'est luxueux ... à cet endroit. Et INDISPENSABLE ailleurs, entre les modules V1/V2 et le gestionnaire.

Ce que j'ai abandonné, c'est vrai, c'est de caser un gestionnaire COMPLET dans un processeur.
A part des cas très particuliers, qui fonctionnent parfaitement, et tes réalisations en sont la preuve, je suis persuadé qu'il n'y a pas la place.

Les logiciels classiques (Trains Controller, JMRI, ...) gèrent le réseau sur un ordi et utilisent la centrale effectivement quasiment comme un booster, comme l'a dit msport.
A une nuance près, importante :
La gestion qui doit être dans la centrale DCC, c'est la gestion du ralenti, de l'accélération, de l'inertie, des fonctions. Et là, on n'est plus dans le booster.

Question : il y a un bus CAN dans la centrale parce qu'on envisage de commander les aiguilles, de créer des itinéraires, d'afficher les occupations de zone ?
Alors là, oui, il faut un CAN. Et un écran plus grand ou une interface vers un TCO physique.
Mais ce n'est pas ce que j'avais compris au départ.

Denis

[DDEFF]

Analysons le positionnement des différentes fonctions et des infos échangées :

Depuis un mobile, en Wifi, et avec l'appli JMRI qui va bien (suivant IOS/Android), on commande non seulement les trains, mais aussi les aiguilles.
Donc, il existe un "traducteur CAN" d'une action sur un bouton virtuel sur le mobile vers une commande CAN adressée au module V1/V2 destinataire.
Ce traducteur est forcément dans la centrale.

De même, il existe un "traducteur DCC" d'une action d'un potar virtuel sur le mobile vers une commande DCC vers les rails pour commander les locos.
Ce traducteur est forcément dans la centrale.

Dans l'autre sens, le réseau envoie via le CAN des infos d'occupation (entre autres) qui, à priori, ne vont pas à la centrale SAUF si celle-ci gère un TCO sur écran ou physique.
Sinon, ces infos vont directement au gestionnaire externe sur ordi.

Quant aux infos type lecture de CV, elles sont acheminées via les rails vers la centrale. Et ne concernent pas le gestionnaire externe, à priori.

Si on a un gestionnaire externe, soit il est relié directement par USB ordi <-> centrale et on utilise les traducteurs précédents en envoyant dans l'USB les ordres qui vont bien et qui simulent les actions sur les mobiles.

1°) Bouger un potar sur l'écran de l'ordi ou bouger un potar virtuel sur un mobile aboutissent au même traducteur DCC et donc ont le même effet.

2°) Commander un itinéraire de, mettons, 3 aiguilles sur le gestionnaire PC aboutiront à l'envoi de 3 ordres sur l'USB, équivalents à 3 appuis sur les boutons virtuels sur un mobile et via le traducteur CAN de la centrale vers les aiguilles choisies.

Autre solution : on n'a pas de connecteur USB dans la centrale.

On fait une interface USB <-> CAN avec un traducteur CAN direct (la commande du gestionnaire n'emprunte pas le traducteur CAN de la centrale)
Ce traducteur CAN gérera aussi les actions sur la vitesse (les 5 messages du précédent post) et les 29 fonctions vers le traducteur DCC de la centrale.
Et, dans l'autre sens, l'interface récupère toutes les infos en provenance du réseau via le CAN.

Denis

[Dominique]

On peut représenter le projet sur la figure ci-dessous qui tient dans un ESP32 :
- une centrale DCCpp
- une interface wifi pour 2 types de clients (pas forcément en même temps :
    - un gestionnaire type JMRI (avec ses manettes)
    - des manettes smartphone en direct (avec traducteur Withrottle <-> commandes DCC++)
- une interface Can pour communiquer avec les satellites
- un mini-gestionnaire de circulation (à inventer avec interface de programmation : le concours est ouvert !!!)

reste à savoir si c'st faisable !

[Dominique]

Les logiciels classiques (Trains Controller, JMRI, ...) gèrent le réseau sur un ordi et utilisent la centrale effectivement quasiment comme un booster, comme l'a dit msport.
A une nuance près, importante :
La gestion qui doit être dans la centrale DCC, c'est la gestion du ralenti, de l'accélération, de l'inertie, des fonctions. Et là, on n'est plus dans le booster.

Tu as raison pour les réseaux assez grands comme ceux que tu traites dans ton logiciel : la modélisation (définition) du réseau (cantons, aiguilles, signaux, itinéraires, beaucoup de trains) avec une IHM de configuration demandent un PC a part entière, pour adresser tous les cas possibles.
La centrale fabrique surtout les trames de bits 0 et 1 des commandes DCC avec des timings rigoureux que le booster traduit en tension et courant.

Mais on oublie plein de cas :
Je vois bien sur le site nombre de modélistes qui démarrent avec des réseaux simples et qui n’ont pas besoin d’un RRTC ou un JMRI pour faire quelques manœuvres même sophistiqués. On devrait pouvoir intégrer dans cette centrale, outre les accélérations et ralentissements, quelques scenarii de manœuvres sympa, sous forme de lignes de commandes.
Des trains automatiques aussi sont possibles tant qu’il ne doivent pas traverser le grill de la gare saint lazare !
A partir d’une certaine taille de réseau (comme le mien) j’admet qu’il faut un gestionnaire externe, ce que je fais, sur le Can évidemment, mais sans PC . Chacun reste libre !

[DDEFF]

Des trains automatiques aussi sont possibles tant qu’il ne doivent pas traverser le grill de la gare saint lazare !

Ah ? Toi aussi, la reproduction en HO à Railexpo du grill de la gare St Lazare (Tranchée des Batignolles), ça t'a marqué ?
C'est vrai que Jean-Paul Guimbert (Régions & Compagnies) a fait très fort !
Je ne le connais malheureusement qu'au travers des photos de Loco Revue Janvier 2020, mais c'est impressionnant.
Ceux qui l'ont vu et qui me connaissent ont dû se dire : c'est un réseau pour Denis ! 

Pour les petits réseaux, bien sûr, pas d'ordi. Et tu as raison : ce sont les plus nombreux.
Je propose de faire une interface CAN pour TCO physique (boutons et LED).

Un traducteur direct bouton poussoir -> CAN  vers les satellites pour les aiguilles
On peut bien sûr pré-programmer un bouton qui fait un itinéraire : il enverra autant d'impulsions que nécessaire pour que les aiguilles soient toutes orientées dans le bon sens. Un séquenceur.

Un traducteur direct bouton poussoir -> CAN vers la centrale pour les 5 ordres de vitesse (maxi) pour ceux qui ne veulent pas commander avec un mobile (et il y en a)
En général, seul l'ordre d'arrêt est utilisé.

Exemple de configuration :
Je gère manuellement 2 trains en DCC.
En bas du TCO, 2 boutons poussoir (un par train)
Sur chaque voies de gare : un bouton poussoir.
Je veux arrêter le train 2 voie 1.
J'appuie simultanément sur le bouton du train 2 et de la voie1. L'ordre est mémorisé.
Quand on a l'occupation de la voie 1, on envoie l'ordre dans le bus CAN -> centrale DCC.
Nota : on récupère le fait que c'est bien la centrale qui gère les ralentissements, ce qui fait que le train s'arrête doucement.
On peut même sécuriser avec un ILS au pied du signal qui donne l'arrêt complet du train (on est alors contents d'avoir mémorisé le numéro du train  )

Et un dernier traducteur CAN -> LED qui récupère le message d'occupation envoyé par le satellite et allume la LED.

En général, il n'y a pas de signalisation sur les petits réseaux. C'est là que commencent les ennuis ...

Denis

[msport]

C'est là que commencent les ennuis ...

... Et les choses intéressantes !

[Dominique]

Et oui, avec des satellites on gère les signaux comme les aiguilles et les détecteurs !

[DDEFF]

Et oui, avec des satellites on gère les signaux comme les aiguilles et les détecteurs !

Oui, ... mais non.
La couleur du signal à afficher est complexe à calculer.
Quand je dis que c'est complexe, je sais de quoi je parle.

Ce n'est pas envoyer l'ordre "allume le Carré" qui est dur, c'est de déterminer qu'il faut allumer le carré.
Sur des réseaux de pleine voie, c'est facile. Dans le gares....
Les R, RR, Cv sont de vraies chausse-trappes. Et le Carré qui peut être manuel...
Mais sur de petits réseaux, dont on parle ici, c'est facile à déterminer.

Pour votre info, je suis actuellement sur le rouge clignotant pour entrer à 15 km/h dans une zone occupée (UM, wagons à raccrocher, ...).

Denis

[bobyAndCo]

Bonsoir,
Avec Dominique, on pensait qu'il fallait pouvoir profiter de l'ESP32 et notamment de ses doubles coeurs processeur.
L'ESP32 embarque le FreeRTOS, un OS temps réel puissant mais qui pour autant un peu bridé par Arduino IDE qui n'exploite au final qu'un coeur (le coeur n°1, sachant que le coeur n°0 ingère de l'idle pendant ce temps).

Cédric,

C'est à mon sens une très bonne suggestion pour une utilisation puissante et optimale. Et très simple à mettre en œuvre

Après on entre dans le domaine du multitâche / multi thread donc attention aux MUTEX qu'il faudra gérer à la pogne si nécessaire.

FreeRTOS dispose d'une API de "Queue" pour la communication entre tâches très simple à utiliser également et aussi très riche en fonctionnalités. Voir ici à partir de la page 109 : https://www.freertos.org/Documentation/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide.pdf


Bien amicalement.

Christophe

[Pyk35]

Bonjour Christophe,

La doc de FreeRTOS est vraiment bien faite, merci pour le lien.
Le mécanisme de Queue est bien décrit ; il faudra maintenant, selon nos choix d'implémentation, identifier les données à échanger par ce mécanisme pour un fonctionnement safe.

A+

[Dominique]

Très interessant, mais est-ce accessible à l'Arduino IDE ?

[Pyk35]

Très interessant, mais est-ce accessible à l'Arduino IDE ?

Je pense que oui car le fonction pour affecter une tâche à un coeur vient de là donc toute l'API doit être utilisable.

[DDEFF]

Dans les deux derniers Elektor (j'ai eu le dernier hier soir avant la fermeture), une série d'articles :
"Le multitâche en pratique avec l'ESP 32"
Je n'ai pas tout lu, sauf qu'il y a maintenant 25 (!!) niveaux de priorité, de 0 à 24.
Cela ne va pas être triste à gérer...

Moi, à mon humble niveau, je vais plutôt me concentrer sur les messages à échanger, de façon aussi détaillée que possible, en particulier pour des échanges de haut niveau avec un gestionnaire complet. Après, je laisserai les spécialistes mettre ça en musique dans l'ESP32.
Par exemple, l'occupation des zones doit avoir la priorité la plus élevée dans le CAN.

Denis

[Pierre59]

Bonjour

Je ne pense pas que pour le moment cela soit bien utile de faire une liste complète des messages.

L'expérience de la mise au point du Locoduinodrome pour Orléans m'a montré que si avais pu modifier ou ajouter des messages j'aurais pu corriger quelques anomalie beaucoup plus facilement.

Je pense qu'il faut définir un format de messages suffisamment souple et ouvert, la liste des messages viendra petit à petit.

Ces messages doivent êtres de haut niveau et il ne faut pas se préoccuper à ce niveau du support physique qui sera utilisé, mais on peut prévoir des messages plus urgents.

J'ai du il y a quelques temps, pour des essais, remplacer la communication USB/Série entre le Mac et l'Arduino pour une liaison réseau (wifi en l'occurence), j'ai juste du changer quelques lignes dans les deux programmes et en 5 min cela marchait.

Cordialement

Pierre

[bobyAndCo]

En lisant l'article de Denis, j'ai vu que les différentes tâches pouvant être programmées sur un ESP32 et exécutées sur le core0 et le core1 partageaient le même espace mémoire.

Concrètement, cela veut dire qu’une variable globale peut être vue et manipulée par les différentes tâches. Voir l’exemple simple ci-dessous.

Ce n’est bien sûr pas le plus recommandable mais après tout, tant qu’il n’y a pas de corruption des données ou de fuites de mémoire…

En fait, je travaillais sur le passage de valeurs entre les tâches par l’intermédiaire de files, ça m’a fait une petite distraction.

Code: [Sélectionner]


TaskHandle_t Task0;
TaskHandle_t Task1;

int intVar = 0;

void setup() {
  Serial.begin(115200);
  delay(2000);
  Serial.printf("\n");

  //create a task that will be executed in the Task0code() function, with priority 1 and executed on core 0
  xTaskCreatePinnedToCore(
    Task0code,   /* Task function. */
    "Task0",     /* name of task. */
    10000,       /* Stack size of task */
    NULL,        /* parameter of the task */
    1,           /* priority of the task */
    &Task0,      /* Task handle to keep track of created task */
    0);          /* pin task to core 0 */
  delay(500);

  //create a task that will be executed in the Task1code() function, with priority 1 and executed on core 1
  xTaskCreatePinnedToCore(
    Task1code,   /* Task function. */
    "Task1",     /* name of task. */
    10000,       /* Stack size of task */
    NULL,        /* parameter of the task */
    1,           /* priority of the task */
    &Task1,      /* Task handle to keep track of created task */
    1);          /* pin task to core 1 */
  delay(500);
}

//Task0code
void Task0code( void * pvParameters ) {
  Serial.printf("Task0 running on core : %d\n", xPortGetCoreID());

  for (;;) {
    intVar++;
    delay(1000);
  }
}

//Task1code
void Task1code( void * pvParameters ) {
  Serial.printf("Task1 running on core : %d\n", xPortGetCoreID());

  for (;;) {
    Serial.printf ("intVar = %d\n", intVar);
    delay(1000);
  }
}

void loop() {}