Digression sur le code UxIx3 et les reboot / ENFIN PLUS DE PLANTAGE

[PhDV61]

J'ai de nouveau analysé le code UxIx3, qui pose problème depuis l'adoption de la bibliothèque "cartes" V3.01 et suivantes au lieu de feu la V2.17 qui marchait parfaitement.

Le problème tourne en partie autour du WIFI (mais pas uniquement je pense) et semble avoir été résolu pour ceux qui ont peu d'ESP32, ou n'utilisent pas le module UxIx3 (tri-phasé).

Le code UxIx3 tel qu'il est écrit actuellement consomme inutilement des ressources, et il n'est pas impossible qu'il y ait depuis la V3.01 des interactions entre les deux cores, possiblement avec les "mutex hardware" ou autres.

Actuellement, le code UxIx3 envoie une requête de données au module JSY-MK-333, puis lit la réponse caractère par caractère jusqu'à les avoir tous lus. C'est une perte de temps inutile, car, en supposant que le module réponde 'dans l'instant', cela prend au minimum  141 données x 10 bits / 9600 = 150 ms.

J'ai donc simplement "dissocié" la requête de la lecture, pour être sûr que lorsque le core viendra lire la réponse, tout le message sera déjà dans le buffer et sera donc lu "à grande vitesse". J'aurais pu aussi venir vérifier si toutes les données avaient été reçues, avec un timeout, avant de les lire toutes, mais sans bloquer.

Le code actuel marche simplement parce que le serial.read() est en partie "bloquant", c'est à dire qu'il attend avec un timeout, dont j'ai lu qu'il était par défaut de 1 seconde. C'est curieux quand on veut faire du temps réel d'avoir des read avec timeout. Mais c'est comme çà.

Pour résoudre le problème, j'ai simplement sorti la requête elle-même de la "lecture", et lancé une première requête à la fin de l'init du port série (voir plus loin).

Et j'ai modifié le code principal en lisant, puis en relançant une requête, sachant que je ne viendrai lire la réponse que 800ms plus tard (lors de l'extinction du timer), donc en étant sûr qu'elle sera dans le buffer de réception dans son intégralité.

if (Source == "UxIx3") {
          Lecture_JSY333();
          PeriodeProgMillis = 800;
          Request_data_JSY333();
        }

Sans doute parce que dans le code V3.0x il y a de nouvelles inter-actions 'parasites' entre le temps réel des deux cores, le simple fait d'utiliser moins longtemps l'UART libère de la ressource qui améliore grandement les choses (pour le WIFI ?? j'en doute).

Très curieux, mais c'est comme ça. Donc je prends puique ainsi cela tombe en marche.

La prochaine étape sera pour moi de passer la comm série à 19200 comme cela a été si bien fait par un autre d'entre nous, pour gagner un facteur 2 sur la vitesse de transmission et réduire encore le temps de lecture et d'occupation de l'UART. Et je testerai en continu le buffer de réception pour ne pas en retarder la lecture comme je le fais actuellement ( comme c'est très bien fait pour le Linky).

En tout cas, je n'ai plus de plantage de mon serveur UxIx3, ce qui est déjà très bien.


// *************************************************
// * Client lecture JSY-MK-333 * Triphasé          *
// * Développement initial de Pierre F (Mars 2024) *
// * update PhDV61 Juin 2024 et Août 2024          *
// *************************************************

void Setup_JSY333() {
  MySerial.setRxBufferSize(SER_BUF_SIZE);
  MySerial.begin(9600, SERIAL_8N1, RXD2, TXD2);  //PORT DE CONNEXION AVEC LE CAPTEUR JSY-MK-333
  delay(10);
  Request_data_JSY333();
}

void Request_data_JSY333() {
int i;
  byte msg_send[] = { 0x01, 0x03, 0x01, 0x00, 0x00, 0x44, 0x44, 0x05 };
  for (i = 0; i < 8; i++) {
    MySerial.write(msg_send[i]);
  }
}  

void Lecture_JSY333() {

  float Tension_M1, Tension_M2, Tension_M3;
  float Intensite_M1, Intensite_M2, Intensite_M3;
  float PVA_M_inst1, PVA_M_inst2, PVA_M_inst3;
  float PW_inst1, PW_inst2, PW_inst3;
  byte Lecture333[200];
  bool injection;
  bool sens1, sens2, sens3;
  long delta_temps = 0;
  int a = 0;

  while (MySerial.available()) {
    Lecture333[a] = MySerial.read();
    a++;
  }
...

Voilà.

Edit : je viens de lire que les tâches WIFI tournaient par défaut (arrrrghhh) sur ... le core 0. Ceci expliquant peut-être cela...