In den letzten drei Artikeln haben wir die vom nanoFramework-Entwicklerteam zur Verfügung gestellte Embedded-Firmware angewendet. In der Praxis gibt es jedoch Situationen, in denen eine hemdsärmeligere Vorgehensweise wünschenswerter ist.

Im Allgemeinen gilt, dass die Qualität eines Cross-Plattform-Entwicklungssystems oder einer Hochsprache immer auch daran bemessen wird, wie kommod man sie um nicht implementierte Teile erweitern kann. Im Fall von Systemen wie dem nanoFramework gilt logischerweise, dass der bequemste Weg zum Erreichen dieser Gefechtsaufgabe die Erzeugung eines neuen Firmware-Images ist. Außerdem ist das der einzige Weg, um bisher nicht unterstützte oder nicht mit einem vorgefertigten Image ausgestattete Controller zur Ausführung von .NET-nanoFramework-basierten Payloads zu befähigen.

Eine Frage der Vorgehensweise

Die Embedded-Entwicklung ist unter anderem dafür berüchtigt, dass die Einrichtung der für die verschiedenen Controller notwendigen Toolchains arbeitsintensiv ausfällt. Im Fall von STM32 bekommt man es beispielsweise mit der STMCubeIDE zu tun, die ihrerseits Dutzende SDKs und andere Komponenten auf die Workstation holt (Abb. 1).

Mittlerweile gibt es im Markt Abstraktionsschichten wie Embeetle oder PlatformIO, die Entwickler:innen die Komponentenverwaltung und das Deployment erleichtern sollen. Die Kehrseite dieser Situation ist allerdings, dass eine einmal eingerichtete Embedded-Umgebung nach Möglichkeit nicht geschüttelt oder anders gestört werden sollte.

Die unter [1] bereitgestellten Anweisungen zur Einrichtung eines nativen Compile-Systems sind deshalb vor allem für jene empfehlenswert, die einerseits erhebliche Kenntnisse im Bereich der STM-Toolchain mitbringen, andererseits auf ihrer Windows-Partition aber nur wenig STM-spezifische Elemente vorhalten. Da sich dieser Betriebszustand in der Praxis allerdings nur höchst selten einstellen dürfte und die Aufgabe andererseits nach Kompartimentierung ruft, ist es logisch, dass Containertechnologien wie Docker im Laufe der letzten Monate und Jahre auch im Embedded-Bereich rapide Land gewinnen konnten.

In den folgenden Schritten wird die Autorin deshalb mit einer als „Dev Container“ bezeichneten Containerumgebung arbeiten, die die Emulation bzw. emulierte Ausführung von allem, was man zur Erzeugung einer Firmware benötigt, ermöglicht.

Inbetriebnahme des Containers

Obwohl Docker einst eine rein unixoide Technologie war, bietet Microsoft seit längerer Zeit erstklassige Docker-Unterstützung auch für Windows an.

Interessant ist, dass das .NET-nanoFramework-Entwicklerteam in der Dokumentation an mehrerlei Stelle davon abrät, Systeme wie Docker Desktop zu verwenden. Im Interesse der optimalen EA-Performance empfiehlt man stattdessen die Verwendung von WSL2. Die Installation von WSL2 selbst ist dabei nicht Thema des Artikels – interessierte Entwickler:innen werden von Microsoft unter [2] mit den notwendigen Anweisungen versorgt.

Die nächste Amtshandlung ist dann das Deployen einer Distribution, die für die Kompilation der Firmware herangezogen werden soll:

C:\WINDOWS\system32>wsl --list --online
C:\WINDOWS\system32>wsl --install -d Ubuntu-22.04

Wer die Befehle unter Windows 11 oder auf einer vergleichsweise frisch aufgesetzten Workstation zur Ausführung bringt, muss die Distribution stattdessen nach folgendem Schema armieren:

C:\WINDOWS\system32>wsl --install Ubuntu-22.04

Wichtig ist lediglich, immer Ubuntu 22.04 zu verwenden – diese Version wird von der .NET-Entwicklerschaft empfohlen. Im Rahmen der Installation der Distribution wird wie üblich ein Unix-Passwort abgefragt.

Nächste Amtshandlung ist das Herunterladen und Installieren einer Docker-Runtime in der Linux-Distribution. Die diversen Vorbereitungshandlungen, um die Docker-Quellen in die Softwareverwaltung von Ubuntu zu integrieren, sind in [3] im Detail dokumentiert. Alternativ dazu zeigt Abbildung 2 die auf der Workstation der Autorin ausgeführten Befehle – dass vor der Installation von CA Cerfiticates und curl ein Aufruf von Upgrade und Update erforderlich ist, sei im Interesse der didaktischen Ehrlichkeit angemerkt.

Die letzte Amtshandlung ist dann das Installieren von Docker, das Setzen der Benutzerberechtigungen und das Schließen des WSL-Fensters:

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER
exit

Fast alles mit Visual Studio Code

Im Bereich der containerbasierten Entwicklung hat sich Visual Studio Code in der Vergangenheit als Quasistandard etabliert. Die unter Windows 10 arbeitende Autorin verwendet in den folgenden Schritten Visual Studio Code 1.95.1 – zu beachten ist, dass es sich um eine vergleichsweise aktuelle Version handeln muss.

Wichtig ist außerdem, dass die Erweiterung von Dev Containers Teil von Visual Studio Code ist – man beachte, dass wir hier die offizielle Version von Microsoft verwenden müssen. Im Store gibt es auch einige Alternativen von anderen Anbietern.

Da die Verbindung von Visual Studio Code zur Kompilations-VM vergleichsweise umfangreiche Anpassungen an der Konfiguration voraussetzt, ist man gut beraten, unter der Option File | Preferences | Profile | New profile ein neues Profil für die diversen Konfigurationsarbeiten anzulegen.

Nächste Amtshandlung ist das Anklicken des neuen Fensterbuttons in der Zeile mit dem erzeugten Profil. Visual Studio startet in diesem Fall eine weitere Instanz der IDE, die nun aber die im neu...