Lorsque j'essaye d'ajouter le code de demo pour recevoir un signal (RC Switch), j'obtiens une erreur de type Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Le code de base qui permet capturer une photo et l'envoyer via blynk est fonctionnelle. C'est simplement lorsque j'avoue cette partie de code que cela plante et fait rebooter l'esp32 en boucle :
Serial.print("Ready to receive.");
mySwitch.enableReceive(digitalPinToInterrupt(15));
delay(1000);
PC: 0x401584a3: esp_intr_get_cpu at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/intr_alloc.c line 780
EXCVADDR: 0x00000000
Decoding stack results
0x401584a3: esp_intr_get_cpu at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/intr_alloc.c line 780
0x401362bc: gpio_isr_handler_add at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/driver/gpio.c line 389
0x40138020: camera_init at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/components/esp32-camera/driver/camera.c line 1205
0x4013819f: esp_camera_init at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/components/esp32-camera/driver/camera.c line 1268
0x400d2482: setup() at /Users/admin/Downloads/Code_Security_Camera_ESP32CAM_Blynk_02/Code_Security_Camera_ESP32CAM_Blynk_02.ino line 115
0x400d585b: loopTask(void*) at /Users/admin/Library/Arduino15/packages/esp32/hardware/esp32/1.0.4/cores/esp32/main.cpp line 14
0x4008bc19: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c line 143
-la gestion des interruptions sur un ESP32 est différente de celle des micros AVR,
Votre code fait planter l'ESP32 parce qu'il ne tient pas compte de ces particularités. Lancer un moteur de recherche avec 'ESP32 interruptions" pour découvrir la manière de gérer les interruptions externes sur un ESP32
-il n'est pas certain que la librairie RCSwitch soit compatible avec l'ESP32
-la gestion des interruptions sur un ESP32 est différente de celle des micros AVR, votre code fait planter l'ESP32 parce qu'il ne tient pas compte de ces particularités
Peux-tu m'aider à comprendre ce qu'il faudrait changer dans mon code pour que ca ne plante plus ?
il n'est pas certain que la libaririe RCSwitch soit compatible avec l'ESP32
Lorsque je test le code de demo de RC switch sur l'esp 32, tout fonctionne et je n'ai aucune erreur et tout fonctionne. Peux-t-on en déduire que l'interrupt fonctionne tel qu'il est écrit et que la librarie est compatible ?
le principe des interruptions externes avec un ESP32 est bien décrit sur ce site :
il y a même un exemple ou une interruption issue d'un capteur PIR déclenche une prise de vue sur une carte ESP32CAM
je ne connais pas la librairie RCswitch, à part son existence... et ne prévois pas de m'y intéresser vu que les télécommandes sur 433 MHz en OOK/ASK disparaissent de mon environnement domestique !
les deux lignes de cod eque tu montres ne suffsient pas à produire une interruption concenabel sure ESP32
il est impératif que la fonction appelée lors d'une interruption ("handler") possède l'attribut IRAM_ATTR comme dans le second exemple ci dessous où le détecteur PIR interrompt l'ESP32
void IRAM_ATTR detectsMovement() {.......
Est-ce le cas dans ton code (ou dans celui de la librairie utilisée) ? (le petit bout de code à éxécuter lors de l'interruption externe doit être implanté en RAM et non en mémoire flash comme le reste du code)
Ne connaissant pas RCSwitch je ne peut aider davantage, ne sachant pas ce qui s'y passe.
Sur un ESP32 on a deux coeurs. Le coeur des applications fonctionne comme un Arduino normal. Mais les routines d'interruption s'exécutent sur l'autre coeur. Les précautions qu'on prend ordinairement sur un mono-processeur lorsqu'on fait communiquer une routine d'interruption avec le reste de l'application sont insuffisantes. Il ne suffit pas de protéger les séquences critiques par des cli() et sei(), ni de définir en "volatile" les variables partagées. Il faut un autre mécanisme, plus puissant.
L'ESP32 fournit ce mécanisme : il s'agit des "mutex". Enfoui dans le hardware des sytèmes multi-processeurs il y a une instruction spéciale, connue sous le nom de "test and set" dans la théorie, qui consiste en fait à tester et mettre à "1" une variable booléenne en un seul cycle du bus mémoire, pour assurer l'exclusivité entre processeurs qui partagent ce bus. Le mutex doit utiliser un tel mécanisme pour assurer l'exclusivité sur des séquences critiques. Quand je dis "doit", c'est une supposition, car un système multi-processeurs ne peut pas fonctionner autrement, mais je n'ai pas trouvé ce détail dans la doc de l'ESP32.
L'inconvénient est qu'on est obligé d'avoir une programmation spéciale pour l'ESP32 des séquences critiques, avec par exemple des compilations conditionnelles.
Pourtant lorsque je test le code indépendemment tout fonctionne bien…