Structures "croisées" entre 2 ESP32

International Français
1

Bonsoir à tous,
je bute ce soir sur un comportement étrange dans une liaison entre 2 ESP32 par Serial en utilisant des structures.
j'ai besoin d'échanger en bidirectionnel.
J'ai d'abord écrit 2 codes tests dont le séquencement est bêtement traité par des delay.
Là n'est pas le problème., il se situe sur l'interprétation fausse d'un côté :
Premier ESP que j'appellerai "Ventil" :

#define RXD2 16       // pin RX2
#define TXD2 17       // pin TX2

float tct;
float tch;
float Tex;
bool ecs;
int state;
bool hiver;
int cons;
float tec;
int fum;
int all;
float cch;

struct Chaudiere
{float tct; float tch; float Tex; boolean ecs; uint16_t state; boolean hiver; uint16_t cons;
 float tec; uint16_t fum; uint16_t all; float cch;}__attribute__((packed));;
 bool nouvellesDonnes = false;
 Chaudiere recept;

struct Ventil
{bool aero; bool soir; bool relance;}__attribute__((packed));;
Ventil envoi;


void setup() {
 Serial.begin(115200);
 Serial2.begin(1200, SERIAL_8N1, RXD2, TXD2);

 envoi.aero = 1;
 envoi.soir = 1;
 envoi.relance = 0;  }

void loop() {

  if (Serial2.available())
    { Serial2.readBytes((byte*)&recept, sizeof recept);
      nouvellesDonnes = true; }

  if (nouvellesDonnes)
  { tct = recept.tct;
    tch = recept.tch;
    Tex = recept.Tex;
    ecs = recept.ecs;
    state = recept.state;
    hiver = recept.hiver;
    cons = recept.cons;
    tec = recept.tec;
    fum = recept.fum;
    all = recept.all;
    cch = recept.cch;

    envoi.aero;
    envoi.soir;
    envoi.relance;

    Serial2.write((byte *)&envoi, sizeof envoi);

    nouvellesDonnes = false; }
    Serial.println(tct); 
    
    delay(2000);
    
}

Second ESP qu'on appellera Chaudiere :

#define RXD2 16       // pin RX2
#define TXD2 17       // pin TX2

bool aero;
bool soir;
bool relance;

struct Chaudiere
{float TempCirc; float TempChaud; float TempExt; boolean NeedEcs;
uint16_t etat; boolean hiver; uint16_t cumulPellets; float TempEcs; uint16_t tempFum;
uint16_t dureeAll; float ConsChaud;}__attribute__((packed));;
Chaudiere envoi;

struct Ventil
{bool aero; bool soir; bool relance;}__attribute__((packed));;
bool nouvellesDonnes = false;
Ventil recept;

void setup() {
 Serial.begin(115200);
 Serial2.begin(1200, SERIAL_8N1, RXD2, TXD2);

  envoi.TempCirc = 40.0;
  envoi.TempChaud = 70.0;
  envoi.TempExt = 12.1;
  envoi.NeedEcs = false;
  envoi.etat = 0;
  envoi.hiver = true;
  envoi.cumulPellets = 0;
  envoi.TempEcs = 60.0;
  envoi.tempFum = 90;
  envoi.dureeAll = 120;
  envoi.ConsChaud = 65;

}

void loop() {

   if (Serial2.available())
    { Serial2.readBytes((byte*)&recept, sizeof recept);
      nouvellesDonnes = true; }

    if (nouvellesDonnes)
     {aero = recept.aero;
      soir = recept.aero;
      relance = recept.aero;
      nouvellesDonnes = false;
      Serial.print(aero); Serial.print("\t"); Serial.print(soir); Serial.print("\t"); Serial.println(relance);}
 
      envoi.TempCirc;
      envoi.TempChaud;
      envoi.TempExt;
      envoi.NeedEcs;
      envoi.etat;
      envoi.hiver;
      envoi.cumulPellets;
      envoi.TempEcs;
      envoi.tempFum;
      envoi.dureeAll;
      envoi.ConsChaud; 
      
      Serial2.write((byte *)&envoi, sizeof envoi);
     
    delay(2000);
        
 }

