14.1.1.2. Die Firmware bauen

Mit der Umgebung aus Einrichten der Entwicklungsumgebung an Ort und Stelle besteht das Bauen eines Firmware-Images aus zwei make-Befehlen plus einer TARGET-Auswahl.

14.1.1.2.1. Kompilieren

Baue zuerst mpy-cross, das Host-Werkzeug, das die eingefrorenen .py-Module in Bytecode kompiliert (mache dies einmal und erneut, sobald du MicroPython aktualisierst):

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

Baue dann die Firmware für ein Board, wobei <TARGET> einer der Namen aus der untenstehenden Tabelle ist:

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

-j$(nproc) baut parallel über alle CPU-Kerne (verwende unter macOS -j$(sysctl -n hw.ncpu)). TARGET ist obligatorisch – make ohne Target bricht mit „Invalid or no TARGET specified“ ab.

Ein vollständiger erster Build, von Anfang bis Ende:

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

14.1.1.2.1.1. Unterstützte Boards

TARGET-Werte sind die Verzeichnisnamen unter boards/. Die Kameras und ihr Silizium:

Kamera	TARGET	MCU	Port	Kern
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+

Baue das exakte TARGET für deine Hardware – z. B. OPENMV4 für die OpenMV Cam H7, OPENMV4P für die H7 Plus, OPENMV_N6 für die N6.

14.1.1.2.1.2. Build-Ausgabe

Alles für ein Board landet in build/<TARGET>/bin/. Für TARGET=OPENMV4 ist das build/OPENMV4/bin/ und enthält:

Datei	Was es ist
firmware.bin	Firmware-Binärdatei – geflasht durch OpenMV IDE Tools -> Load Custom Firmware und durch dfu-util
firmware.elf	Firmware mit Debug-Symbolen – die Datei, auf die du den Debugger richtest
bootloader.bin / .elf	Der Bootloader (nur auf Boards mit aktiviertem Bootloader)
openmv.bin	Kombiniertes Bootloader- + Firmware-Image
romfs<n>.img	Schreibgeschütztes ROM-Dateisystem-Image, das zusammen mit der Firmware geflasht wird

Der Alif AE3 ist Dual-Core, daher erzeugt er firmware_M55_HP.elf / firmware_M55_HP.bin (der Hochleistungskern) und ein separates firmware_M55_HE.elf / firmware_M55_HE.bin (der hocheffiziente Kern) plus ein Inhaltsverzeichnis-Image (TOC), das dem Boot-ROM mitteilt, wo das Image jedes Kerns liegt.

14.1.1.2.1.3. Bereinigen und neu bauen

Builds sind pro Board unter build/<TARGET>/ isoliert. Um den Build eines Boards zu löschen:

make TARGET=<TARGET> clean

Es gibt kein distclean; clean benötigt immer ein TARGET. mpy-cross wird boardübergreifend gemeinsam genutzt – wenn du MicroPython aktualisierst, baue es ebenfalls neu:

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

Um die Flash-/RAM-Nutzung eines Builds zu melden:

make TARGET=<TARGET> size

14.1.1.2.1.4. Bauen in Docker (keine Host-Toolchain)

Wenn du lieber nichts auf dem Host installieren möchtest (oder du auf einer Plattform ohne nativen Build bist), verwende den Docker-Weg:

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

Artefakte erscheinen in openmv/docker/build/<TARGET>. Für wiederholte Builds gibt es einen inkrementellen Dev-Weg, der das Repo unter demselben absoluten Pfad innerhalb des Containers wie auf dem Host einhängt, sodass die Debugger-Quellpfade ohne Neuzuordnung aufgelöst werden:

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

Führe make clean-dev aus, wenn du TARGET wechselst.

14.1.1.2.2. Build-Optionen

Das Build-Verhalten wird durch Variablen gesteuert, die auf der make-Kommandozeile übergeben werden, zum Beispiel:

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

Die Variablen, die ein Firmware-Entwickler verwenden wird:

Variable	Standard	Wirkung
TARGET	(erforderlich)	Das zu bauende Board. Wählt boards/<TARGET>/board_config.mk aus, das den MCU, den Kern, das Speicherlayout, die USB-IDs und die aktivierten Module festlegt.
DEBUG	0	DEBUG=1 kompiliert mit -Og -ggdb3 (debug-optimiert, vollständige GDB-Debug-Informationen) und deaktiviert die MicroPython-ROM-Text-Kompression – das ist der Build, den du debuggst. DEBUG=0 kompiliert mit -O2 -DNDEBUG (kleiner, schneller, Asserts aus) und ist der Release-Build.
V	0	V=1 gibt jeden Compiler-/Linker-Befehl aus, statt der kurzen CC file.c-Zusammenfassung. Verwende es, um die exakten Flags zu sehen oder Build-Probleme zu diagnostizieren.
DEBUG_PRINTF	0	DEBUG_PRINTF=1 definiert OMV_DEBUG_PRINTF und aktiviert die Low-Level-Debug-printf-Ausgabe in der Firmware (kombiniere mit SWO/RTT, siehe Debugging der Firmware).
PROFILE_ENABLE	0	PROFILE_ENABLE=1 baut mit Funktionsaufruf-Instrumentierung (-finstrument-functions, -DOMV_PROFILER_ENABLE=1), sodass du profilieren kannst, wo Zeit verbracht wird. PROFILE_HASH=<N> legt die Größe der Hash-Tabelle des Profilers fest (Zweierpotenz; Standard 256) und PROFILE_IRQ=1 profiliert auch Code, der im Interrupt-Kontext läuft.
STACK_PROTECTOR	0	STACK_PROTECTOR=1 fügt -fstack-protector-all hinzu – Stack-Canaries, die Stack-Puffer-Überläufe abfangen. Nützlich bei der Suche nach Speicherbeschädigungen.
DEBUGGER	JLINK	Welchen Debugger die Targets make debug / make deploy verwenden. JLINK ist der Standard; NONE deaktiviert das debug-Target.

Bemerkung

Es gibt viele weitere Variablen (Kamera-/Sensortreiber, Wireless-Stacks, ML-Backends, USB-Stack, Secure Boot usw.), aber diese werden pro Board in boards/<TARGET>/board_config.mk gesetzt und normalerweise nicht auf der Kommandozeile überschrieben. Sie zu ändern ist Board-Anpassung, kein normaler Entwickler-Build – siehe docs/boards.md im Firmware-Repository.

Für die tägliche Arbeit sind die einzigen Optionen, die du benötigst, TARGET (immer), DEBUG=1 (immer wenn du debuggen möchtest, siehe Debugging der Firmware) und gelegentlich V=1.