14.1.1.2. Compilar o firmware

Com o ambiente de Configurar o ambiente de desenvolvimento configurado, compilar uma imagem de firmware são dois comandos make mais uma seleção de TARGET.

14.1.1.2.1. Compilação

Primeiro compile o mpy-cross, a ferramenta do anfitrião que compila os módulos .py congelados em bytecode (faça isto uma vez, e novamente sempre que atualizar o MicroPython):

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

De seguida compile o firmware para uma placa, onde <TARGET> é um dos nomes da tabela abaixo:

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

-j$(nproc) compila em paralelo em todos os núcleos de CPU (em macOS use -j$(sysctl -n hw.ncpu)). TARGET é obrigatório – make sem alvo aborta com «Invalid or no TARGET specified».

Uma primeira compilação completa, do início ao fim:

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

14.1.1.2.1.1. Placas suportadas

Os valores de TARGET são os nomes de diretório em boards/. As câmaras e o seu silício:

Câmara	TARGET	MCU	Porta	Núcleo
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+

Compile o TARGET exato para o seu hardware – por exemplo, OPENMV4 para a OpenMV Cam H7, OPENMV4P para a H7 Plus, OPENMV_N6 para a N6.

14.1.1.2.1.2. Resultado da compilação

Tudo para uma placa fica em build/<TARGET>/bin/. Para TARGET=OPENMV4 isso é build/OPENMV4/bin/, contendo:

Ficheiro	O que é
firmware.bin	Binário do firmware – carregado pelo OpenMV IDE em Tools -> Load Custom Firmware e pelo dfu-util
firmware.elf	Firmware com símbolos de depuração – o ficheiro que aponta ao depurador
bootloader.bin / .elf	O bootloader (apenas em placas com bootloader ativado)
openmv.bin	Imagem combinada de bootloader + firmware
romfs<n>.img	Imagem do sistema de ficheiros ROM só de leitura carregada juntamente com o firmware

O Alif AE3 tem dois núcleos, pelo que produz firmware_M55_HP.elf / firmware_M55_HP.bin (o núcleo de alto desempenho) e um firmware_M55_HE.elf / firmware_M55_HE.bin separado (o núcleo de alta eficiência), mais uma imagem de tabela de conteúdos (TOC) que indica à ROM de arranque onde reside a imagem de cada núcleo.

14.1.1.2.1.3. Limpeza e recompilação

As compilações são isoladas por placa em build/<TARGET>/. Para apagar a compilação de uma placa:

make TARGET=<TARGET> clean

Não existe distclean; clean necessita sempre de um TARGET. O mpy-cross é partilhado entre placas – se atualizar o MicroPython, compile-o novamente também:

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

Para reportar o uso de flash/RAM de uma compilação:

make TARGET=<TARGET> size

14.1.1.2.1.4. Compilar em Docker (sem cadeia de ferramentas no anfitrião)

Se preferir não instalar nada no anfitrião (ou estiver numa plataforma sem compilação nativa), use o caminho Docker:

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

Os artefactos aparecem em openmv/docker/build/<TARGET>. Para compilações repetidas existe um caminho de desenvolvimento incremental que monta o repositório no mesmo caminho absoluto dentro do contentor que no anfitrião, para que os caminhos de origem do depurador se resolvam sem remapeamento:

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

Execute make clean-dev ao mudar o TARGET.

14.1.1.2.2. Opções de compilação

O comportamento da compilação é controlado por variáveis passadas na linha de comando do make, por exemplo:

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

As variáveis que um programador de firmware irá usar:

Variável	Predefinição	Efeito
TARGET	(obrigatório)	A placa a compilar. Seleciona boards/<TARGET>/board_config.mk, que define o MCU, núcleo, mapa de memória, IDs USB e módulos ativados.
DEBUG	0	DEBUG=1 compila com -Og -ggdb3 (otimizado para depuração, informação de depuração GDB completa) e desativa a compressão de texto ROM do MicroPython – esta é a compilação que se depura. DEBUG=0 compila com -O2 -DNDEBUG (mais pequeno, mais rápido, asserções desativadas) e é a compilação de lançamento.
V	0	V=1 imprime cada comando do compilador/ligador em vez do resumo curto CC file.c. Use-o para ver os flags exatos ou diagnosticar problemas de compilação.
DEBUG_PRINTF	0	DEBUG_PRINTF=1 define OMV_DEBUG_PRINTF, ativando a saída de depuração printf de baixo nível no firmware (use em conjunto com SWO/RTT, consulte Depuração do firmware).
PROFILE_ENABLE	0	PROFILE_ENABLE=1 compila com instrumentação de chamadas de função (-finstrument-functions, -DOMV_PROFILER_ENABLE=1) para que possa fazer o perfil de onde é gasto o tempo. PROFILE_HASH=<N> define o tamanho da tabela de hash do profiler (potência de dois; predefinição 256) e PROFILE_IRQ=1 também faz o perfil do código em contexto de interrupção.
STACK_PROTECTOR	0	STACK_PROTECTOR=1 adiciona -fstack-protector-all – canários de pilha que detetam estouros de buffer de pilha. Útil para rastrear corrupção de memória.
DEBUGGER	JLINK	O depurador que os alvos make debug / make deploy usam. JLINK é a predefinição; NONE desativa o alvo debug.

Nota

Existem muitas mais variáveis (controladores de câmara/sensor, pilhas de comunicação sem fios, backends de ML, pilha USB, arranque seguro, etc.), mas essas são definidas por placa em boards/<TARGET>/board_config.mk e normalmente não são substituídas na linha de comando. Alterá-las é personalização de placa, não uma compilação normal de programador – consulte docs/boards.md no repositório do firmware.

Para o trabalho diário, as únicas opções necessárias são TARGET (sempre), DEBUG=1 (sempre que pretender depurar, consulte Depuração do firmware), e ocasionalmente V=1.