Chaudiere envoie un mix de format vers Ventil. Tout se passe bien, même si pour faire court je n'ai affiché que la première variable.
Ventil envoie 3 booléens vers Chaudière. Pour vérifier la transmission j'ai monté les 2 premiers en true et le troisième en false.
Voici ce que Chaudière reçoit (extrait du moniteur série :

1	1	1
1	1	1
1	1	1
1	1	1
1	1	1
1	1	1
1	1	1
1	1	1
1	1	1
1	1	1
1	1	1
1	1	1
1	1	1
1	1	1

alors que j'attends 1 1 0 .

D'où peut provenir le souci ?

2

Avez vous bien lié les GNDs des 2 cartes ?

pouvez vous rajouter un delay de 5000 juste après la config des ports séries et avant de commencer à balancer des bits histoire de vous laisser le temps de rebooter les 2 ESP32 ? avez vous le même comportement ?

A titre de curiosité, que se passe-t-il si vous mettez 115200 bauds au lieu de 1200 (qui est super lent) pour la communication croisée ? avez vous le même comportement ?

➜ faire une communication binaire sur une liaison asynchrone avec gestion des timeout (lecture bloquante) et des délais est dangereux car vous ne maitrisez pas ce qu'il se passe.

Pour bien écouter ub nport série (ou gérer un flux asynchrone de manière générale) vous pouvez jeter un oeil à mon petit tuto sur le sujet. On lit au plus vite sans bloquer la loop and quand on a reçu toute une trame on effectue le traitement. Si vous pouvez aussi envoyer un marqueur de début ou fin de trame cela aide à la synchro entre les 2 appareils.

3

Merci pour ces pistes.

pouvez vous rajouter un delay de 5000 juste après la config des ports séries

c'est pire : l'ESP Ventil affiche la valeur d'une autre variable.

A titre de curiosité, que se passe-t-il si vous mettez 115200 bauds au lieu de 1200 (qui est super lent) pour la communication croisée ? avez vous le même comportement ?

pas de changement par rapport à la situation intiale (OK côté ESP Ventil). L'installation tourne depuis plus de 5 ans avec une distance de 5m. Par précaution j'ai utilisé 2 adaptateurs TTL- RS232 et choisi une vitesse faible.
La raison de mes modifications est rendre plus propre les échanges, tous basés sur des String. C'est pour cela que je suis en train de tester la solution "struct".
En unidirectionnel ça fonctionne parfaitement.

Pour bien écouter un port série (ou gérer un flux asynchrone de manière générale) vous pouvez jeter un oeil à mon petit tuto sur le sujet.

Je remarque que votre tuto est basé sur la classe String, ce que je veux à présent éviter car l'installation est en fait un Mega en chaudière et un ESP en Ventil, et elle souffre de fragmentation de RAM avec des plantages tous 15 - 20 jours...
La solution structure m'avait paru idéale dans ce sens.

4

ça démontre que votre code n'est pas robuste et qu'il est dépendant du timing (traitement synchrone d'une communication asynchrone)

absolument pas... Je n'utilise pas cette classe (et sur MEGA, si vous utilisez correctement la classe String vous ne devriez pas avoir de fragmentation).

Le principal souci dans une communication binaire est de synchroniser les débuts de message - éventuellement ajouter un CRC dans la structure pour valider que le buffer est bien reçu où mettez en début de structure un code sur quelques octets 0xDEADBEEF par exemple qui est peu probable d'être contenu dans le message binaire et servez vous en pour synchroniser les échanges

5

En plus de ce qu'a indiqué @J-M-L, tu peux en début de ta structure avoir la taille de celle-ci.
Comme tu utilises des plateformes différentes, il faudrait aussi forcer l'alignement des propriétés de la structure sur un octet.

6

il a deux ESP32

donc le risque est moindre mais un alignement sur 1 octet en plus de packed ne gâcherait rien effectivement

(j'ai testé la taille des structures de son code et elles sont bien identiques des 2 côtés)

7

Autant pour moi je pensais que Mega, faisait référence a une carte de la marque Arduino.

8

ah j'avais raté ça

effectivement ça laisse planer le doute alors et

struct __attribute__((packed, aligned(1))) Chaudiere {
  float tct; 
  float tch; 
  float Tex; 
  boolean ecs; 
  uint16_t state; 
  boolean hiver; 
  uint16_t cons;
  float tec; 
  uint16_t fum; 
  uint16_t all; 
  float cch;
};
 
struct __attribute__((packed, aligned(1))) Ventil {
  bool aero; 
  bool soir; 
  bool relance;}
};

serait pertinent en effet

il y a aussi l'adaptation de tension ( vérifier comment est géré le TTL- RS232)

9

Après si j'ai bien interprété sur sa platforme de test actuel, @jackjean utilise deux ESP32.
c'est sa plateforme de déploiement qui est différents ?

10

on va attendre confirmation

11

ca fait plaisir de se sentir moins seul, même si on se sent encore plus ignorant :slight_smile:

Je vais donc éclaircir :
L'installation (chauffage) actuelle tourne avec un Arduino Mega 2560 (code "chaudière") connecté à 5m à un ESP32 via 2 adaptateurs TTL - RS232 (code "ventil").
Je n'ai pas de souci de données erronées ou manquantes avec de simples Serial.print / readStringUntil. Peut-être quelques irrégularités dans la cadence, mais en chauffage les événements peuvent être traités avec qq secondes de retard... Par contre l'ESP32 actuel crashe tous les 15 - 20 jours (malgré dans taille de RAM "confortable"...
Je prépare actuellement le remplacement du coffret "ventil", toujours en ESP32 et TTL RS232 et profite pour coder plus proprement.
La future platine du coffret est prête et c'est sur elle que je code "ventil". A ses côtés j'ai une breadboard portant un autre ESP que j'appellelrais "fausse chaudière". En breadboard c'est plus pratique qu'un Mega et les niveaux sont identiques. Je n'utilise donc pas les TTL_RS232 dans ce test. La liaison série fait 50cm...

12

est-ce un adapteur RS232 vers TTL avec niveau logique 3,3V et 5V supportés?

avez vous regardé où ça crash?

OK clair pour le ban de test - ce sont 2 ESP32 connectés directement Rx, Tx (et GND j'imagine)

13

ce qui est bien, c'est que c'est l'état nécessaire pour moins ignorant, car dans ce domaine, il y a très peu de sachant :rofl:

14

est-ce un adapteur RS232 vers TTL avec niveau logique 3,3V et 5V supportés?

Oui puisqu'ils fonctionnent depuis 5 ans ainsi et n'entrent pas dans la réflexion car n'étant pas utilisés dans mes tests.

avez vous regardé où ça crash?

Non, je ne sais pas (encore) faire. Je peux juste dire qu'un simple soft reset par ESP.restart() tous les soirs (équivalent à un appui bouton ) ne changent rien à la durée entre crashes.
J'ai compris que la RAM de l'ESP32 ne se vide pas sans coupure d'alimentation.

15

Je confirme

16

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.