Seid gegrüßt,

gestern (14.11.2017) sollte Zephyr in Eclipse eingerichtet werden. Dies verlief eher nicht so erfolgreich, daher möchte ich hier noch einige Fragen beantworten und Anmerkungen machen.

Festzuhalten ist, dass das Erzeugen eines Beispielprojektes mit MSYS2 bei allen funktioniert hat. Jedoch gab es hier schon einige Schwierigkeiten und es wurde nicht ganz klar, was aus welchen Gründen geschieht.

Kurz zu MSYS2:

MSYS2 is a software distro and building platform for Windows --MSYS2 Website

Es liefert unter anderem eine Shell und Autotools mit.
MSYS2 benutzt das Package Management System pacman. Darüber kann wie bei anderen Paketverwaltungssystemen, wie beispielsweise APT unter Ubuntu, Software installiert oder entfernt werden.

$ pacman -S git cmake make gcc dtc diffutils ncurses-devel python3 gperf

Der Parameter -S steht für das Installieren bzw. Aktualisieren von Paketen (vgl. pacman Wiki). Somit installieren wir mit dem Befehl gleich mehrere Pakete wie angegeben (git, cmake, ...) in einem Rutsch.

Diese Pakete werden für Zephyr später benötigt. Zephyr benutzt seit letzter Woche die Build-Umgebung CMake, mit welcher wir Makefiles erstellen. Zu CMake gibt es auch Bücher mit über 700 Seiten (siehe Mastering CMake). Wir müssen erstmal nur wissen, dass wir CMake nutzen, um Makefiles zu generieren.

Als nächstes haben wir Zephyr heruntergeladen und pip installiert. Das Python-Programm pip (pip installs packages) ist das Paketverwaltungssystem für Python-Pakete. Darüber werden die Pakete installiert, die in der Datei zephyr/scripts/requirements.txt stehen.

Anschließend wurden gewisse Befehle in die Datei .zephyrrc geschrieben.
Der Befehl export definiert Umgebungsvariablen für die aktuelle Shell-Sitzung.

$ export ZEPHYR_GCC_VARIANT=gccarmemb

Somit erzeugt der obige Befehl die Umgebungsvariable ZEPHYR_GCC_VARIANT und weist ihr gccarmemb zu. Sobald wir die MSYS2-Shell schließen, ist die Umgebungsvariable nicht mehr vorhanden.
Deswegen wollten wir die export-Befehle in die .zephyrrc schreiben, damit alle benötigten Umgebungsvariablen schnell geladen werden können.
Dieser Ansatz hat den Nachteil, dass jedes Mal die Umgebungsvariablen geladen werden müssen, sobald eine MSYS2-Shell geöffnet wird. Der Vorteil ist, dass nicht immer alle Umgebungsvariablen global und für jede Sitzung vorhanden sein sollen. Beispielweise, wenn man über mehrere Zephyr-Projekte mit verschiedenen Architekturen verfügt. Dabei werden z. B. andere Compiler benötigt und die Umgebungsvariablen enthalten andere Zuweisungen oder es sind verschiedene Versionen für ein Programm vorhanden und man will nicht, dass versehentlich die falsche Version automatisch ausgewählt wird.

Der Befehl source zephyr-env.sh hat die Befehle in der Datei .zephyrrc ausgeführt (Setzen der Umgebungsvariablen), den Pfad ~/zephyr/scripts zur PATH-Umgebungsvariable hinzugefügt sowie die Variable ZEPHYR_BASE erzeugt.

Gestern habe ich dann bei den meisten diese Dinge einfach in die .bashrc geschrieben, damit nicht für jede Sitzung source zephyr-env.sh ausgeführt werden muss. .bashrc wird bei jedem Start einer MSYS2-Shell ausgeführt.

Als nächstes wurde Kconfig erzeugt. Kconfig wird später genutzt, um Projekte zu konfigurieren, wie beispielsweise die Boardauswahl oder das Nutzen von Debug-Ausgaben etc. Es sind über 2500 Kconfig-Symbole zum jetzigen Zeitpunkt vorhanden. Eine Auflistung findet man unter Kconfig Symbole. Der Pfad zu Kconfig muss der PATH-Variablen hinzugefügt werden. Dies wurde ebenfalls in der .zephyr eingetragen. Wenn jetzt der Weg der "globalen" Umgebungsvariablen (also für jede Sitzung automatisch) gewählt wird, muss dieser Eintrag noch in die .bashrc übernommen werden. Ansonsten ist der Eintrag in der .zephyrrc richtig und wird über source zephyr-env.sh geladen.

