14.1.1.2. A firmware felépítése¶

Ha a A fejlesztői környezet beállítása szerinti környezet a helyén van, egy firmware-kép felépítése két make parancs plusz egy TARGET kiválasztása.

14.1.1.2.1. Fordítás¶

Először építsd fel az mpy-cross-t, azt a gazdagépi eszközt, amely a befagyasztott .py modulokat bytecode-dá fordítja (ezt egyszer csináld meg, majd újra, valahányszor frissíted a MicroPythont):

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

Ezután építsd fel a firmware-t egy lapra, ahol a <TARGET> az alábbi táblázatban szereplő nevek egyike:

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

A -j$(nproc) az összes CPU-magon párhuzamosan épít (macOS-en használd a -j$(sysctl -n hw.ncpu)-t). A TARGET kötelező – a cél nélküli make „Invalid or no TARGET specified” hibával leáll.

Egy teljes első build, elejétől a végéig:

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

14.1.1.2.1.1. Támogatott lapok¶

A TARGET értékek a boards/ alatti könyvtárnevek. A kamerák és a szilíciumuk:

Kamera	`TARGET`	MCU	Port	Mag
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 (kettős 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+

A hardveredhez pontosan a megfelelő TARGET-et építsd fel – pl. OPENMV4 az OpenMV Cam H7-hez, OPENMV4P a H7 Plus-hoz, OPENMV_N6 az N6-hoz.

14.1.1.2.1.2. Build-kimenet¶

Egy lap minden eredménye a build/<TARGET>/bin/ könyvtárba kerül. A TARGET=OPENMV4 esetén ez a build/OPENMV4/bin/, amely a következőket tartalmazza:

Fájl	Mi ez
`firmware.bin`	Firmware bináris – az OpenMV IDE Tools -> Load Custom Firmware menüjével és a `dfu-util`-lal flashelve
`firmware.elf`	Firmware hibakeresési szimbólumokkal – az a fájl, amelyre a hibakeresőt irányítod
`bootloader.bin` / `.elf`	A rendszerbetöltő (csak az engedélyezett rendszerbetöltővel rendelkező lapokon)
`openmv.bin`	Kombinált rendszerbetöltő + firmware kép
`romfs<n>.img`	Csak olvasható ROM-fájlrendszer kép, a firmware mellé flashelve

Az Alif AE3 kétmagos, így firmware_M55_HP.elf / firmware_M55_HP.bin (a nagy teljesítményű mag) és egy külön firmware_M55_HE.elf / firmware_M55_HE.bin (a nagy hatékonyságú mag) fájlokat állít elő, plusz egy tartalomjegyzék (TOC) képet, amely megmondja a boot ROM-nak, hol található az egyes magok képe.

14.1.1.2.1.3. Tisztítás és újraépítés¶

A buildek laponként el vannak különítve a build/<TARGET>/ alatt. Egy lap buildjének törléséhez:

make TARGET=<TARGET> clean

Nincs distclean; a clean-hez mindig kell egy TARGET. Az mpy-cross megosztott a lapok között – ha frissíted a MicroPythont, építsd újra azt is:

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

Egy build flash/RAM-használatának jelentéséhez:

make TARGET=<TARGET> size

14.1.1.2.1.4. Építés Dockerben (gazdagépi eszközlánc nélkül)¶

Ha inkább nem szeretnél semmit telepíteni a gazdagépre (vagy egy natív build nélküli platformon vagy), használd a Docker-utat:

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

A termékek az openmv/docker/build/<TARGET> könyvtárban jelennek meg. Ismételt buildekhez van egy inkrementális fejlesztői út, amely a tárolót ugyanazon az abszolút úton csatolja fel a konténeren belül, mint a gazdagépen, így a hibakereső forrásútvonalai átleképezés nélkül feloldódnak:

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

Futtasd a make clean-dev-et a TARGET váltásakor.

14.1.1.2.2. Build-opciók¶

A build viselkedését a make parancssorán átadott változók vezérlik, például:

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

Azok a változók, amelyeket egy firmware-fejlesztő használni fog:

Változó	Alapértelmezés	Hatás
`TARGET`	(kötelező)	Az építendő lap. Kiválasztja a `boards/<TARGET>/board_config.mk`-t, amely beállítja az MCU-t, a magot, a memóriatérképet, az USB-azonosítókat és az engedélyezett modulokat.
`DEBUG`	`0`	A `DEBUG=1` az `-Og -ggdb3` kapcsolókkal fordít (hibakeresésre optimalizált, teljes GDB hibakeresési információ) és letiltja a MicroPython ROM-szöveg tömörítését – ez az a build, amelyet hibakeresel. A `DEBUG=0` az `-O2 -DNDEBUG` kapcsolókkal fordít (kisebb, gyorsabb, assertek kikapcsolva) és ez a kiadási build.
`V`	`0`	A `V=1` minden fordító-/linker-parancsot kiír a rövid `CC file.c` összefoglaló helyett. Használd a pontos kapcsolók megtekintéséhez vagy a build-problémák diagnosztizálásához.
`DEBUG_PRINTF`	`0`	A `DEBUG_PRINTF=1` definiálja az `OMV_DEBUG_PRINTF`-et, engedélyezve az alacsony szintű hibakeresési `printf` kimenetet a firmware-ben (párosítsd SWO/RTT-vel, lásd A firmware hibakeresése).
`PROFILE_ENABLE`	`0`	A `PROFILE_ENABLE=1` függvényhívás-műszerezéssel épít (`-finstrument-functions`, `-DOMV_PROFILER_ENABLE=1`), így profilozhatod, hol töltődik az idő. A `PROFILE_HASH=<N>` beállítja a profilozó hash-táblájának méretét (kettő hatványa; alapértelmezés 256), a `PROFILE_IRQ=1` pedig a megszakítási kontextusban futó kódot is profilozza.
`STACK_PROTECTOR`	`0`	A `STACK_PROTECTOR=1` hozzáadja az `-fstack-protector-all`-t – veremkanárik, amelyek elkapják a verempuffer túlcsordulásokat. Hasznos a memóriasérülés keresésekor.
`DEBUGGER`	`JLINK`	Melyik hibakeresőt használják a `make debug` / `make deploy` célok. A `JLINK` az alapértelmezés; a `NONE` letiltja a `debug` célt.

Megjegyzés

Sokkal több változó létezik (kamera-/érzékelő-illesztőprogramok, vezeték nélküli stackek, ML-háttérprogramok, USB-stack, biztonságos rendszerindítás stb.), de ezeket laponként állítják be a boards/<TARGET>/board_config.mk-ban, és normál esetben nem írják felül őket a parancssoron. Ezek módosítása lap-testreszabás, nem normál fejlesztői build – lásd a docs/boards.md-ot a firmware tárolóban.

A mindennapi munkához az egyetlen szükséges opciók a TARGET (mindig), a DEBUG=1 (valahányszor hibakeresni szándékozol, lásd A firmware hibakeresése) és alkalmanként a V=1.