Merci de ton retour,
Je vois dans ton code de nombreux commentaires '//La PAC lis depuis le module WiFi "
tu as laissé le module wifi de branché en // ?
En disant module ou passerelle WiFi, je veux parler de l’adresse 02, donc celle à laquelle l’ESP répond, équivalent du module WiFi d’origine, je ne l’ai pas laissé branché (Il vaut mieux éviter car lorsque le contrôleur va interroger l’adresse 2, l’ESP et le module WiFi vont répondre en même temps sur le même bus ce qui va causer beaucoup d’erreurs CRC, les trames ne seront pas reconnues ce qui va causer des erreurs de trame trop longue).
J’ai augmenter la taille du RingBuf et c’est bcp mieux…
J’avais baissé la taille du buffer msg, sûrement trop, mais cela veut dire que les trames sont formées légèrement différemment car par exemple, lorsque le contrôleur envoi la requête de lecture de la trame d’heure de l’IHM :
(D p:^0415ms) (recv_msg) Entete: Lecture depuis IHM
(I p:^0005ms) (recv_msg) Message complet recu de taille 8 : 01 03 0B B9 00 1E 16 03
(D p:^0015ms) (recv_msg) Entete: Lecture depuis IHM
(E p:^0007ms) (recv_msg) Trame trop longue, reinitialisation !
Il lui demande 001E mots de data, donc 60 octets.
On ajoute l’entête de la réponse de 3 octets (01 03 3C) et les 2 octets de CRC, on devrait avoir en réponse une trame de 65 octets, on devrait pas atteindre la limite du buffer msg de 266 octets.
Pareil pour le broadcast 07D1 :
(D p:^0205ms) (recv_msg) Entete: Diffusion broadcast
(E p:^0007ms) (recv_msg) Trame trop longue, reinitialisation !
(D p:^0196ms) (recv_msg) Entete: Diffusion broadcast
(I p:^0007ms) (recv_msg) Message complet recu de taille 8 : 00 10 07 D1 00 5A 10 AE
Via la réponse de l’IHM au broadcast, on voit que la taille est de 005A mots: 180 octets de data, + 9 octets entête et CRC c’est normalement OK.
Je serais intéressé de voir les trames que tu as après avoir augmenté la taille du buffer ?