Kompilieren eines Beispielprojektes

Zum Schluss wurde in den Ordner eines Beispielprojektes gewechselt. In diesem Fall das Bluetooth-Mesh-Beispiel und ein build-Ordner angelegt. Danach wurden unter anderem Makefiles mit dem Befehl

cmake -DBOARD=nrf51_pca10028 ..

erstellt. Mit dem Parameter -DBOARD=nrf51_pca10028 wurde lediglich ausgedrückt, für welches Device CMake die Projektdateien erstellen soll. Es werden nämlich viele verschiedene Architekturen (u.a. arm, risc-v, x86 etc.) und Boards untersützt (nrf51, arduino). .. musste verwendet werden, da wir den Befehl cmake in dem Unterordner build ausgeführt haben und die benötigte Datei CMakeLists.txt einen Ordner höher lag.
Kompiliert wurde dieses Projekt anschließend mit make und wenn alles geklappt hat, dann wurde die Datei zephyr.hex erzeugt. Diese ist sozusagen das Programm, welches auf den Mikrocontroller geflasht werden muss.

Wie programmiert man den Mikrocontroller

Für einige Boards wird ein externer Programmer benötigt wie beispielsweise
ST-Link Programmer (für Geräte von STMicroelectronics) oder ein J-Link (für diverse Geräte von verschiedenen Herstellern).
STLink und J-Link Edu
Wir benutzen die Boards NRF51-DK und NRF52-DK von Nordic Semiconductor. Auf diesen Boards ist bereits ein J-Link verbaut. Somit können wir die Boards flashen, wenn wir den PC mit dem Board über ein Micro-USB-Kabel verbinden.
Es können verschiedene Tools zum Flashen verwendet werden. Es gibt nrfjprog von Nordic, Software von Segger und noch weitere Möglichkeiten, wie OpenOCD etc.

Da wir aber nicht nur Programme auf das Board flashen wollen, sondern gegebenfalls das Programm debuggen wollen, wird JLinkGDBServer benötigt. Dieser ist wie der Flasher beim Software-Paket von Segger dabei. Hierfür ist ein Plugin für Eclipse vorhanden (GNU MCU Eclipse Plugin).

Die Einbindung in Eclipse war nur bei Einigen erfolgreich. Der größte Teil konnte die Plugins nicht installieren bzw updaten. Wir werden im Labor die aktuellste Version des Plugins bis nächste Woche zur Verfügung stellen. Dann sind auch die Einträge wie im Eclipse Tutorial vorhanden.
Es ist niemand an Eclipse gebunden. Falls jemand andere Vorlieben hat, dann kann er diese gerne nutzen, sofern er es zum Laufen kriegt. Es gibt von CLion eine 30-tägige Testversion. CLion kann standardmäßig bereits mit CMake-Projekten umgehen. Das Einrichten des Debugvorgangs unterscheidet sich jedoch und ihr müsstet euch selbst darum kümmern.

Zum Schluss sei gesagt, dass der Hardwareteil der Blockwoche sehr anstrengend sein wird. Es gibt kein Tutorial, dem ihr einfach folgen könnt und - zack - habt ihr alle Sensoren angebunden und ein Mesh-Netzwerk aufgebaut. Zephyr wird stetig weiterentwickelt. Alleine in den letzten 24 Stunden gab es über 20 neue Commits. Man muss sich darauf einstellen, dass man bei so einem großen Projekt viele Schwierigkeiten hat. Alleine beim Einbinden eigener Dateien in die CMake-Dateien bzw. Makefiles kann es zu Schwierigkeiten kommen. Somit sollte man sich gut überlegen, ob man darauf Lust hat, sich mit vielen verschiedenen Aspekten auseinander zu setzen. Neben CMake oder Make muss sich mit vielen weiteren Punkten wie dem Mikrocontroller auseinander gesetzt werden. Dazu zählen I2C, Interrupts, Flash-Speicher und vieles mehr.
Ich will hier niemanden abschrecken und bin mir sicher, dass wir das gemeinsam schaffen. Ich will nur bewusst machen, worauf man sich einlässt und jeder kann sich vorab Gedanken machen, ob er das überhaupt will.

Viele Grüße
Arthur