Programmierung
Das Zephyr-Build-System verwendet das Buildtool CMake (https://cmake.org/). CMake erstellt mit Hilfe sogenannter Generatoren Build-Systeme in verschiedenen Formaten. Zephyr unterstützt dabei die folgenden Generatoren: Unix Makefiles (unterstützt auf Linux) und macOS sowie Ninja (unterstützt auf allen Plattformen). Auf meinem Linux-System verwende ich Unix Makefiles und kann damit auf recht einfache Weise den Build-Prozess durchführen. Mit dem traditionellen Hello-World-Beispiel im nächsten Abschnitt kann die Funktionsweise der Zephyr-Entwicklungsumgebung getestet werden.
Eine allgemeine Einführung in die wichtigsten Funktionen und Dienste des Zephyr-Kernels ist im Zephyr-Kernel-Primer (https://docs.zephyrProjekt.org/latest/kernel/kernel.html#zephyrkernel-primer) zu finden. Umfangreiche Developer-Guides (https://docs.zephyrProjekt.org/latest/application/index.html#developer-guides) helfen beim Einstieg in die komplexe Materie.
Die hier erwähnten Programmbeispiele sowie zugehörige Screenshots sind auf Github unter https://github.com/ckuehnel/zephyrtests abgelegt.
Beim Hello-World-Beispiel erfolgt hier eine periodische Ausgabe über die Console. Die folgenden Zeilen in Listing 1 zeigen eine Print-Ausgabe gefolgt von einer Pause von 2,5 s. In ähnlicher Form ist der Quelltext bei den Zephyr-Programmbeispielen im Verzeichnis /zephyr/samples/hello_world zu finden.
/*
* Copyright (c) 2012-2014 Wind River Systems, Inc.
* SPDX-License-Identifier: Apache-2.0
*/
#include <zephyr.h>
#include <misc/printk.h>
void main(void)
{
while(1)
{
printk(„Hello World! This is %s\n“, CONFIG_
BOARD);
k_sleep(2500);
}
}
Listing 1: Programmierbeispiel Hello World.
Der Build-Prozess wird nun durch die in Listing 2 ersichtlichen Kommandos gestartet. Beim Aufruf von CMake muss das Target angegeben werden. Ein erstes Build erfolgt hier für einen BBC-micro:bit (nRF51 Basis Arm Cortex-M0+), später folgen noch NXP Freedom-K64F (Kinetis K64 Basis Arm-Cortex-M4) und ST Nucleo L476RG (STM32L476RG Basis Arm-Cortex-M4).
$ cd samples/hello_world
$ mkdir build & cd build
$ cmake –DBOARD=bbc_micro-
bit ..
$ make
$ cp zephyr/zephyr.bin /
media/claus/MICROBIT
Listing 2: Start des Build-Prozesses.
Weisen die über USB verbundenen Mikrocontroller ein DAPLink-Debug-Interface [7] auf, dann erscheinen diese dem Hostcomputer als USB-Disk. Die erstellten Programme können in Binary- (.bin) oder Hex-Format (.hex) dorthin kopiert werden und die Übertragung in den Speicher des Targets erfolgt automatisch.
DAPLink kommuniziert über die CMSIS-DAP-Schnittstelle mit der CPU. Debugging, Programmierung (Flashen) und Zugriff auf Arm-Cortex-M-Mikrocontroller kann mit der Software pyOCD erfolgen [8].
Das DAP-Link-Interface stellt zusätzlich ein USB-Serial-Port zur Verfügung, welcher unter Windows als COM-Port, unter Linux als /dev/tty* und unter macOS als /dev/usbmodem erscheint.
Ist das jeweilige Target programmiert, so kann die Ausgabe über die Console verfolgt werden. Ich habe hier der Einfachheit halber das Programm minicom verwendet: $ sudo minicom –D /dev/ttyACM0 –b 115200. Die Ausgaben über die Console zeigt Bild 4.
Nachdem Hello World auf allen Targets läuft ist sichergestellt, dass die Zephyr-Entwicklungsumgebung richtig installiert ist und mit Hilfe zahlreicher Beispiele kann man sich dieses Betriebssystem nun erschließen.
GPIO und Sensoren
Die digitale IO erfolgt über das GPIO-API. Das Programmbeispiel Blinky zeigt die Konfiguration eines Ausgangs zur Ansteuerung der User-LED (LED0) auf dem Target. Unter anderem weist das Nucleo-STM32L476-Board eine solche User-LED auf. Für dieses Board habe ich das Programmbeispiel compiliert und das Ergebnis als kurzes Video ebenfalls auf Github abgelegt.
Sensoren werden im Zephyr OS über das Sensor-API angesprochen. Das Programmbeispiel BME280 zeigt die Vorgehensweise. Auf dem Erweiterungsboard enviro:bit zum BBC-micro:bit-Controller wird zur Messung von Temperatur und relativer Luftfeuchtigkeit ein BME280-Sensor von Bosch eingesetzt.
Wie im Quelltext des Programmbeispiels BME280 zu sehen ist, werden der Devicetreiber für den BME280 Sensor an die Device-Struktur gebunden und die ausgelesenen Daten der Struktur sensor_value übergeben.
Die Werte selbst werden durch einen Integer- und einen Nachkommawert in der Form repräsentiert. Die Temperatur wird im Programmbeispiel mit zwei Nachkommastellen angezeigt, Druck und Feuchtigkeit mit je einer. Bild 5 zeigt die Ausgaben über die Console.
Im Linux-Umfeld wird der I²C-Bus durch das Paket i2c-tools unterstützt. Wichtig für die Erweiterung einer Mikro-controller-Umgebung durch Sensoren oder Aktoren, die über den I²CBus angesteuert werden, ist die Kenntnis, dass Verbindung und Kommunikation zwischen dem I²C-Master und den angeschlossenen I²C-Slaves in Ordnung sind.
Das Programmbeispiel i2cdetect für das Zephyr OS bietet nicht die Funktionalität seines Linux-Kompagnons, kann aber einen Scan der am I²C-Bus angeschlossenen Busteilnehmer vornehmen. Hier läuft i2cdetect auf einem BBC-micro:bit, an den das Erweiterungsboard enviro:bit angeschlossen ist. Auf den beiden Boards sind die in Tabelle 2 ersichtlichen Sensoren bestückt.
Bild 6 zeigt die Ausgabe des Programms i2cdetect für die Kombination BBC-micro:bit & enviro:bit über die Console. Durch Abziehen des Erweiterungsboards enviro:bit kann man sich schnell von den nun fehlenden Sensoren überzeugen.
Eddystone Beacon
Eddystone ist ein Bluetooth-Low-Energy-Beacon-Profil, das von Google im Juli 2015 veröffentlicht wurde. Das plattformübergreifende und versionierte Profil enthält mehrere Frame-Typen wie Eddystone-UID, Eddystone-URL und Eddystone-TLM.
Eddystone-URL wird von dem Physical-Web-Projekt verwendet, während Eddystone-UID typischerweise von nativen Apps auf dem Gerät eines Benutzers verwendet wird. Obwohl es recht große Ähnlichkeit zu Apples iBeacon-Profil gibt, kann Eddystone durch seine unterschiedlichen Frame-Typen wesentlich mehr Funktionen abdecken, als nur die Übermittlung einer Identifikationsnummer.
Zum Test der Bluetooth-Funktionalität des Zephyr OS habe ich das Programmbeispiel Eddystone ausprobiert. Schaut man in den Quelltext des Programmbeispiels, dann erkennt man, dass derzeit nur Eddystone-URL implementiert ist. Das reicht erstmal, um auf einem BBC-Micro:bit und auf einem Phytec-reel-board einen Eddystone-URL-Beacon zu implementieren. Das Phytec-reel-board selbst wurde in [9] bereits detailliert vorgestellt.
Bild 7 zeigt den auf einem Phytec-reel-board (https://www.phytec.eu/producteu/internet-of-things/reelboard/) realisierten Eddystone Beacon in einem BLE-Scanner auf einem Android-Smartphone.
Schaut man in den auf Github für das reel-board abgelegten Quelltext, dann ist nicht die o. a. URL verknüpft, sondern eine mit Hilfe von Bitly (https://bitly.com/) auf https://bit.ly/2yQFie2 verkürzte. Google hat am 25.10.2018 über der Einstellung der Nearby-Notifications informiert [10].
Zugriff auf das Beacon-Dashboard ist aber weiterhin gegeben. Mit Googles Proximity-Beacons-API können über eigene Apps ähnliche Benachrichtigungen bereitgestellt werden. Das Proximity-Beacon-API ist Teil der Bluetooth-Low-Energy-Beacon-Plattform (BLE), zu der auch Eddystone gehört. Dieses API ist ein Cloud-Dienst, mit dem Daten verwaltet werden können, die BLE-Beacons über eine REST-Schnittstelle zugeordnet sind [11][12].
reel-board-Demo
Zur vollständigen Programmierung aller Bausteine des reel-board hat Phytec das Programmbeispiel demo bereitgestellt, das sämtliche Sensorik, LEDs und Taster beinhaltet. Die erhobenen Messwerte werden auf dem ePaper-Display angezeigt. Das reel-board sendet außerdem als Eddystone Beacon die URL https://www.zephyrProjekt.org/.
Bild 8 zeigt die Ausgaben des Programms demo auf dem ePaper-Display. Eine RGB-LED am oberen Rand von Bild 8 blinkt periodisch mit drei Farben. Weitere auf Github abgelegte Bilder sollen zusammen mit dem Quelltext helfen, die Funktionalität des Programms zu erschließen. Die URL für das Programmbeispiel lautet https://github.com/jfischer-phytec-iot/zephyr/tree/pr-reelbasic/samples/boards/reel_board/demo.
Mesh Badge
Das abschließende Programmbeispiel mesh_badge (https://github.com/jfischer-phyteciot/zephyr/tree/pr-reel-basic/samples/boards/reel_board/mesh_badge) dient der Demonstration der Bluetooth-Mesh-Kommunikation und war eine der Vorgaben für den Zephyr-Hackathon – Get Connected.
I2C-Bus | I2C-Device | Board |
---|---|---|
0x0E | MAG3110 3-Axis Magnetometer | BBC micro:bit |
0x1D | MMA8653FC 10-bit Accelerometer | |
0x29 | TCS34725 RGB Color Sensor with IR filter and White LED | enviro:bit |
0x76 | BME280 Temperature Humidity Pressure Sensor |
Tabelle 2: Sensorbestückung des Boards BBC micro:bit und des Erweiterungsboards enviro:bit.
Das Programmbeispiel startet als normale Bluetooth-GATT-Peripherieanwendung. Über die App nRF-Connect (installiert auf einem Android- oder iOS-Smartphone) kann das Pairing und die Übertragung von Text zum reel-board erfolgen. Der eingegebene Text wird schließlich im ePaper-Display angezeigt. Wird die Verbindung abgebrochen, was beispielsweise durch Beenden der App nRF-Connect erfolgt, dann geht das reel-board in den Bluetooth-Mesh-Modus über. Eine Verbindung über GATT ist dann nicht mehr möglich. Hat man mehrere reel-boards auf diese Weise konfiguriert, dann ist eine Kommunikation über Mesh möglich. Durch Drücken des User-Buttons auf dem reel-board wird das erste Wort des Textes im Display (bei einem Badge sicher ein Name) an alle anderen Boards gesendet.
Dort erscheint dann der Text »<Name> sagt Hallo!« auf deren ePaper-Displays. Auf Github ist unter https://github.com/ckuehnel/zephyrtests/tree/master/mesh_badge eine kommentierte Bildfolge zum beschriebenen Vorgehen abgelegt. Aus Platzgründen muss an dieser Stelle der Link genügen.
Schlussbemerkung
Das Zephyr OS ist ein Open-Source-RTOS, welches durch das von der Linux Foundation gehostete Zephyr-Projekt und die Nähe zu Linux das Potential hat, bei Embedded-Systemen mit kleinem Footprint in Zukunft vergleichbar erfolgreich zu werden, wie es Linux bei Systemen mit mehr Performance schon länger ist. Der Erfolg wird sicher stark durch die Community geprägt. Ausdauer und Kraft sind der Community zu wünschen. Die zentrale Mailing-List des Zephyr-Projekts [13] gibt aktuell Auskunft über die laufenden Aktivitäten.
Der vorliegende Beitrag soll Einblicke in das Zephyr-OS und die Zephyr-Entwicklungsumgebung geben. Anhand einiger einfacher und nachvollziehbarer Programmbeispiele wird die Vorgehensweise bei der Programmierung von Anwendungen und der Build-Prozess dokumentiert. Die Programmbeispiele selbst sowie dazugehörige Screenshots sind auf Github unter https://github.com/ckuehnel/zephyrtests abgelegt. (fr)
Referenzen
[1] Auswahl und Einsatz eines Embedded-Betriebssystems für Mikrocontroller. https://www.embedded-software-engineering.de/auswahl-und-einsatz-einesembedded-betriebssystems-fuer-mikrocontroller-a-736676/
[2] 25 Jahre Linux: „Das vielseitigste Betriebssystem aller Zeiten“. https://www.elektronikpraxis.vogel.de/25-jahre-linux-das-vielseitigste-betriebssystem-allerzeiten-a-549773/index2.html
[3] Top IoT Operating Systems and Microsoft. https://medium.com/@iskerrett/top-iot-operating-systems-and-microsoft-25aee43e11f4
[4] Wind River to Acquire DSP Technology from Eonic Systems. https://www.windriver.com/news/press/pr.html?ID=437
[5] Building the VxWorks Microkernel Profile. http://windriver.mrooms.net/enrol/index.php?id=192
[6] Zephyr Projekt Documentation. https://docs.zephyrProjekt.org/latest/getting_started/getting_started.html
[7] DAPLink. https://os.mbed.com/handbook/DAPLink
[8] pyOCD. https://pypi.org/Projekt/pyOCD/
[9] Das Zephyr von vorne aufgezäumt. https://www.elektroniknet.de/design-elektronik/messen-testen/das-zephyr-von-vorneaufgezaeumt-159421.html
[10] Discontinuing support for Android Nearby Notifications. https://android-developers.googleblog.com/2018/10/discontinuing-support-forandroid.html
[11] Google Beacon Platform - Proximity Beacon API – Overview. https://developers.google.com/beacons/proximity/guides
[12] Get Started with the Proximity Beacon REST API. https://developers.google.com/beacons/proximity/get-started
[13] Zephyr Projekt - The central mailing list for the Zephyr Projekt. https://lists.zephyrProjekt.org/g/main