14.1.1.2. Compiler le micrologiciel

Avec l’environnement de Configuration de l’environnement de développement en place, compiler une image de micrologiciel se résume à deux commandes make plus la sélection d’une TARGET.

14.1.1.2.1. Compilation

Compilez d’abord mpy-cross, l’outil hôte qui compile les modules .py figés en bytecode (faites-le une fois, puis de nouveau chaque fois que vous mettez à jour MicroPython)

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

Compilez ensuite le micrologiciel pour une carte, où <TARGET> est l’un des noms du tableau ci-dessous

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

-j$(nproc) compile en parallèle sur tous les cœurs CPU (sur macOS, utilisez -j$(sysctl -n hw.ncpu)). TARGET est obligatoire – make sans cible s’interrompt avec « Invalid or no TARGET specified ».

Une première compilation complète, de bout en bout

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

14.1.1.2.1.1. Cartes prises en charge

Les valeurs de TARGET sont les noms de répertoires sous boards/. Les caméras et leur silicium :

Caméra	TARGET	MCU	Port	Cœur
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 (double 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+

Compilez la TARGET exacte correspondant à votre matériel – par exemple OPENMV4 pour l’OpenMV Cam H7, OPENMV4P pour la H7 Plus, OPENMV_N6 pour la N6.

14.1.1.2.1.2. Résultat de la compilation

Tout ce qui concerne une carte atterrit dans build/<TARGET>/bin/. Pour TARGET=OPENMV4, c’est build/OPENMV4/bin/, qui contient :

Fichier	Ce dont il s’agit
firmware.bin	Binaire du micrologiciel – flashé par OpenMV IDE Tools -> Load Custom Firmware et par dfu-util
firmware.elf	Micrologiciel avec symboles de débogage – le fichier que vous indiquez au débogueur
bootloader.bin / .elf	Le programme d’amorçage (uniquement sur les cartes dotées d’un programme d’amorçage activé)
openmv.bin	Image combinée programme d’amorçage + micrologiciel
romfs<n>.img	Image du système de fichiers ROM en lecture seule, flashée en même temps que le micrologiciel

L’Alif AE3 est à double cœur, il produit donc firmware_M55_HP.elf / firmware_M55_HP.bin (le cœur haute performance) et un firmware_M55_HE.elf / firmware_M55_HE.bin distinct (le cœur haute efficacité) ainsi qu’une image de table des matières (TOC) qui indique à la ROM d’amorçage où se trouve l’image de chaque cœur.

14.1.1.2.1.3. Nettoyage et recompilation

Les compilations sont isolées par carte sous build/<TARGET>/. Pour effacer la compilation d’une carte

make TARGET=<TARGET> clean

Il n’y a pas de distclean ; clean a toujours besoin d’une TARGET. mpy-cross est partagé entre les cartes – si vous mettez à jour MicroPython, recompilez-le aussi

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

Pour rapporter l’utilisation de la mémoire flash/RAM d’une compilation

make TARGET=<TARGET> size

14.1.1.2.1.4. Compiler dans Docker (sans chaîne d’outils hôte)

Si vous préférez ne rien installer sur l’hôte (ou si vous êtes sur une plateforme sans compilation native), utilisez la voie Docker

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

Les artefacts apparaissent dans openmv/docker/build/<TARGET>. Pour des compilations répétées, il existe une voie de développement incrémentale qui monte le dépôt au même chemin absolu à l’intérieur du conteneur que sur l’hôte, de sorte que les chemins source du débogueur se résolvent sans remappage

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

Exécutez make clean-dev lors du changement de TARGET.

14.1.1.2.2. Options de compilation

Le comportement de la compilation est contrôlé par des variables passées sur la ligne de commande make, par exemple

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

Les variables qu’un développeur de micrologiciel utilisera :

Variable	Valeur par défaut	Effet
TARGET	(requis)	La carte à compiler. Sélectionne boards/<TARGET>/board_config.mk, qui définit le MCU, le cœur, le plan mémoire, les identifiants USB et les modules activés.
DEBUG	0	DEBUG=1 compile avec -Og -ggdb3 (optimisé pour le débogage, informations de débogage GDB complètes) et désactive la compression du texte ROM de MicroPython – c’est la compilation que vous déboguez. DEBUG=0 compile avec -O2 -DNDEBUG (plus petit, plus rapide, assertions désactivées) et constitue la compilation de version.
V	0	V=1 affiche chaque commande de compilateur/éditeur de liens au lieu du résumé court CC file.c. Utilisez-la pour voir les options exactes ou diagnostiquer des problèmes de compilation.
DEBUG_PRINTF	0	DEBUG_PRINTF=1 définit OMV_DEBUG_PRINTF, activant la sortie de débogage printf de bas niveau dans le micrologiciel (à associer à SWO/RTT, voir Débogage du micrologiciel).
PROFILE_ENABLE	0	PROFILE_ENABLE=1 compile avec l’instrumentation des appels de fonction (-finstrument-functions, -DOMV_PROFILER_ENABLE=1) afin de pouvoir profiler où le temps est passé. PROFILE_HASH=<N> définit la taille de la table de hachage du profileur (puissance de deux ; 256 par défaut) et PROFILE_IRQ=1 profile également le code s’exécutant en contexte d’interruption.
STACK_PROTECTOR	0	STACK_PROTECTOR=1 ajoute -fstack-protector-all – des canaris de pile qui interceptent les dépassements de tampon de pile. Utile lors de la recherche de corruptions de mémoire.
DEBUGGER	JLINK	Le débogueur qu’utilisent les cibles make debug / make deploy. JLINK est la valeur par défaut ; NONE désactive la cible debug.

Note

Bien d’autres variables existent (pilotes de caméra/capteur, piles sans fil, backends ML, pile USB, démarrage sécurisé, etc.), mais celles-ci sont définies par carte dans boards/<TARGET>/board_config.mk et ne sont normalement pas surchargées sur la ligne de commande. Les modifier relève de la personnalisation de carte, pas d’une compilation de développeur ordinaire – voir docs/boards.md dans le dépôt du micrologiciel.

Pour le travail quotidien, les seules options dont vous avez besoin sont TARGET (toujours), DEBUG=1 (chaque fois que vous comptez déboguer, voir Débogage du micrologiciel), et occasionnellement V=1.