14.1.1.2. Construirea firmware-ului¶

Cu mediul din Configurarea mediului de dezvoltare pregătit, construirea unei imagini de firmware înseamnă două comenzi make plus o selecție TARGET.

14.1.1.2.1. Compilare¶

Mai întâi construiește mpy-cross, instrumentul gazdă care compilează modulele .py înghețate în bytecode (fă acest lucru o dată și din nou ori de câte ori actualizezi MicroPython):

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

Apoi construiește firmware-ul pentru o placă, unde <TARGET> este unul dintre numele din tabelul de mai jos:

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

-j$(nproc) construiește în paralel pe toate nucleele CPU (pe macOS folosește -j$(sysctl -n hw.ncpu)). TARGET este obligatoriu – make fără țintă se oprește cu „Invalid or no TARGET specified”.

O primă construire completă, de la cap la coadă:

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

14.1.1.2.1.1. Plăci suportate¶

Valorile TARGET sunt numele directoarelor de sub boards/. Camerele și siliciul lor:

Cameră	`TARGET`	MCU	Port	Nucleu
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 (M55 dual)	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+

Construiește exact TARGET-ul potrivit hardware-ului tău – de ex. OPENMV4 pentru OpenMV Cam H7, OPENMV4P pentru H7 Plus, OPENMV_N6 pentru N6.

14.1.1.2.1.2. Ieșirea construirii¶

Tot ce ține de o placă ajunge în build/<TARGET>/bin/. Pentru TARGET=OPENMV4 acela este build/OPENMV4/bin/, conținând:

Fișier	Ce este
`firmware.bin`	Binarul de firmware – flash-uit de OpenMV IDE prin Tools -> Load Custom Firmware și de `dfu-util`
`firmware.elf`	Firmware cu simboluri de depanare – fișierul pe care îl indici depanatorului
`bootloader.bin` / `.elf`	Bootloader-ul (doar pe plăcile cu un bootloader activat)
`openmv.bin`	Imagine combinată bootloader + firmware
`romfs<n>.img`	Imaginea sistemului de fișiere ROM doar-citire, flash-uită alături de firmware

Alif AE3 este cu nucleu dublu, așa că produce firmware_M55_HP.elf / firmware_M55_HP.bin (nucleul de înaltă performanță) și un firmware_M55_HE.elf / firmware_M55_HE.bin separat (nucleul de înaltă eficiență), plus o imagine de tabel de cuprins (TOC) care îi spune boot ROM-ului unde se află imaginea fiecărui nucleu.

14.1.1.2.1.3. Curățare și reconstruire¶

Construirile sunt izolate per placă sub build/<TARGET>/. Pentru a șterge construirea unei singure plăci:

make TARGET=<TARGET> clean

Nu există distclean; clean are întotdeauna nevoie de un TARGET. mpy-cross este partajat între plăci – dacă actualizezi MicroPython, reconstruiește-l și pe el:

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

Pentru a raporta utilizarea flash/RAM a unei construiri:

make TARGET=<TARGET> size

14.1.1.2.1.4. Construire în Docker (fără lanț de instrumente pe gazdă)¶

Dacă preferi să nu instalezi nimic pe gazdă (sau ești pe o platformă fără o construire nativă), folosește calea Docker:

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

Artefactele apar în openmv/docker/build/<TARGET>. Pentru construiri repetate există o cale de dezvoltare incrementală care montează depozitul la aceeași cale absolută în interiorul containerului ca pe gazdă, astfel încât căile sursă ale depanatorului se rezolvă fără remapare:

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

Rulează make clean-dev când schimbi TARGET.

14.1.1.2.2. Opțiuni de construire¶

Comportamentul construirii este controlat de variabile transmise în linia de comandă make, de exemplu:

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

Variabilele pe care le va folosi un dezvoltator de firmware:

Variabilă	Implicit	Efect
`TARGET`	(obligatoriu)	Placa de construit. Selectează `boards/<TARGET>/board_config.mk`, care setează MCU-ul, nucleul, harta de memorie, ID-urile USB și modulele activate.
`DEBUG`	`0`	`DEBUG=1` compilează cu `-Og -ggdb3` (optimizat pentru depanare, informații complete de depanare GDB) și dezactivează compresia textului ROM al MicroPython – aceasta este construirea pe care o depanezi. `DEBUG=0` compilează cu `-O2 -DNDEBUG` (mai mică, mai rapidă, cu aserțiuni dezactivate) și este construirea de lansare.
`V`	`0`	`V=1` afișează fiecare comandă de compilator/linker în loc de rezumatul scurt `CC file.c`. Folosește-o pentru a vedea flag-urile exacte sau a diagnostica problemele de construire.
`DEBUG_PRINTF`	`0`	`DEBUG_PRINTF=1` definește `OMV_DEBUG_PRINTF`, activând ieșirea de depanare `printf` de nivel scăzut în firmware (combină cu SWO/RTT, vezi Depanarea firmware-ului).
`PROFILE_ENABLE`	`0`	`PROFILE_ENABLE=1` construiește cu instrumentarea apelurilor de funcții (`-finstrument-functions`, `-DOMV_PROFILER_ENABLE=1`) astfel încât să poți profila unde se petrece timpul. `PROFILE_HASH=<N>` setează dimensiunea tabelei de dispersie a profilatorului (putere a lui doi; implicit 256), iar `PROFILE_IRQ=1` profilează de asemenea codul care rulează în context de întrerupere.
`STACK_PROTECTOR`	`0`	`STACK_PROTECTOR=1` adaugă `-fstack-protector-all` – canari de stivă care interceptează depășirile tampoanelor de stivă. Util când urmărești coruperea memoriei.
`DEBUGGER`	`JLINK`	Care depanator folosesc țintele `make debug` / `make deploy`. `JLINK` este implicit; `NONE` dezactivează ținta `debug`.

Notă

Există multe alte variabile (drivere de cameră/senzor, stive wireless, backend-uri ML, stiva USB, boot securizat etc.), dar acestea sunt setate per placă în boards/<TARGET>/board_config.mk și în mod normal nu sunt suprascrise în linia de comandă. Modificarea lor este personalizare a plăcii, nu o construire normală de dezvoltator – vezi docs/boards.md în depozitul firmware-ului.

Pentru munca de zi cu zi, singurele opțiuni de care ai nevoie sunt TARGET (întotdeauna), DEBUG=1 (ori de câte ori intenționezi să depanezi, vezi Depanarea firmware-ului) și ocazional V=1.