14.1.1.1. Einrichten der Entwicklungsumgebung¶

Sie benötigen drei Dinge auf dem Host, bevor Sie kompilieren können: einen Editor (VS Code wird empfohlen, weil sich der Debugger darin einklinkt), eine Linux-artige Shell (WSL unter Windows, nativ unter Linux/macOS) und das OpenMV-Repository mit dem entpackten, fest verankerten SDK.

14.1.1.1.1. VS Code¶

Für die Firmware-Entwicklung funktioniert jeder Editor – der Build ist einfach make, und der Hardware-Debugger läuft ebenfalls von der Kommandozeile aus. Visual Studio Code ist schlicht der einfachste Weg: Das Debugging der Firmware-Setup klinkt sich in dessen Cortex-Debug-Erweiterung ein, sodass mit installiertem VS Code der Rest dieser Seiten sofort funktioniert, sowohl beim Bauen als auch beim Debuggen.

14.1.1.1.1.1. Installieren von VS Code¶

Windows – laden Sie das Installationsprogramm von code.visualstudio.com herunter und führen Sie es aus. Installieren Sie VS Code unter Windows, nicht innerhalb von WSL; es integriert sich über die WSL-Erweiterung mit WSL und führt seine Benutzeroberfläche unter Windows aus, während Compiler, Dateien und Debugger in Linux leben.
macOS – laden Sie die .zip von code.visualstudio.com herunter, entpacken Sie sie und ziehen Sie Visual Studio Code.app nach /Applications. Oder brew install --cask visual-studio-code.
Linux – installieren Sie die .deb / .rpm von code.visualstudio.com (z. B. sudo apt install ./code_*.deb) oder verwenden Sie das Snap/Flatpak der Distribution.

Zu installierende Erweiterungen (über das Erweiterungen-Panel, Ctrl+Shift+X):

C/C++ (ms-vscode.cpptools) – Navigation im C-Quellcode und IntelliSense.
Cortex-Debug (marus25.cortex-debug) – On-Chip-Debugging über GDB und einen J-Link-/OpenOCD-Server. Erforderlich für Debugging der Firmware.
WSL (ms-vscode-remote.remote-wsl) – nur Windows. Ermöglicht es VS Code, einen Ordner innerhalb Ihrer WSL-Distribution zu öffnen, sodass Editor, Terminal, IntelliSense und Cortex-Debug allesamt in Linux arbeiten. Installieren Sie die Erweiterungen C/C++ und Cortex-Debug nach dem Verbinden einmalig in den WSL-Host (VS Code fordert Sie dazu auf).

14.1.1.1.2. Host-Shell¶

Sie benötigen eine Linux- (x86-64) oder macOS- (arm64) Umgebung mit git und einigen grundlegenden Tools. Wählen Sie den Abschnitt für Ihr Betriebssystem.

14.1.1.1.2.1. Windows: WSL installieren¶

WSL führt eine echte Ubuntu-Userland-Umgebung unter Windows aus. Nach der Installation ist jede weitere Anweisung in diesem Leitfaden identisch mit nativem Linux.

Öffnen Sie PowerShell als Administrator (Rechtsklick auf Start -> Terminal (Administrator)).
Installieren Sie WSL mit der Standard-Ubuntu-Distribution:
```
wsl --install
```
Dies aktiviert die erforderlichen Windows-Features, installiert den WSL-2-Kernel und installiert Ubuntu. Starten Sie neu, wenn Sie dazu aufgefordert werden.
Nach dem Neustart wird Ubuntu gestartet und fordert Sie auf, einen UNIX-Benutzernamen und ein Passwort zu erstellen. Dieses Konto ist unabhängig von Ihrem Windows-Konto.
Aktualisieren Sie die Distribution:
```
sudo apt update && sudo apt upgrade -y
```
Bestätigen Sie, dass Sie WSL 2 verwenden (erforderlich – WSL 1 wird für diesen Workflow nicht unterstützt). In PowerShell:
```
wsl --list --verbose
```
In der Spalte VERSION muss 2 stehen. Steht dort 1, konvertieren Sie es:
```
wsl --set-version Ubuntu 2
```

Tipp

