14.1.1.2. Compilazione del firmware

Con l’ambiente di Configurazione dell’ambiente di sviluppo predisposto, compilare un’immagine firmware sono due comandi make più una selezione di TARGET.

14.1.1.2.1. Compilazione

Per prima cosa compila mpy-cross, lo strumento host che compila i moduli .py congelati in bytecode (fallo una volta, e di nuovo ogni volta che aggiorni MicroPython):

make -j$(nproc) -C lib/micropython/mpy-cross

Poi compila il firmware per una scheda, dove <TARGET> è uno dei nomi della tabella sottostante:

make -j$(nproc) TARGET=<TARGET>

-j$(nproc) compila in parallelo su tutti i core della CPU (su macOS usa -j$(sysctl -n hw.ncpu)). TARGET è obbligatorio – make senza target si interrompe con «Invalid or no TARGET specified».

Una prima build completa, dall’inizio alla fine:

make sdk
make -j$(nproc) -C lib/micropython/mpy-cross
make -j$(nproc) TARGET=OPENMV4

14.1.1.2.1.1. Schede supportate

I valori di TARGET sono i nomi delle directory sotto boards/. Le camere e il loro silicio:

Camera	TARGET	MCU	Port	Core
OpenMV Cam M4	OPENMV2	STM32F427	stm32	Cortex-M4
OpenMV Cam M7	OPENMV3	STM32F765	stm32	Cortex-M7
OpenMV Cam H7	OPENMV4	STM32H743	stm32	Cortex-M7
OpenMV Cam H7 Plus	OPENMV4P	STM32H743 + SDRAM	stm32	Cortex-M7
OpenMV Pure Thermal	OPENMVPT	STM32H743 + SDRAM	stm32	Cortex-M7
OpenMV Cam N6	OPENMV_N6	STM32N657	stm32	Cortex-M55
OpenMV Cam RT1062	OPENMV_RT1060	MIMXRT1062	mimxrt	Cortex-M7
OpenMV AE3	OPENMV_AE3	Alif Ensemble (dual M55)	alif	Cortex-M55
Arduino Portenta H7	ARDUINO_PORTENTA_H7	STM32H747	stm32	Cortex-M7
Arduino Giga	ARDUINO_GIGA	STM32H747	stm32	Cortex-M7
Arduino Nicla Vision	ARDUINO_NICLA_VISION	STM32H747	stm32	Cortex-M7
Arduino Nano 33 BLE Sense	ARDUINO_NANO_33_BLE_SENSE	nRF52840	nrf	Cortex-M4
Arduino Nano RP2040 Connect	ARDUINO_NANO_RP2040_CONNECT	RP2040	rp2	Cortex-M0+

Compila l’esatto TARGET per il tuo hardware – ad es. OPENMV4 per la OpenMV Cam H7, OPENMV4P per la H7 Plus, OPENMV_N6 per la N6.

14.1.1.2.1.2. Output della build

Tutto ciò che riguarda una scheda finisce in build/<TARGET>/bin/. Per TARGET=OPENMV4 ciò è build/OPENMV4/bin/, che contiene:

File	Che cos’è
firmware.bin	Binario del firmware – flashato da OpenMV IDE Tools -> Load Custom Firmware e da dfu-util
firmware.elf	Firmware con simboli di debug – il file a cui punti il debugger
bootloader.bin / .elf	Il bootloader (solo sulle schede con un bootloader abilitato)
openmv.bin	Immagine combinata bootloader + firmware
romfs<n>.img	Immagine del filesystem ROM di sola lettura flashata insieme al firmware

L’Alif AE3 è dual-core, quindi produce firmware_M55_HP.elf / firmware_M55_HP.bin (il core ad alte prestazioni) e un separato firmware_M55_HE.elf / firmware_M55_HE.bin (il core ad alta efficienza) più un’immagine di indice (TOC) che indica alla boot ROM dove risiede l’immagine di ciascun core.

14.1.1.2.1.3. Pulizia e ricompilazione

