Messages

541

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 19, 2020, 08:46:16 pm »

Marcel, qu'est-ce que tu appelles "continuer manuellement" ?

542

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 19, 2020, 04:16:12 pm »

Pour ceux que ça intéresse, voici le moyen d’utiliser JMRI en Wifi. C’est la première brique que je propose pour cette centrale. (et dans l’attente de DCCpp sur ESP32)

Le procédé est très simple, JMRI communique en TCP (Ethernet) avec l’ESP32, les deux étant reliés à votre box.

Les commandes reçues de JMRI par l’ESP32 sont « routées » par le port « Serial2 » de l’ESP32 au port série (Pins TX et RX) de l’Arduino UNO (ou autre) qui supporte DCC++.

De la même manière, les informations envoyées par DCC++ sont « routées » en TCP à JMRI.

N’oubliez pas que le TX de l’un va dans le RX de l’autre et vice-versa.

Attention, le courant sur les pins de l’Arduino est en 5V et sur celles de de l’ESP en 3,3V. Vous devrez ajouter un convertisseur de tension comme sur la photo.

Chez moi, le serveur DHCP a donné l’IP 192.168.1.126 à l’ESP. Il vous faut entrer dans JMRI l’adresse IP attribuée à l’ESP32 dans votre propre configuration.

N’oubliez pas de mettre vos propres identifiants internet dans le fichier config.h

#define WIFI_SSID           "votre_ssid"
#define WIFI_PSWD           "votre_password"

A votre disposition si ces informations ne sont pas suffisantes pour l’installation.

Prochaine étape, je vais essayer de piloter à partir de WiThrottle avec les informations fournies par Dominique.

543

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 19, 2020, 06:01:11 am »

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.

544

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 18, 2020, 09:51:04 am »

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

545

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 18, 2020, 12:14:47 am »

La même chose que ce que j'ai posté précédemment mais avec des structures pour manipuler des variables complexes.

Code: [Sélectionner]

/*
   Documentation @ http://web.ist.utl.pt/~ist11993/FRTOS-API/group___queue_management.html#xQueueReceive
*/

TaskHandle_t vSenderTask;
TaskHandle_t vReceiverTask;

/* Declaration d'une variable xQueue de type QueueHandle_t qui servira a stocker la file. */
QueueHandle_t xQueue;
/* Taille de la file*/
const uint32_t queueSize = 1000; // Prevoir une taille suffisante pour ne pas perdre de messages
/* Taille maxi de la chaine de caractere */
#define maxCaractInQueue 25

struct Msg {
  uint32_t id;
  char str[maxCaractInQueue];
} msg;


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

  xQueue = xQueueCreate( queueSize, sizeof( struct Msg * ));
  if ( xQueue != NULL ) {

    xTaskCreatePinnedToCore(
      vSenderTaskCode,            /* Task function. */
      "vSenderTask",              /* name of task. */
      10000,                      /* Stack size of task */
      NULL,
      1,                          /* priority of the task */
      &vSenderTask,               /* Task handle to keep track of created task */
      0);                         /* pin task to core 0 */
    delay(500);

    xTaskCreatePinnedToCore(
      vReceiverTaskCode,          /* Task function. */
      "vReceiverTask",            /* name of task. */
      10000,                      /* Stack size of task */
      NULL,                       /* parameter of the task */
      2,                          /* priority of the task */
      &vReceiverTask,             /* Task handle to keep track of created task */
      1);                         /* pin task to core 1 */
    delay(500);
  }
  else
    Serial.printf("The queue could not be created.");
}


void vSenderTaskCode( void *parameter ) {
  struct Msg *ptTxMsg;
  BaseType_t xStatus;
  ptTxMsg = &msg;
  Serial.print("vSenderTask\n");
  for (int i = 0; i < 10000; i++) {
    ptTxMsg->id = i;
    sprintf(ptTxMsg->str, "Ligne %d", i);
    xStatus = xQueueSendToBack( xQueue, (void*) &ptTxMsg, 0 );
    if ( xStatus == pdPASS )
      Serial.printf("Send : %d\n", ptTxMsg->id);
    else
      Serial.printf( "Could not send to the queue.\n" );
  }
  vTaskDelete( NULL );
}

