Bonjour à tous, j'ai un problème avec ma carte LilyGO TTGO oled lora32.
Ref de la carte: T3 V1.6.1
Pinout:
Ma carte redémarre constamment. Je pense que c'est un problème de bibliothèque mais je n'arrive pas à trouver ?
Je dis ça car le code fonctionnait très bien jusqu'à ce que je change d'ordinateur et que je reprenne le code.
J'ai téléchargé le code suivant et cela fonctionne très bien. Je n'ai pas de redémarrage avec ce code:
//words preceded by "//"" are comments and are not executed
bool ticktock; //declare ticktock as a boolean flag
void setup() { //runs once on start up
Serial.begin(115200); //open the serial port for USB cable
delay(500);
}
void loop() { //runs in circles!
ticktock = !ticktock; //every pass through reverse the flag
if (ticktock) { //test current value of the ticktock flag
Serial.println("tick");
} else { //prints one or the other to the USB port
Serial.println("tock");
}
delay(1000); //wait for a second and run again!
}
Oui j'ai bien choisi la bonne carte et elle est à jour. Je pense que mon problème se situe au niveau de la librairie de l'afficheur OLED car dès que j'enlève tout ce qui concerne l'affichage, je n'ai plus de reboot.
Du coup je creuse encore. Ha oui effectivement peut-être que c'est le fait de faire tourner trop de tâche en même temps... Je te tiens au courant ! Merci.
Il n'y a que toi qui sait ce qu'il y a sur ta carte et si tu as bien chargé une librairie compatible.
Pendant le téléchargement, le PC dialogue avec la carte.
Est-ce que tu as un message d'erreur dans la console de l'IDE indiquant que le téléchargement a échoué?
Oui effectivement j'ai ça en erreur au début du téléversement:
c:\Users\LABAT\OneDrive\Documents\Arduino\libraries\LoRa\src\LoRa.cpp: In member function 'long int LoRaClass::packetFrequencyError()':
c:\Users\LABAT\OneDrive\Documents\Arduino\libraries\LoRa\src\LoRa.cpp:277:71: warning: 'B111' is deprecated: use 0b111 instead [-Wdeprecated-declarations]
277 | freqError = static_cast<int32_t>(readRegister(REG_FREQ_ERROR_MSB) & B111);
| ^~~~
In file included from C:\Users\LABAT\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\cores\esp32/Arduino.h:41,
from c:\Users\LABAT\OneDrive\Documents\Arduino\libraries\LoRa\src/LoRa.h:7,
from c:\Users\LABAT\OneDrive\Documents\Arduino\libraries\LoRa\src\LoRa.cpp:4:
C:\Users\LABAT\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\cores\esp32/binary.h:86:3: note: declared here
86 | B111 DEPRECATED(0b111) = 7,
| ^~~~
c:\Users\LABAT\OneDrive\Documents\Arduino\libraries\LoRa\src\LoRa.cpp:283:42: warning: 'B1000' is deprecated: use 0b1000 instead [-Wdeprecated-declarations]
283 | if (readRegister(REG_FREQ_ERROR_MSB) & B1000) { // Sign bit is on
| ^~~~~
C:\Users\LABAT\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\cores\esp32/binary.h:92:3: note: declared here
92 | B1000 DEPRECATED(0b1000) = 8,
| ^~~~~
Je ne suis pas expert, mais j'ai un projet en cours qui utilise une bibliothèque LoRa. J'avais un problème de reboot intempestif et j’ai finit par trouver la source avec la bibliothèque que j’utilise : Il semble que lorsque qu’un message arrive, il déclenche une interruption qui appelle la callback déclarée préalablement.
Si l’exécution de la callback est trop longue, le watch dog se plein et reboot la plaque.
Dans ma callback, je me contente donc de mettre a true une variable, puis, dans la loop, je lis cette variable pour savoir si j’ai un message et je fais sa lecture.
Les sorties sur Serial son particulièrement lentes.
C’est un peu plus compliqué que cela parce qu’un un appel à print ou write sur Serial est généralement hyper rapide puisque cela ne consiste qu’à copier ce qu’il faut imprimer dans un buffer mémoire qui ensuite est émis de manière asynchrone et donc ça n’empêche généralement pas votre code d’avancer et c’est rapide.
Là où ça se complique c’est que si le buffer de sortie est plein alors la fonction print() bloque jusqu’à ce qu’il y ait de la place, ce qui veut dire qu’il faut que suffisamment d’octets présents dans le buffer aient été émis.
Hors l’UART fait son job d’émission asynchrone par le biais d’interruptions. Donc si vous faites un print dans un contexte déjà d’interruption ou potentiellement les nouvelles interruptions sont bloquées l’UART une fois qu’elle aura émis un octet en tâche de fond va lever une interruption qui ne sera pas vue puisque le code principal est bloqué dans ce contexte où les interruptions sont désactivées…. On est alors coincé là.
Arduino s’est rendu compte que c’était un bug fréquent des débutants et donc a modifié la procédure d’émission dans le cas où les interruptions sont désactivées pour émettre plus d’octets de manière synchrone tant que le buffer n’est pas suffisamment vidé (sans utiliser les interruptions donc, par attente active sur les registres d’états de l’UART).
C’est dans ce cas que l’impression devient lente puisque synchronisée sur le débit en bauds retenu.
C’est pour cela que l’on recommande très fortement de ne pas utiliser l’impression dans un contexte d’interruption.
Concernant le traitement d’une interruption qui dit qu’un message LoRa est dispo, il faut copier le message (le sortir du buffer LoRa) dans le code du callback parce qu’on n’est pas sûr qu’une fois revenu à la loop le module Lora ne sera pas encore en train de recevoir un autre message et d’utiliser son buffer. Il faut considérer que l’accès à ce buffer n’est valide que dans le contexte de l’interruption. Donc on le copie et on met un drapeau (une variable booléenne volatile ou mieux en utilisant un mutex/sémaphore) pour effectivement traiter le message plus tard dans la loop.
Dans un environnement où le traitement des messages peut être long par rapport à des salves de messages il faut que l’interruption rajoute le message dans une queue qui sera dépilée par la loop car on pourrait avoir plusieurs messages qui arrivent pendant qu’on en traite un. Il ne faut pas dans ce cas que la procédure d’interruption vienne modifier le buffer du message sur lequel votre code principal bosse…
Bref - attention à tout ce qui est parallélisme et contextes partagés
