14.1.1.2. De firmware bouwen¶

Met de omgeving uit De ontwikkelomgeving opzetten op zijn plaats is het bouwen van een firmware-image een kwestie van twee make-commando’s plus een TARGET-selectie.

14.1.1.2.1. Compileren¶

Bouw eerst mpy-cross, het host-hulpprogramma dat de bevroren .py-modules compileert tot bytecode (doe dit één keer, en opnieuw telkens wanneer je MicroPython bijwerkt):

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

Bouw vervolgens de firmware voor een board, waarbij <TARGET> één van de namen uit de onderstaande tabel is:

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

-j$(nproc) bouwt parallel over alle CPU-cores (gebruik op macOS -j$(sysctl -n hw.ncpu)). TARGET is verplicht – make zonder target breekt af met “Invalid or no TARGET specified”.

Een volledige eerste build, van begin tot eind:

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

14.1.1.2.1.1. Ondersteunde boards¶

TARGET-waarden zijn de mapnamen onder boards/. De camera’s en hun silicium:

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+

Bouw exact de TARGET voor jouw hardware – bijv. OPENMV4 voor de OpenMV Cam H7, OPENMV4P voor de H7 Plus, OPENMV_N6 voor de N6.

14.1.1.2.1.2. Build-uitvoer¶

Alles voor een board belandt in build/<TARGET>/bin/. Voor TARGET=OPENMV4 is dat build/OPENMV4/bin/, met daarin:

Bestand	Wat het is
`firmware.bin`	Firmware-binary – geflasht door OpenMV IDE Tools -> Load Custom Firmware en door `dfu-util`
`firmware.elf`	Firmware met debugsymbolen – het bestand waar je de debugger op richt
`bootloader.bin` / `.elf`	De bootloader (alleen op boards met een ingeschakelde bootloader)
`openmv.bin`	Gecombineerd bootloader + firmware-image
`romfs<n>.img`	Alleen-lezen ROM-bestandssysteem-image die naast de firmware wordt geflasht

De Alif AE3 is dual-core, dus die produceert firmware_M55_HP.elf / firmware_M55_HP.bin (de high-performance core) en een aparte firmware_M55_HE.elf / firmware_M55_HE.bin (de high-efficiency core) plus een inhoudsopgave- (TOC-)image die de boot-ROM vertelt waar de image van elke core zich bevindt.

14.1.1.2.1.3. Opschonen en herbouwen¶

Builds zijn per board geïsoleerd onder build/<TARGET>/. Om de build van één board te wissen:

make TARGET=<TARGET> clean

Er is geen distclean; clean heeft altijd een TARGET nodig. mpy-cross wordt gedeeld over de boards – als je MicroPython bijwerkt, herbouw het dan ook:

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

Om het flash-/RAM-gebruik van een build te rapporteren:

make TARGET=<TARGET> size

14.1.1.2.1.4. Bouwen in Docker (geen host-toolchain)¶

Als je liever niets op de host installeert (of je zit op een platform zonder native build), gebruik dan het Docker-pad:

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

Artefacten verschijnen in openmv/docker/build/<TARGET>. Voor herhaalde builds is er een incrementeel ontwikkelpad dat de repo op hetzelfde absolute pad binnen de container mount als op de host, zodat broncodepaden van de debugger zonder hertoewijzing worden opgelost:

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

Voer make clean-dev uit bij het wisselen van TARGET.

14.1.1.2.2. Build-opties¶

Het build-gedrag wordt geregeld door variabelen die op de make-commandoregel worden meegegeven, bijvoorbeeld:

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

De variabelen die een firmware-ontwikkelaar zal gebruiken:

Variabele	Standaard	Effect
`TARGET`	(vereist)	Het te bouwen board. Selecteert `boards/<TARGET>/board_config.mk`, die de MCU, core, geheugenkaart, USB-ID’s en ingeschakelde modules instelt.
`DEBUG`	`0`	`DEBUG=1` compileert met `-Og -ggdb3` (debug-geoptimaliseerd, volledige GDB-debuginformatie) en schakelt MicroPython-ROM-tekstcompressie uit – dit is de build die je debugt. `DEBUG=0` compileert met `-O2 -DNDEBUG` (kleiner, sneller, asserts uit) en is de release-build.
`V`	`0`	`V=1` print elk compiler-/linker-commando in plaats van de korte `CC file.c`-samenvatting. Gebruik het om exacte vlaggen te zien of om buildproblemen te diagnosticeren.
`DEBUG_PRINTF`	`0`	`DEBUG_PRINTF=1` definieert `OMV_DEBUG_PRINTF` en schakelt laag-niveau debug-`printf`-uitvoer in de firmware in (combineer met SWO/RTT, zie De firmware debuggen).
`PROFILE_ENABLE`	`0`	`PROFILE_ENABLE=1` bouwt met functie-aanroep-instrumentatie (`-finstrument-functions`, `-DOMV_PROFILER_ENABLE=1`) zodat je kunt profileren waar tijd aan wordt besteed. `PROFILE_HASH=<N>` stelt de grootte van de hashtabel van de profiler in (macht van twee; standaard 256) en `PROFILE_IRQ=1` profileert ook code die in interruptcontext draait.
`STACK_PROTECTOR`	`0`	`STACK_PROTECTOR=1` voegt `-fstack-protector-all` toe – stack-canaries die stack-bufferoverlopen opvangen. Nuttig bij het opsporen van geheugencorruptie.
`DEBUGGER`	`JLINK`	Welke debugger de `make debug` / `make deploy`-targets gebruiken. `JLINK` is de standaard; `NONE` schakelt het `debug`-target uit.

Notitie

Er bestaan nog veel meer variabelen (camera-/sensordrivers, draadloze stacks, ML-backends, USB-stack, secure boot, enz.), maar die worden per board ingesteld in boards/<TARGET>/board_config.mk en worden normaal gesproken niet op de commandoregel overschreven. Het wijzigen ervan is boardaanpassing, geen normale ontwikkelaarsbuild – zie docs/boards.md in de firmware-repository.

Voor het dagelijks werk zijn de enige opties die je nodig hebt TARGET (altijd), DEBUG=1 (telkens wanneer je van plan bent te debuggen, zie De firmware debuggen) en af en toe V=1.