void vReceiverTaskCode( void *parameter ) {
  struct Msg *ptRxMsg;
  BaseType_t xStatus;
  const TickType_t xTicksToWait = pdMS_TO_TICKS( 100 );
  Serial.print("vReceiverTask\n");
  for ( ;; ) {
    if ( uxQueueMessagesWaiting( xQueue ) != 0 )
      Serial.printf( "Queue should have been empty!\n" );
    xStatus = xQueueReceive( xQueue, &(ptRxMsg), xTicksToWait );
    if ( xStatus == pdPASS )
      Serial.printf( "Received n° %d - value : %s\n", ptRxMsg->id, ptRxMsg->str );
    else
      Serial.printf( "Could not receive from the queue.\n" );
  }
}

void loop() {}

546

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 17, 2020, 07:01:11 pm »

Merci Pierre, l'exemple est en effet simple et parlant.

547

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 17, 2020, 05:04:21 pm »

J'ai complété le programme pour avoir une vraie file d'attente pour faire une messagerie qui échangerait les données d'une tâche à l'autre. Bien sûr, une tâche tourne sur le cœur 0 et l'autre sur le cœur 1 sinon ça n'a pas d'intérêt.

Ca m'intéresse d'avoir vos retours.

PS : Pierre, je viens juste de voir ta réponse et je ne l'ai pas analysée. Cependant, le ne suis pas certain qu'il y ait besoin de sémaphore dans ce cas car il n'y a pas de modifications de données entre les tâches, non ?

Code: [Sélectionner]

TaskHandle_t vSenderTask;
TaskHandle_t vReceiverTask;

/* Declaration d'une variable xQueue de type QueueHandle_t qui servira a stocker la file. */
QueueHandle_t xQueue;
/* Taille de la file*/
int queueSize = 1000;
/* Taille maxi de la chaine de caractere */
#define maxCaractInQueue 25


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

  xQueue = xQueueCreate( queueSize, maxCaractInQueue );
  if ( xQueue != NULL ) {

    xTaskCreatePinnedToCore(
      vSenderTaskCode,            /* Task function. */
      "vSenderTask",              /* name of task. */
      10000,                      /* Stack size of task */
      NULL,
      1,                          /* priority of the task */
      &vSenderTask,               /* Task handle to keep track of created task */
      0);                         /* pin task to core 0 */
    delay(500);

    xTaskCreatePinnedToCore(
      vReceiverTaskCode,          /* Task function. */
      "vReceiverTask",            /* name of task. */
      10000,                      /* Stack size of task */
      NULL,                       /* parameter of the task */
      2,                          /* priority of the task */
      &vReceiverTask,             /* Task handle to keep track of created task */
      1);                         /* pin task to core 1 */
    delay(500);
  }
  else
    /* The queue could not be created. */
    Serial.printf("The queue could not be created.");
}



void vSenderTaskCode( void *parameter ) {
  BaseType_t xStatus;
  /* Variable qui va contenir la valeur a envoyer*/
  char strTx[maxCaractInQueue];
  Serial.print("vSenderTask\n");
  for (int i = 0; i < queueSize; i++) {
    sprintf(strTx, "Ligne %d", i);
    xStatus = xQueueSendToBack( xQueue, (char*) strTx, 0 );
    if ( xStatus != pdPASS )
      Serial.printf( "Could not send to the queue.\r\n" );
    else
      Serial.printf("Send : %s\n", strTx);
  }
  vTaskDelete( NULL );
}

void vReceiverTaskCode( void *parameter ) {
  BaseType_t xStatus;
  /* Variable qui va contenir la valeur recue*/
  char strRx[maxCaractInQueue];
  const TickType_t xTicksToWait = pdMS_TO_TICKS( 100 );
  Serial.print("vReceiverTask\n");
  for ( ;; ) {
    if ( uxQueueMessagesWaiting( xQueue ) != 0 )
      Serial.printf( "Queue should have been empty!\n" );

    xStatus = xQueueReceive( xQueue, &strRx, xTicksToWait );
    if ( xStatus == pdPASS )
      /* Data was successfully received from the queue, print out the received
        value. */
      Serial.printf( "Received : %s\n", &strRx );
    else
      Serial.printf( "Could not receive from the queue.\r\n" );
  }
}

void loop() {}

548

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 17, 2020, 10:10:35 am »

L'exemple est sympa et parlant. La difficulté de la gestion multi-tâche réside essentiellement par les synchronisations qu'il faut généralement mettre en place pour éviter les conflits d’accès et/ou d'écriture sur les mêmes données. Les langages C et C++ prévoient des mécanismes type mutex, sémaphore ou lock pour justement contourner ces problèmes. Je ne sais pas ce qui est vraiment disponible pour l'ESP32, et en particulier si c'est utilisable avec un Arduino IDE...