Arbeiten Sie innerhalb des Linux-Dateisystems (~/ in WSL), nicht unter /mnt/c/. Das Bauen auf dem unter Windows eingehängten Laufwerk ist drastisch langsamer und kann Probleme mit Dateiberechtigungen und Zeilenenden verursachen. Klonen Sie das Repository in Ihr WSL-Home-Verzeichnis.

So öffnen Sie das Projekt später: Starten Sie Ubuntu aus dem Startmenü für eine Shell, oder drücken Sie in VS Code unter Windows Ctrl+Shift+P -> WSL: Connect to WSL, dann File -> Open Folder und wählen Sie das geklonte Repo im Linux-Dateisystem.

14.1.1.1.2.2. Voraussetzungen für Linux / WSL¶

Das SDK liefert den Compiler, daher werden nur eine Handvoll Host-Pakete benötigt:

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

14.1.1.1.2.3. Voraussetzungen für macOS¶

Natives Bauen wird nur unter macOS mit Apple-Silicon (arm64) unterstützt. Mit Homebrew:

brew install bash make coreutils

(Intel-Macs sind kein unterstützter nativer Build-Host – verwenden Sie den Docker-Build aus Die Firmware bauen oder eine Linux-VM.)

14.1.1.1.3. Den Quellcode beschaffen¶

Klonen Sie das Repository mit allen Submodulen (MicroPython, CMSIS, Vendor-Treiber usw.):

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

Ein vollständiger rekursiver Klon ist groß. Für einen schnelleren, flachen Klon:

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

Bemerkung

Beim Bauen eines bestimmten Boards können Sie stattdessen make nur die Submodule dieses Boards holen lassen:

make TARGET=<board> submodules

Das oben gezeigte explizite git submodule update deckt bereits alles ab, daher ist dieser Schritt optional.

14.1.1.1.4. Installieren des OpenMV SDK¶

Führen Sie aus dem Repository-Stammverzeichnis die einmalige SDK-Installation aus:

make sdk

Dies lädt openmv-sdk-<version>-<os>-<arch>.tar.xz von download.openmv.io herunter, überprüft dessen SHA-256-Prüfsumme und entpackt es nach ~/openmv-sdk-<version>/ (die Version wird durch die Datei SDK_VERSION des Repos fest vorgegeben). Es ist idempotent – ein erneutes Ausführen bewirkt nichts, wenn die korrekte Version bereits installiert ist, und der reguläre Build bricht mit „OpenMV SDK not found. Run ‚make sdk‘ to install it.“ ab, wenn es fehlt oder die falsche Version vorliegt.

Das SDK bündelt alles, was Build und Debugger benötigen, und alles wird vom Makefile automatisch zum PATH hinzugefügt:

Komponente	Zweck
ARM-GNU-Toolchain (`arm-none-eabi-gcc` 14.3)	Compiler, Linker, `arm-none-eabi-gdb` zum Debuggen
LLVM/clang	Wird für ausgewählte Objekte auf einigen Ports verwendet
CMake, GNU Make	Build-Orchestrierung für Vendor-Bibliotheken
Python (relocatable)	Build-Skripte, `mpy-cross`-Helfer, Signierung, Modell-Tools
STM32CubeProgrammer (`STM32_Programmer_CLI`)	SWD-Flashen und der STM32N6-Wiederherstellungsablauf
ST Edge AI	Compiler für neuronale Netze für die STM32N6-NPU
`dfu-util`	USB-DFU-Flashen
`gdbrunner`	Der GDB-Server-Starter des `make debug`-Ziels (die von ihm gesteuerte Segger-J-Link-Software ist eine separate Installation)

Warnung

Der OpenMV N6 und der OpenMV AE3 verwenden Cortex-M55-Kerne und erfordern GCC 14.3 oder neuer. Der Build erzwingt dies für diese Ziele und bricht mit dem Fehler „Upgrade to GCC 14.3+ for proper CM55 support“ ab, wenn ein älteres arm-none-eabi-gcc im PATH vor dem des SDK gefunden wird. Die mitgelieferte SDK-Toolchain erfüllt dies bereits; der Fehler bedeutet, dass eine andere, ältere Toolchain sie verdeckt.