Ciao a tutti.
Sto usando ide arduino e scheda wemos lolin32 lite.
per farla breve: ho una funzione da fare solo la prima volta che si ha resettato o riacceso la scheda. Poi il loop() infinito di dormi/sveglia con il deep sleep, senza piu' rifare quella funzione.
bene , dichiaro , all'inizio del codice dopo gli include delle varie librerie questa variabile: RTC_DATA_ATTR bool firstTime = true;
poi nel setup() testo la variabile , se true , metto la variabile a false e eseguo la funzione.
mi aspetterei che non venga piu' eseguita.
D'altra parte , in precedenza ho usato esattamente lo stesso metodo per eseguire una cosa simile.
Beh invece stavolta,puntualmente, la funzione da fare solo una volta, si ripresenta ogni volta dopo il 'risveglio'....
Tesi: la variabile viene azzerata dal deep sleep , ma come mai non succedeva negli altri sketch? mi bastava dichiarare le variabili con RTC_DATA_ATTR e leggerle e scrivere senza fare altro.
Domanda: Ho letto che dopo il deep sleep, il programma riprende dalla istruzione successiva. Da altre parti leggo che invece si riparte dal setup(). Nel mio caso e come se si ripartisse totalmente come se fosse fisicamente spento e riacceso.
Con questa MCU di fatto l'esecuzione del firmware riparte (più o meno) dall'inizio ovvero dalla funzione setup()
Per quanto riguarda il tuo problema, che versionde di Arduino core per ESP32 stai usando?
Con l'ultima disponibile (versione 2.0.9) gli esempi inclusi funzionano esattamente come dovrebbero
si sto usando l'ultima , daro' un'occhiata agli esempi, anche se ripeto, gli sketch precedenti funzionano.... qui invece e' come se ripartisse dalla prima riga di codice, ridefinendo ogni cosada zero.... se almeno ci fosse un debugger passo passo, potrei seguire esattamente il flusso e vedere cosa succede...
accipicchia , ho daato un 'occhiata e mi sono subito iscritto ad un corso accellerato di ingegneria elettronica, specializzazione semiconduttori!!!! Ai tempi del buon vecchio caro 'clipper' per intel, nel compilatore c'era anche un'opzione comodissima che metteva a video il programma in run riga per riga e ci si poteva fermare e ispezionare tutte le variabili. una cosa utilissima, senza nessuna aggiunta hardware e magheggi vari.... capisco che un esp32 e' un po' diverso, ma pensavo a qualcosa di piu' semplice.... vabbe, oggi vado a commentare a turno tutte le call alle funzioni chiamate prima e dopo il deep sleep e vediamo se qualcuna di esse interferisce col flusso del programma ......
Ma che discorsi sono? Il Clipper è un compilatore per PC, è normale che ci sia un ambiente di debug integrato che consente di fare esecuzione del programma step by step come nella stragrande maggioranza dei sistemi di sviluppo di questo tipo.
Non è solo questione di ESP32, nel mondo embedded è una cosa del tutto diversa: il debugging è sempre "esterno" e nel 99.99% dei casi è necessario l'apposito hardware specializzato per famiglia di microntrollori.
eh, adesso lo so :-), si impara sempre.
Ad ogni modo, escludendo varie funzioni, finalmente ottengo un comportamento prevedibile.
Ho ricominciato ad includere qualcosa. Procedo step by step e spero di isolare il responsabile. Lo pubblichero' qui, casomai qualcuno si imbattesse nella stessa cosa....
Penso di averlo trovato.
per essere sicuro che tutte le periferiche fossero chiuse prima del deep sleep eseguivo questo ciclo:
/*for (int i = 0; i < 40; i++) { // Chiudi tutte le GPIO
pinMode(i, INPUT);
digitalWrite(i, LOW);
}*/
Adesso ricontrollo, ma sembra essere la causa dell'azzeramento della RTC e di consequenza dell'ignoro dei controlli sul primo ciclo dopo il reset....
Ovviamente ignoro il perche' succeda.
UPDATE: Si' confermo.
UPDATE: Ho trovato questo:
ESP32: Please do not use the interrupt of GPIO36 and GPIO39 when using ADC or Wi-Fi and Bluetooth with sleep mode enabled. Please refer to the comments of adc1_get_raw . Please refer to Section 3.11 of ESP32 ECO and Workarounds for Bugs for the description of this issue.
si hai ragione, probabilmente, nel delirio di voler ridurre ad ogni costo qualunque consumo di energia, ho codificato la stupidata. Inoltre pare che vada a cozzare con qualche funzione sui dei pin quando usati assieme allo sleep....
Non so se, trovandosi a livello alto, commutandolo su input si attiverebbe la resistenza di pullup... Forse, però, per attivarla va posto a livello alto solo dopo averlo impostato come ingresso-
Penso di aver letto qualcosa del genere in passato e per questo poi, ho scritto quelle righe. Purtroppo ho dimenticato tutto e non avendo mai studiato per bene elettronica & c. Vi seguo con difficoltà….