L’API de FreeRTOS est vraiment très complète pour gérer en particulier les queues, les semaphores et les mutexes.

Je pense que l’on doit pouvoir arriver à des choses fiables sur un ESP32 en multi-tâches. Pour l’instant, je m’intéresse au passage de données d’une tâche à une autre (qui était l’exemple pris par Cédric) dans le cas d’une messagerie avec gestion de la communication web sur une tâche et traitement des données sur une autre par exemple.

Les différents paramètres du message seraient stockés dans une structure (date, ID, contenu, …) qui elle-même serait passée en paramètre entre les tâches.

Il m’intéresserait d’appliquer cela à ma passerelle CAN/WiFi car c’est exactement la problématique.

549

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 16, 2020, 09:44:31 pm »

Bonjour Christophe,

Je pense que sur une donnée partagée de type int, ton code ne risque rien. Par contre, si on s'amuse à modifier un objet sur un coeur et de manipuler l'objet par l'autre coeur, je crois qua ça se passera mal tôt ou tard.
A+

Je suis bien conscient des limites et je l'ai bien précisé. Cependant, en y regardant de plus près, il me semble que ce petit exemple est réaliste dans un système de messagerie par exemple. Il n’y a en effet de modification de données que dans une seule deux tâches.

C’est je crois le cas que tu évoquais précédemment avec le traitement web dans une tâche et le reste dans une autre tâche.

Mais comme il n’y a pas de gestion de file, la valeur de la variable peut avoir été modifié dans la tâche 1 avant même que la tâche 2 n’ai pu la traiter. C'est une autre limite.

Ce petit exemple voulait également répondre à quelqu’un qui disait que ça semblait compliqué. En fait pas du tout et il y a dans ce que je montre tout pour faire fonctionner une tâche sur le core 0 et un autre sur le core 1  permettant ainsi d’accroitre les performances.

Le seul vrai problème se pose comme tu le précises bien lorsque les deux tâches travaillent sur les mêmes objets en modification.

Je trouve en tous cas ceci amusant !

550

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 16, 2020, 05:34:26 pm »

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() {}


551

Vos projets / Re : Re : projet centrale wifi DCC++ Can

« le: mars 15, 2020, 01:11:36 pm »

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

552

Bus DCC / Re : Passerelle CAN/WiFi-TCP/Serial

« le: février 22, 2020, 07:11:28 pm »

En réalité, la carte SN65HVD230 ne fait pas le même boulot qu'une carte NiRen par exemple mais il y a sur l'ESP32 une partie du CAN donc la carte SN65HVD230 est complémentaire et simplifiée.

553

Vie du forum / Re : Voeux 2020

« le: janvier 01, 2020, 11:53:03 am »

Bonne année à tous et longue vie à Locoduino !

Christophe

554

Bus DCC / Re : Passerelle CAN/WiFi-TCP/Serial

« le: novembre 08, 2019, 05:15:33 pm »

Soyons bien clair, je n'oppose pas une technologie à une autre, en l'occurence le CAN et le WiFI. Bien au contraire. Ce que je présente ici est une passerelle entre les deux types de réseaux. Pour que ce qui fonctionne en CAN reste en CAN et pour que ce qui fonctionne en TCP (et bien souvent ne peut fonctionner qu'en TCP) puisse aussi communiquer avec un bus CAN.

Dans ce que je présente, la latence est un non problème puisque les ports TCP une fois ouverts le restent constamment ! Ce qui influence donc la latence comme la vérification du message ou la performance du réseau n'est pas moins performant qu'en CAN (peut être meilleur même).

CQFD.

555

Bus DCC / Re : Passerelle CAN/WiFi-TCP/Serial

« le: novembre 07, 2019, 10:04:49 pm »

B'hein faut mettre les ESP32 là où la WiFi marche bien, non ? Quelle idée de faire des dioramas qui représentent la Creuse ou la Lozère !

Bon c'est à peine une boutade. Le bus CAN faisant tout le tour du réseau, la ou les passerelles peuvent être placées là où la réception est la meilleure. Mais tout ceci fonctionne aussi avec des cartes Ethernet sur Arduino (filaire donc).

Tout ce que je peux dire, c'est que j'ai fait des tests avec des échanges d'informations un peu fournis et une base de données en TCP et je n'ai pas perdu me messages.