14.1.1.1. Configurazione dell’ambiente di sviluppo

Sull’host servono tre cose prima di poter compilare: un editor (si consiglia VS Code perché il debugger vi si integra), una shell in stile Linux (WSL su Windows, nativa su Linux/macOS) e il repository OpenMV con l’SDK fissato estratto.

14.1.1.1.1. VS Code

Qualsiasi editor va bene per lo sviluppo del firmware – la build è semplicemente make, e anche il debugger su hardware si esegue dalla riga di comando. Visual Studio Code è semplicemente il percorso più facile: la configurazione di Debug del firmware si integra con la sua estensione Cortex-Debug, quindi con VS Code installato il resto di queste pagine funziona senza configurazioni aggiuntive, sia per compilare che per fare debug.

14.1.1.1.1.1. Installazione di VS Code

  • Windows – scarica l’installer da code.visualstudio.com ed eseguilo. Installa VS Code su Windows, non all’interno di WSL; si integra con WSL tramite l’estensione WSL, eseguendo la sua interfaccia su Windows mentre il compilatore, i file e il debugger risiedono in Linux.

  • macOS – scarica lo .zip da code.visualstudio.com, decomprimilo e trascina Visual Studio Code.app in /Applications. Oppure brew install --cask visual-studio-code.

  • Linux – installa il .deb / .rpm da code.visualstudio.com (ad es. sudo apt install ./code_*.deb), oppure usa lo Snap/Flatpak della distribuzione.

Estensioni da installare (dal pannello Estensioni, Ctrl+Shift+X):

  • C/C++ (ms-vscode.cpptools) – navigazione del codice sorgente C e IntelliSense.

  • Cortex-Debug (marus25.cortex-debug) – debug on-chip tramite GDB e un server J-Link / OpenOCD. Richiesta per Debug del firmware.

  • WSL (ms-vscode-remote.remote-wsl) – solo Windows. Consente a VS Code di aprire una cartella all’interno della tua distribuzione WSL così che editor, terminale, IntelliSense e Cortex-Debug operino tutti in Linux. Installa le estensioni C/C++ e Cortex-Debug nell’host WSL una volta connesso (VS Code lo richiede).

14.1.1.1.2. Shell dell’host

Serve un ambiente Linux (x86-64) o macOS (arm64) con git e alcuni strumenti di base. Scegli la sezione per il tuo sistema operativo.

14.1.1.1.2.1. Windows: installazione di WSL

WSL esegue un vero userland Ubuntu su Windows. Una volta installato, ogni istruzione successiva in questa guida è identica a Linux nativo.

  1. Apri PowerShell come Amministratore (clic destro su Start -> Terminale (Admin)).

  2. Installa WSL con la distribuzione Ubuntu predefinita:

    wsl --install

    Questo abilita le funzionalità Windows richieste, installa il kernel WSL 2 e installa Ubuntu. Riavvia se richiesto.

  3. Dopo il riavvio, Ubuntu si avvia e ti chiede di creare un nome utente e una password UNIX. Questo account è indipendente dal tuo account Windows.

  4. Aggiorna la distribuzione:

    sudo apt update && sudo apt upgrade -y

  5. Verifica di essere su WSL 2 (richiesto – WSL 1 non è supportato per questo workflow). In PowerShell:

    wsl --list --verbose

    La colonna VERSION deve indicare 2. Se indica 1, convertila:

    wsl --set-version Ubuntu 2

Suggerimento

Lavora all’interno del filesystem Linux (~/ in WSL), non sotto /mnt/c/. Compilare sull’unità montata di Windows è notevolmente più lento e può causare problemi di permessi sui file e di fine riga. Clona il repository nella tua home directory WSL.

Per aprire il progetto in seguito: avvia Ubuntu dal menu Start per una shell, oppure da VS Code su Windows premi Ctrl+Shift+P -> WSL: Connect to WSL, quindi File -> Open Folder e seleziona il repo clonato nel filesystem Linux.

14.1.1.1.2.2. Prerequisiti Linux / WSL

L’SDK fornisce il compilatore, quindi servono solo pochi pacchetti sull’host:

sudo apt-get update
sudo apt-get install git build-essential

14.1.1.1.2.3. Prerequisiti macOS

La compilazione nativa è supportata solo su macOS con Apple-silicon (arm64). Usando Homebrew

brew install bash make coreutils

(I Mac Intel non sono un host di build nativo supportato – usa la build Docker da Compilazione del firmware o una VM Linux.)

14.1.1.1.3. Ottenere il sorgente

Clona il repository con tutti i submodule (MicroPython, CMSIS, driver dei fornitori, ecc.):

git clone --recursive https://github.com/openmv/openmv.git
cd openmv

Un clone ricorsivo completo è di grandi dimensioni. Per un clone shallow più veloce:

git clone --depth=1 https://github.com/openmv/openmv.git
cd openmv
git submodule update --init --depth=1 --no-single-branch
git -C lib/micropython/ submodule update --init --depth=1

Nota

Quando compili una scheda specifica puoi invece lasciare che make scarichi solo i submodule di quella scheda:

make TARGET=<board> submodules

Il comando git submodule update esplicito mostrato sopra copre già tutto, quindi questo passaggio è facoltativo.

14.1.1.1.4. Installazione dell’SDK OpenMV

Dalla radice del repository, esegui l’installazione una tantum dell’SDK:

make sdk

Questo scarica openmv-sdk-<version>-<os>-<arch>.tar.xz da download.openmv.io, ne verifica il checksum SHA-256 e lo estrae in ~/openmv-sdk-<version>/ (la versione è fissata dal file SDK_VERSION del repo). È idempotente – rieseguirlo non fa nulla se la versione corretta è già installata, e la build normale si interrompe con «OpenMV SDK not found. Run “make sdk” to install it.» se manca o è la versione sbagliata.

L’SDK include tutto ciò di cui la build e il debugger hanno bisogno, aggiunto automaticamente al PATH dal Makefile:

Componente

Scopo

Toolchain ARM GNU (arm-none-eabi-gcc 14.3)

Compilatore, linker, arm-none-eabi-gdb per il debug

LLVM/clang

Usato per oggetti selezionati su alcune porte

CMake, GNU Make

Orchestrazione della build per le librerie dei fornitori

Python (rilocabile)

Script di build, helper mpy-cross, firma, strumenti per i modelli

STM32CubeProgrammer (STM32_Programmer_CLI)

Flashing SWD e il flusso di recupero dell’STM32N6

ST Edge AI

Compilatore di reti neurali per la NPU dell’STM32N6

dfu-util

Flashing USB DFU

gdbrunner

Il lanciatore del server GDB del target make debug (il software Segger J-Link che pilota è un’installazione separata)

Avvertimento

L’OpenMV N6 e l’OpenMV AE3 utilizzano core Cortex-M55 e richiedono GCC 14.3 o più recente. La build lo impone per quei target e si interrompe con un errore «Upgrade to GCC 14.3+ for proper CM55 support» se viene trovato un arm-none-eabi-gcc più vecchio prima di quello dell’SDK nel PATH. La toolchain dell’SDK inclusa soddisfa già questo requisito; l’errore indica che una toolchain diversa e più vecchia la sta oscurando.