La scheda non è ancora arrivata, ma il firmware deve avanzare. È una situazione comune: il circuito è in revisione, i primi prototipi sono condivisi tra più persone oppure un errore compare soltanto dopo una modifica difficile da isolare. In questi casi, poter eseguire una parte delle verifiche sul computer aiuta a distinguere i problemi del software da quelli dell’hardware.
Con Zephyr e il fork QEMU di Espressif è possibile eseguire firmware per alcuni ESP32 in un ambiente emulato. Il vantaggio è anticipare verifiche mirate e renderle ripetibili. Per usarlo bene, però, bisogna sapere che cosa rappresenta il modello e quali prove richiedono ancora il dispositivo reale.
Lo spunto arriva dalla guida pubblicata da Espressif il 15 settembre 2026, dedicata all’avvio di Zephyr e al debug con QEMU. L’aspetto interessante per chi sviluppa prodotti è il metodo: preparare prima una base software osservabile, poi verificarla sulla scheda.
Come funziona l’emulazione ESP32 con Zephyr e QEMU
Nel flusso di lavoro entrano tre elementi. Zephyr fornisce il sistema operativo e l’ambiente dell’applicazione. La toolchain compila i sorgenti per l’architettura del target. QEMU esegue quel codice usando un modello software della macchina, sul computer di sviluppo.
Il debugger permette di fermare l’esecuzione, osservare memoria e registri e seguire un percorso del programma. Il collegamento avviene attraverso il meccanismo remoto descritto nella documentazione QEMU per GDB. Non serve collegare una sonda fisica alla scheda per questa sessione emulata.
Questa distinzione aiuta a interpretare il risultato. Se l’applicazione raggiunge il punto atteso, abbiamo verificato un percorso in quella configurazione. Non abbiamo ancora misurato come reagirà una linea di alimentazione a un picco di corrente o quanto impiegherà una trasmissione nel luogo di installazione.
Quali ESP32 considerare e come verificare il supporto
La documentazione Zephyr per Espressif QEMU elenca i seguenti abbinamenti. La disponibilità della variante nella propria versione di Zephyr va controllata prima di preparare la build.
| SoC | Architettura | Eseguibile QEMU |
|---|---|---|
| ESP32 | Xtensa | qemu-system-xtensa |
| ESP32-S3 | Xtensa | qemu-system-xtensa |
| ESP32-C3 | RISC-V | qemu-system-riscv32 |
| ESP32-C6 | RISC-V | qemu-system-riscv32, con modello C6 disponibile |
Per ESP32-C6 serve una verifica in più: i pacchetti precompilati della release esp-develop-9.2.2-20260417 citata nella documentazione non includono quel modello; il percorso indicato è la compilazione del ramo esp-develop. Per pacchetti successivi, controllare le release ufficiali e l’elenco delle macchine effettivamente disponibili.
Che cosa si può verificare e che cosa resta fuori
La matrice delle funzionalità Espressif QEMU è il riferimento per le periferiche modellate. Le capacità cambiano tra i SoC: non vanno dedotte dal solo nome ESP32. Wi-Fi e Bluetooth non sono emulati; anche numerose interfacce verso sensori e dispositivi esterni restano escluse.
La stessa matrice descrive periferiche virtuali aggiuntive per alcuni impieghi, come una connessione Ethernet emulata. La presenza di un percorso di rete virtuale non verifica il collegamento Wi-Fi del prodotto: associazione, antenna, interferenze e copertura richiedono prove dedicate.
Per decidere se un test è adatto, conviene formulare una domanda precisa. “Il parser rifiuta un messaggio incompleto?” è diverso da “Il sensore risponde correttamente sul bus?”. Nel primo caso possiamo costruire input controllati; nel secondo dipendiamo anche dal driver, dal modello della periferica e, infine, dal collegamento fisico.
Un primo avvio su ESP32-C3: da dove partire
Il punto di partenza è un workspace Zephyr funzionante, con SDK, dipendenze Espressif e una revisione che includa il target QEMU richiesto. Per predisporlo, seguire la guida di installazione Zephyr. L’emulatore va installato separatamente dalle release Espressif.
Prima della compilazione, controllare che il binario trovato dal terminale conosca la macchina desiderata:
qemu-system-riscv32 -machine helpNell’elenco deve essere presente esp32c3. Se manca, controllare il percorso del programma e la sua versione. Compilatore ed emulatore hanno ruoli diversi: installare soltanto il primo non aggiunge il modello del chip al secondo.
Questa è una sequenza di riferimento basata sulla documentazione, da eseguire dalla radice del workspace, dove esiste la directory zephyr/. Non è un resoconto di una misura di laboratorio:
west build \
-b esp32c3_devkitc/esp32c3/qemu \
zephyr/samples/hello_world \
-d build-qemu-c3 --no-sysbuild --pristine
west build -d build-qemu-c3 -t runLa variante /qemu seleziona la configurazione per l’emulazione. Il primo controllo consiste nell’osservare l’avvio e il messaggio del sample, senza attribuire a questo risultato la validazione dell’applicazione completa.
La documentazione di west build chiarisce l’uso delle directory di compilazione e di --pristine, che ricrea il contenuto della directory di build. Usare una cartella dedicata e conservare sorgenti e documenti altrove. Quando cambia target o configurazione, una build pulita evita di riutilizzare impostazioni precedenti.
Per passare al debug, il flusso Espressif prevede il target debugserver e il GDB dell’architettura corretta. Il file zephyr.elf deve corrispondere alla build in esecuzione: simboli di un’altra compilazione possono rendere fuorviante l’analisi.
Un caso concreto: verificare la gestione di un allarme
Consideriamo un esempio progettuale: un dispositivo legge una temperatura, attiva un allarme oltre una soglia e lo disattiva quando il valore scende sotto una seconda soglia. L’isteresi evita continue commutazioni vicino al limite. Prima ancora del sensore, ci sono decisioni software da verificare.
Si può separare la lettura della misura dalla funzione che aggiorna lo stato. Il test fornisce una sequenza nota: valore normale, superamento della soglia, oscillazione intermedia e rientro. Per ogni passaggio confronta lo stato ottenuto con quello atteso. Si aggiungono poi lettura non valida, dato troppo vecchio e configurazione incoerente.
Gli input sintetici verificano la logica che li riceve. Non dimostrano che un sensore I2C funzioni dentro QEMU. Questa separazione consente di trovare un errore nell’isteresi senza dipendere dal cablaggio; quando arriva la scheda, il lavoro si concentra anche su acquisizione, tempi e gestione degli errori del driver.
Un rapporto utile deve dire quale requisito è stato verificato. “Allarme attivo dopo una misura valida oltre soglia” è un risultato leggibile; “test OK” da solo non spiega copertura e limiti. Se il software è stato modificato per un nuovo sensore, ripetere la sequenza aiuta a individuare regressioni nelle regole applicative.
Test della logica, emulazione e scheda reale: tre livelli complementari
Per un prodotto conviene organizzare verifiche diverse, ciascuna con un obiettivo. I test della logica cercano errori nelle decisioni. L’emulazione osserva parti dell’integrazione del firmware. Le prove sul dispositivo verificano proprietà che esistono soltanto nell’hardware e nel suo ambiente.
Zephyr offre Ztest per strutturare verifiche e asserzioni. La piattaforma native_sim permette inoltre di eseguire applicazioni Zephyr compilate per l’host. È un ambiente diverso dall’emulazione di un ESP32: può essere utile quando l’obiettivo riguarda la logica o l’integrazione software senza riprodurre quel SoC.
In una pipeline automatizzata, registrerei per ogni esecuzione revisione del codice, configurazione, versioni degli strumenti e risultato atteso. Il job dovrebbe riconoscere un fallimento applicativo, un timeout e un problema nell’avvio dell’ambiente come eventi distinti. Altrimenti un processo terminato può essere scambiato per un test superato.
Per partire, meglio scegliere poche verifiche legate a errori costosi: configurazione non valida, messaggio incompleto, coda piena, recupero dopo un’anomalia. Il guadagno si valuta osservando quali difetti vengono intercettati prima e quali restano da riprodurre sulla scheda. Non esiste una percentuale di risparmio valida per ogni progetto.
Domande frequenti su ESP32, Zephyr e QEMU
Posso usare QEMU per verificare Wi-Fi e Bluetooth dell’ESP32?
Nel flusso descritto, queste radio non sono emulate. Per verificarne funzionamento e prestazioni serve hardware reale. Un’interfaccia di rete virtuale non equivale a una prova radio.
Posso usare automaticamente la configurazione del prodotto?
Occorre controllare le dipendenze dalle periferiche. Un’applicazione che inizializza componenti non modellati può richiedere una configurazione di test o interfacce sostituibili. Le differenze rispetto al firmware di produzione vanno documentate.
Un test passato in QEMU è sufficiente per rilasciare il firmware?
È una parte delle evidenze. Il rilascio richiede criteri riferiti al prodotto, comprese integrazione sulla scheda, gestione degli errori e condizioni operative previste.
Portare le verifiche dentro il progetto firmware
Un buon punto di partenza è scegliere il modulo più critico del software e definire quali comportamenti debbano restare invariati. Da lì si costruiscono test ripetibili, si decide dove eseguirli e si collegano i risultati alle prove sul dispositivo.
Silicon LogiX segue lo sviluppo firmware ESP32, l’integrazione dei sistemi e le attività di debug e ottimizzazione firmware. Per valutare il percorso di verifica del tuo prodotto, descrivi il dispositivo, lo stato del software e il problema da risolvere.
Per approfondire: FreeRTOS, Zephyr e ThreadX a confronto, ESP32 con Wi-Fi e interfaccia web e diagnostica dei reset in campo.
Riferimenti tecnici consultati il 29 settembre 2026. I diagrammi sono schemi originali; il caso dell’allarme è un esempio progettuale. Comandi e compatibilità vanno verificati rispetto alle versioni installate.
