très bonne illustration
on voit que le code ASCII de 'a' est envoyé (0x61) suivi de CR et LF puisque vous avez utilisé println()
très bonne illustration
on voit que le code ASCII de 'a' est envoyé (0x61) suivi de CR et LF puisque vous avez utilisé println()
Yes !
Du coup ça répond à mon hypothèse (post #18) que l'affichage dans le moniteur série n'est pas synchrone avec ce qui est transmit par Tx. Ou je n'ai pas compris ?
l'affichage est "synchrone" avec la réception octet par octet de l'application qui écoute le port série (le terminal par exemple affiche les octets quand ils deviennent dispos) mais le code qui a fait le print() lui est déjà beaucoup plus loin dans son exécution sauf si vous avez rajouté un Serial.flush(); après le print(). flush() est une méthode bloquante qui va attendre que le buffer de sortie soit vide avant de continuer
Ok, merci encore.
Faut-il que j'ouvre une autre filière pour continuer sur les questions UART entre deux ESP32 ?
Comment avoir l'information sur la disponibilité des données sur Tx sur un ESP32, et leur bonne réception par le deuxième ESP32 ?
non on peut discuter de cela ici
Comment avoir l'information sur la disponibilité des données sur Tx sur un ESP32
en gros le premier ESP fait Serial1.println("coucou"); et le second utilise le code de mon petit tuto sur le port série pour lire une instruction jusqu'au séparateur qui ici serait le CR LF du println
si vous voulez garantir la réception, il faut bâtir un protocole un peu plus complexe (moyen de vérifier que le message est intègre) et avec renvoi d'un message qui dit "bien reçu"
Mais pour faire juste de l'affichage, je ne pense pas que ce soit nécessaire. éventuellement si l'ESP en réception ne reçoit rien pendant un moment il pourrait mettre une PIN à HIGH et cette pin serait écoutée par l'autre arduino qui comprendrait qu'il y a un souci
C'est la fonction available qui te l'indique.
Pourquoi as tu besoin d'être sûre de la bonne réception, que compte tu faire si ce n'est pas le cas?
Normalement si le deuxième ESP32 ne le reçoit pas, c'est que ton programme as un soucis.
Merci pour available, je vais voir ça.
Effectivement, je te suis, aucun besoin d'attester de la bonne réception par le deuxième ESP32 puisque c'est l'affichage lui-même qui témoignera de la qualité du fonctionnement. Logique, merci.
Merci J-M-L, je me suis bien inspiré de votre tuto (trapu le tuto) sur le port série pour faire quelque chose qui se tient.
Une autre option pour envoyer des valeurs byte d’un ESP32 à un autre :
La broche 25 (ou 26) du premier est reliée à une broche y du deuxième.
Sur le premier : pinMode(25,OUTPUT); dacWrite(25, valeur);
Sur le deuxième : pinMode(y, INPUT) ; analogRead(y);
L’erreur est de l’ordre de 1% avec des CAN calibrés. Le tout dure 120 µs.
Juste une remarque, pour rebondir sur quelque chose dit par @J-M-L au début : "pourquoi pas un unique ESP32 ?". L'ESP32 a 2 cœurs, donc il peut être réellement multitâche non concurrent.
Pas forcément facile à mettre en œuvre, avec RTOS, et peut-être pas assez rapide ? A évaluer...
J'ai essayé d'utiliser les deux cœurs avec l'espoir de créer des tâches parallèles et indépendantes. J'ai trouvé quelques modèles qui montrent la voie.
Et bien raté.
Chacun des deux doit laisser suffisamment de temps à l'autre, si non reboot.
Pourtant l'explication de J-M-L sur le déroulement de la communication par Serial.print() montre que cette tâche s'effectue sans gêner les autres...
la communication série est gérée par du hardware dédié qui tourne en parallele des 2 coeurs. Un coeur est sollicité une fois de temps en temps pour remettre un octet dans le buffer d'émission ou de réception mais c'est très court comme interruption
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.