Come si alimenta un ESP32 a batteria?
Modalità di consumo dell'ESP32 e correnti da datasheet, risveglio, coprocessore ULP, perché le schede consumano più del chip, brownout e calcolo dell'autonomia.
Foto: Deepak Rastogi / Unsplash
Dopo aver letto questo articolo saprai:
- Leggere la tabella delle modalità di consumo dell'ESP32 e sapere cosa resta alimentato in light sleep, deep sleep e hibernation
- Spiegare perché una scheda di sviluppo consuma molto più del chip e cosa provoca un reset da brownout
- Stimare l'autonomia a partire da tempo di veglia, corrente di veglia e corrente di sleep con una formula semplice
In questa pagina
Un ESP32 funziona a batteria passando quasi tutto il tempo in deep sleep, dove il chip classico assorbe 10 µA con alimentati solo il timer RTC e la memoria RTC, secondo il datasheet dell’ESP32, e svegliandosi per brevi momenti per misurare e trasmettere. La parte costosa è la radio: la sola ricezione Wi-Fi richiede da 95 a 100 mA. L’autonomia quindi dipende meno dalla corrente di sleep che da quanto spesso il dispositivo si sveglia, da quanto resta sveglio e da cos’altro sulla scheda continua ad assorbire corrente mentre il chip dorme.
Questa guida passa in rassegna le modalità di consumo, i modi per svegliare il chip, il coprocessore a bassissimo consumo, la differenza tra chip e scheda, il messaggio di brownout che spiazza molti primi progetti e un metodo per stimare l’autonomia senza tirare a indovinare.
Quali modalità di consumo ha l’ESP32?
Il datasheet dell’ESP32 classico definisce cinque modalità. Ognuna spegne una parte maggiore del chip e richiede più lavoro per tornare a eseguire codice.
| Modalità | Cosa resta in funzione | Corrente tipica (datasheet ESP32) |
|---|---|---|
| Active | CPU e radio | Da 95 a 100 mA in ricezione, fino a 240 mA in trasmissione 802.11b alla massima potenza |
| Modem-sleep | CPU, radio spenta | Da 20 a 68 mA secondo clock e core |
| Light-sleep | CPU in pausa, RTC e ULP attivi | 0,8 mA |
| Deep-sleep | Timer RTC, memoria RTC, ULP opzionale | 10 µA, oppure 150 µA con l’ULP alimentato |
| Hibernation | Un timer RTC e alcuni GPIO RTC | 5 µA |
Con il chip spento tramite il pin di abilitazione, il datasheet indica 1 µA. Quando il Wi-Fi è attivo il chip passa da solo tra active e modem-sleep, ed è per questo che un ESP32 connesso non scende mai al valore del light sleep a meno che l’applicazione non configuri il light sleep automatico.
I chip più recenti hanno valori minimi più bassi. I datasheet indicano correnti in deep sleep di 5 µA per l’ESP32-C3, 7 µA per l’ESP32-C6 e l’ESP32-H2, da 7 a 8 µA per l’ESP32-S3 e 12 µA per l’ESP32-C5, sempre con il timer RTC e la memoria a basso consumo accesi.
Cosa può svegliare un ESP32 dal deep sleep?
La documentazione di ESP-IDF sulle modalità di sleep elenca le sorgenti di risveglio per l’ESP32 classico: il timer RTC, un singolo GPIO RTC a un livello scelto (ext0), più GPIO RTC combinati (ext1), il sensore touch, il coprocessore ULP e, tramite una chiamata separata per il risveglio da GPIO, i pin del dominio di alimentazione RTC. Il risveglio da UART funziona solo dal light sleep.
Svegliarsi dal deep sleep equivale a un riavvio. CPU e gran parte della RAM erano spente, quindi parte il bootloader e l’applicazione ricomincia dall’inizio. Le variabili marcate RTC_DATA_ATTR stanno nella memoria RTC e sopravvivono, ed è così che il firmware conserva tra un risveglio e l’altro un contatore, un buffer di letture o l’ultimo canale Wi-Fi. Le connessioni Wi-Fi e Bluetooth non sopravvivono né al light sleep né al deep sleep; la documentazione indica di fermare la radio prima di dormire e di riconnettersi dopo. Un dispositivo che deve restare associato a un access point usa invece il modem-sleep con light sleep automatico, con una corrente media molto più alta.
Un errore facile: un GPIO con pull-up interno collegato a circuiti esterni può disperdere corrente durante lo sleep. La documentazione consiglia di chiamare rtc_gpio_isolate() su quei pin prima di entrare in deep sleep.
Cosa fa il coprocessore ULP?
Il coprocessore a bassissimo consumo (ULP) è un piccolo processore che resta in funzione mentre i core principali dormono. Può leggere sensori e periferiche e svegliare la CPU principale solo quando succede qualcosa di interessante, per esempio quando un valore supera una soglia. La documentazione ULP descrive tre generazioni: l’ULP-FSM su ESP32, S2 e S3, programmato in assembly; l’ULP-RISC-V su S2 e S3, programmato in C; e il core LP su C5, C6 e P4, un core RISC-V con accesso più ampio a memoria e periferiche.
L’ULP non è gratis. Sull’ESP32 classico il deep sleep con l’ULP alimentato sale da 10 µA a 150 µA, e il datasheet indica 100 µA per un “sensor-monitored pattern” con l’ADC a un duty cycle dell’1%. L’ULP conviene quando fa risparmiare risvegli: controllare un contatto porta o un livello d’acqua qualche volta al secondo costa molto meno che avviare ogni volta CPU principale e radio.
Perché una scheda di sviluppo consuma più del chip?
I valori del datasheet descrivono il solo chip. Una scheda di sviluppo aggiunge componenti che continuano ad assorbire corrente mentre il chip dorme: un regolatore di tensione lineare con la sua corrente di riposo, un convertitore USB-UART, un LED di alimentazione, resistenze di pull-up e i sensori collegati. Conta anche la memoria. Il datasheet dell’ESP32-S3 chiede di aggiungere al valore del light sleep il consumo della PSRAM, per esempio 140 µA per 8 MB di PSRAM octal a 3,3 V.
Il risultato è che una scheda che dovrebbe dormire a 10 µA può assorbire molte volte quel valore, e la stima di autonomia costruita sul numero del datasheet sbaglia di un ordine di grandezza. Per un prodotto a batteria scegli o progetta una scheda con un regolatore a bassa corrente di riposo, nessun LED sempre acceso e un convertitore USB alimentato solo dalla USB, e spegni i sensori tramite un GPIO o un interruttore di carico. Poi misura l’intera scheda, con uno strumento che risolve i microampere e cattura i brevi picchi della fase di veglia.
Cosa significa “Brownout detector was triggered”?
Il brownout detector controlla la tensione di alimentazione e resetta il chip quando scende sotto un livello sicuro. La pagina sugli errori fatali di ESP-IDF spiega che il chip stampa “Brownout detector was triggered” e si resetta, e che il rilevatore è attivo per impostazione predefinita e si configura con CONFIG_ESP_BROWNOUT_DET e CONFIG_ESP_BROWNOUT_DET_LVL_SEL.
La causa abituale è un’alimentazione che non riesce a seguire i picchi di corrente della trasmissione Wi-Fi. Le linee guida di progettazione hardware di Espressif avvertono che l’aumento improvviso di corrente quando il chip trasmette può far crollare la linea di alimentazione, e chiedono un’alimentazione a 3,3 V da almeno 500 mA con almeno 10 µF di capacità all’ingresso. I colpevoli più comuni sono cavi USB lunghi e sottili, porte USB deboli, regolatori sottodimensionati, batterie quasi scariche e batterie a bottone, che non possono fornire i picchi di corrente del Wi-Fi. Correggi l’alimentazione invece di disattivare il rilevatore, che nasconderebbe solo il sintomo. Per alimentazioni che salgono o scendono lentamente, come i circuiti solari o di ricarica, le stesse linee guida consigliano un chip supervisore sul pin di abilitazione con una soglia intorno a 3,0 V.
Come si stima l’autonomia?
Dividi il ciclo del dispositivo in una fase di veglia e una di sleep, misurale entrambe sulla scheda reale e calcola la media:
I_avg = (I_wake × t_wake + I_sleep × t_sleep) / (t_wake + t_sleep)
life (hours) = usable capacity (mAh) / I_avg (mA)I_wake e t_wake coprono tutto dal risveglio al ritorno in sleep: avvio, lettura del sensore, associazione Wi-Fi, DHCP, handshake TLS e pubblicazione MQTT. I_sleep è la corrente di sleep dell’intera scheda, non il valore del datasheet. La capacità utilizzabile è inferiore a quella di targa: riducila per l’autoscarica, le basse temperature e la tensione alla quale il tuo regolatore smette di funzionare.
La formula mostra dove concentrare gli sforzi. Un giorno intero di deep sleep ai 10 µA del datasheet vale 0,24 mAh, la stessa carica di circa nove secondi di ricezione Wi-Fi a 100 mA. Una volta tenuta sotto controllo la corrente di sleep della scheda, conta soprattutto ridurre il tempo di veglia: trasmetti meno spesso, accumula più letture nella memoria RTC e inviale insieme, evita una scansione Wi-Fi completa a ogni risveglio e tieni breve la sessione TLS. Se la fase di veglia non si accorcia abbastanza, la radio è quella sbagliata, e Bluetooth LE, Thread o LoRaWAN faranno meglio del Wi-Fi.
Per continuare
- Scegliere un ESP32 confronta le varianti, compresi i C6 e H2 a basso consumo.
- ESP32 con MQTT descrive il ciclo di connessione, pubblicazione e disconnessione di un dispositivo che dorme.
- Bluetooth Low Energy per l’IoT spiega la radio adatta alle batterie più piccole.
- Tipi di dispositivi IoT e i vincoli che ne determinano la progettazione mette i budget energetici nel loro contesto.
Argomenti: ESP32, deep sleep, autonomia, basso consumo, hardware