14.1.1.2. Budowanie oprogramowania układowego

Mając przygotowane środowisko z Konfiguracja środowiska programistycznego, zbudowanie obrazu oprogramowania układowego sprowadza się do dwóch poleceń make plus wyboru TARGET.

14.1.1.2.1. Kompilacja

Najpierw zbuduj mpy-cross, narzędzie hosta kompilujące zamrożone moduły .py do kodu bajtowego (zrób to raz, a następnie ponownie zawsze, gdy aktualizujesz MicroPython):

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

Następnie zbuduj oprogramowanie układowe dla płytki, gdzie <TARGET> jest jedną z nazw z poniższej tabeli:

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

-j$(nproc) buduje równolegle na wszystkich rdzeniach procesora (na macOS użyj -j$(sysctl -n hw.ncpu)). TARGET jest obowiązkowy – make bez celu przerywa działanie komunikatem „Invalid or no TARGET specified”.

Pełna pierwsza kompilacja, od początku do końca:

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

14.1.1.2.1.1. Obsługiwane płytki

Wartości TARGET to nazwy katalogów w boards/. Kamery i ich układy scalone:

Kamera	TARGET	MCU	Port	Rdzeń
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 (podwójny 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+

Zbuduj dokładnie ten TARGET, który odpowiada Twojemu sprzętowi – np. OPENMV4 dla OpenMV Cam H7, OPENMV4P dla H7 Plus, OPENMV_N6 dla N6.

14.1.1.2.1.2. Wynik kompilacji

Wszystko dla danej płytki trafia do build/<TARGET>/bin/. Dla TARGET=OPENMV4 jest to build/OPENMV4/bin/, zawierający:

Plik	Co to jest
firmware.bin	Plik binarny oprogramowania układowego – wgrywany przez OpenMV IDE Tools -> Load Custom Firmware oraz przez dfu-util
firmware.elf	Oprogramowanie układowe z symbolami debugowania – plik, który wskazujesz debuggerowi
bootloader.bin / .elf	Bootloader (tylko na płytkach z włączonym bootloaderem)
openmv.bin	Połączony obraz bootloader + oprogramowanie układowe
romfs<n>.img	Obraz systemu plików tylko do odczytu ROM wgrywany obok oprogramowania układowego

Alif AE3 jest dwurdzeniowy, więc produkuje firmware_M55_HP.elf / firmware_M55_HP.bin (rdzeń o wysokiej wydajności) oraz osobno firmware_M55_HE.elf / firmware_M55_HE.bin (rdzeń o wysokiej efektywności), a także obraz spisu treści (TOC), który informuje boot ROM, gdzie znajduje się obraz każdego rdzenia.

14.1.1.2.1.3. Czyszczenie i ponowne budowanie

Kompilacje są izolowane dla każdej płytki w build/<TARGET>/. Aby wyczyścić kompilację jednej płytki:

make TARGET=<TARGET> clean

Nie ma celu distclean; clean zawsze wymaga TARGET. mpy-cross jest współdzielony między płytkami – jeśli aktualizujesz MicroPython, przebuduj go również:

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

Aby zaraportować zużycie pamięci flash/RAM przez kompilację:

make TARGET=<TARGET> size

14.1.1.2.1.4. Budowanie w Dockerze (bez łańcucha narzędzi na hoście)

Jeśli wolisz niczego nie instalować na hoście (lub jesteś na platformie bez natywnej kompilacji), skorzystaj ze ścieżki Dockera:

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

Artefakty pojawiają się w openmv/docker/build/<TARGET>. Dla powtarzanych kompilacji istnieje przyrostowa ścieżka deweloperska, która montuje repozytorium pod tą samą bezwzględną ścieżką wewnątrz kontenera, co na hoście, dzięki czemu ścieżki źródłowe debuggera rozwiązują się bez remapowania:

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

Uruchom make clean-dev przy przełączaniu TARGET.

14.1.1.2.2. Opcje kompilacji

Zachowanie kompilacji sterowane jest zmiennymi przekazywanymi w wierszu poleceń make, na przykład:

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

Zmienne, których użyje deweloper oprogramowania układowego:

Zmienna	Domyślnie	Efekt
TARGET	(wymagane)	Płytka do zbudowania. Wybiera boards/<TARGET>/board_config.mk, który ustawia MCU, rdzeń, mapę pamięci, identyfikatory USB oraz włączone moduły.
DEBUG	0	DEBUG=1 kompiluje z -Og -ggdb3 (zoptymalizowane pod debugowanie, pełne informacje debugowania GDB) i wyłącza kompresję tekstu ROM MicroPython – to kompilacja, którą debugujesz. DEBUG=0 kompiluje z -O2 -DNDEBUG (mniejsza, szybsza, asercje wyłączone) i jest kompilacją wydania.
V	0	V=1 wypisuje każde polecenie kompilatora/linkera zamiast krótkiego podsumowania CC file.c. Użyj go, aby zobaczyć dokładne flagi lub zdiagnozować problemy z kompilacją.
DEBUG_PRINTF	0	DEBUG_PRINTF=1 definiuje OMV_DEBUG_PRINTF, włączając niskopoziomowe wyjście debugowania printf w oprogramowaniu układowym (w parze z SWO/RTT, zobacz Debugowanie oprogramowania układowego).
PROFILE_ENABLE	0	PROFILE_ENABLE=1 buduje z instrumentacją wywołań funkcji (-finstrument-functions, -DOMV_PROFILER_ENABLE=1), dzięki czemu możesz profilować, gdzie spędzany jest czas. PROFILE_HASH=<N> ustawia rozmiar tablicy mieszającej profilera (potęga dwójki; domyślnie 256), a PROFILE_IRQ=1 profiluje również kod działający w kontekście przerwania.
STACK_PROTECTOR	0	STACK_PROTECTOR=1 dodaje -fstack-protector-all – kanarki stosu, które wykrywają przepełnienia buforów na stosie. Przydatne przy tropieniu uszkodzeń pamięci.
DEBUGGER	JLINK	Którego debuggera używają cele make debug / make deploy. JLINK jest domyślny; NONE wyłącza cel debug.

Informacja

Istnieje wiele innych zmiennych (sterowniki kamer/sensorów, stosy bezprzewodowe, backendy ML, stos USB, bezpieczny rozruch itd.), ale są one ustawiane per płytka w boards/<TARGET>/board_config.mk i normalnie nie nadpisuje się ich w wierszu poleceń. Ich zmiana to dostosowywanie płytki, a nie normalna kompilacja deweloperska – zobacz docs/boards.md w repozytorium oprogramowania układowego.

W codziennej pracy jedyne opcje, których potrzebujesz, to TARGET (zawsze), DEBUG=1 (gdy zamierzasz debugować, zobacz Debugowanie oprogramowania układowego) oraz sporadycznie V=1.