Le build sono isolate per scheda sotto build/<TARGET>/. Per cancellare la build di una scheda:

make TARGET=<TARGET> clean

Non esiste un distclean; clean richiede sempre un TARGET. mpy-cross è condiviso tra le schede – se aggiorni MicroPython, ricompila anche quello:

make -C lib/micropython/mpy-cross clean
make -j$(nproc) -C lib/micropython/mpy-cross

Per riportare l’utilizzo di flash/RAM di una build:

make TARGET=<TARGET> size

14.1.1.2.1.4. Compilazione in Docker (nessun toolchain host)

Se preferisci non installare nulla sull’host (o sei su una piattaforma senza una build nativa), usa il percorso Docker:

git clone --recursive https://github.com/openmv/openmv.git
cd openmv/docker
make TARGET=<TARGET>

Gli artefatti compaiono in openmv/docker/build/<TARGET>. Per build ripetute esiste un percorso di sviluppo incrementale che monta il repository allo stesso percorso assoluto all’interno del container come sull’host, così i percorsi sorgente del debugger si risolvono senza rimappatura:

make install-sdk
make build-firmware-dev TARGET=<TARGET>

Esegui make clean-dev quando cambi TARGET.

14.1.1.2.2. Opzioni di build

Il comportamento della build è controllato da variabili passate sulla riga di comando make, per esempio:

make -j$(nproc) TARGET=OPENMV4 DEBUG=1 V=1

Le variabili che uno sviluppatore di firmware userà:

Variabile	Predefinito	Effetto
TARGET	(obbligatorio)	La scheda da compilare. Seleziona boards/<TARGET>/board_config.mk, che imposta l’MCU, il core, la mappa di memoria, gli ID USB e i moduli abilitati.
DEBUG	0	DEBUG=1 compila con -Og -ggdb3 (ottimizzato per il debug, informazioni di debug GDB complete) e disabilita la compressione del testo ROM di MicroPython – questa è la build che usi per il debug. DEBUG=0 compila con -O2 -DNDEBUG (più piccola, più veloce, assert disattivati) ed è la build di rilascio.
V	0	V=1 stampa ogni comando del compilatore/linker invece del breve riassunto CC file.c. Usalo per vedere i flag esatti o diagnosticare problemi di build.
DEBUG_PRINTF	0	DEBUG_PRINTF=1 definisce OMV_DEBUG_PRINTF, abilitando l’output di debug printf di basso livello nel firmware (da abbinare a SWO/RTT, vedi Debug del firmware).
PROFILE_ENABLE	0	PROFILE_ENABLE=1 compila con strumentazione delle chiamate di funzione (-finstrument-functions, -DOMV_PROFILER_ENABLE=1) così puoi profilare dove viene speso il tempo. PROFILE_HASH=<N> imposta la dimensione della tabella hash del profiler (potenza di due; predefinito 256) e PROFILE_IRQ=1 profila anche il codice in esecuzione nel contesto degli interrupt.
STACK_PROTECTOR	0	STACK_PROTECTOR=1 aggiunge -fstack-protector-all – canarini di stack che intercettano gli overflow dei buffer di stack. Utile quando si dà la caccia alla corruzione della memoria.
DEBUGGER	JLINK	Quale debugger usano i target make debug / make deploy. JLINK è il predefinito; NONE disabilita il target debug.

Nota

Esistono molte altre variabili (driver di camera/sensore, stack wireless, backend ML, stack USB, secure boot, ecc.), ma quelle sono impostate per scheda in boards/<TARGET>/board_config.mk e normalmente non vengono sovrascritte sulla riga di comando. Modificarle è personalizzazione della scheda, non una normale build da sviluppatore – vedi docs/boards.md nel repository del firmware.

Per il lavoro quotidiano le uniche opzioni di cui hai bisogno sono TARGET (sempre), DEBUG=1 (ogni volta che intendi fare debug, vedi Debug del firmware), e occasionalmente V=1.