Neuer Kurzstrecken-Funkstandard Matter
Matter-Geräteentwicklung mit Nordic-Systemen
Das norwegische Unternehmen Nordic Semiconductor unterstützt mit seinen Funk-ICs und SoCs den Verbindungsstandard Matter seit Anbeginn, sodass es sich lohnt, ein passendes Entwicklungskit und die Software-Entwicklungsumgebung unter praktischen Gesichtspunkten näher zu untersuchen.
Nordic Semiconductor ist besonders durch die Multiprotokoll-SoCs (System on a Chip) der nRF-Serien für Nahfunksysteme wie Wi-Fi, Bluetooth LE, ZigBee, ANT, Thread und individuelle 2,4-GHz-Protokollsysteme bekannt geworden. Die SoCs basieren auf ARM-Mikrocontrollern wie Cortex M0 (nRF51-Serie), Cortex M4 (nRF52-Serie) und Cortex M33 Dual-Core bei der nRF53- und der nRF54-Serie, die momentan den höchsten Integrationsgrad aufweist.
Vor allem der nRF52840 (Bild 1), der seit 2018 auf dem Markt ist, wurde in zahllose BLE-Peripherieeinheiten eingebaut. Er unterstützt ebenfalls ANT, Thread, NFC sowie proprietäre 2,4-GHz-Systeme. Die Nordic-SoCs gelten generell als recht energieeffizient und bieten neben dem multifunktionalen Funkinterface auch programmierbare GPIO-Leitungen sowie DMA für die schnelle Datenübertragung ohne CPU.
Matter-Aufgabenstellung
Die folgende Aufgabenstellung, die für Matter-Systeme unterschiedlicher Hersteller auch in folgenden Veröffentlichungen gelten soll, ist zwar relativ einfach, deckt aber die wichtigsten Aspekte für die Hardware- und Software-Entwicklung von Matter-Geräten ab:
Mit einem möglichst kostengünstigen Developerkit und der zur Verfügung gestellten Software soll eine Light-Bulb-Applikation programmiert werden, die sich daraufhin in eine Matter-Umgebung wie Google Home oder SmartThings von Samsung integrieren und bedienen lässt.
Dabei gilt es auch festzuhalten, wie schnell man mit dem jeweiligen Kit zu einem funktionierenden Matter Device kommt, ohne etwa Hunderte Seiten von Dokumentationen lesen (und verstehen) oder auch tagelange Software-Installationen und -Konfigurationen ausführen zu müssen. Wünschenswert ist die gute Führung des Entwicklers durch die Dokumentations- und Programmvielfalt, um das Abdriften auf Nebenschauplätze möglichst zu vermeiden, was natürlich auch von den Vorkenntnissen des Entwicklers abhängt. Am besten ist es, wenn eine separate Dokumentation für die Matter-Geräteentwicklung zur Verfügung steht, die die notwendigen Schritte klar und deutlich darstellt. Die Light Bulb wird auf dem Developer Board mit einer Leuchtdiode dargestellt und soll sich von einem Smartphone mit einer App ein- und ausschalten lassen. Idealerweise ist es auch möglich, dass die App einen Tastendruck auf dem Board registriert, um somit die Bidirektionalität der Matter-Datenkommunikation testen zu können. Die App stammt vom jeweiligen Hersteller des Matter Hub, der Wi-Fi und Thread für die Kommunikation mit Matter End Devices unterstützt.
Developer Board nRF7002
Nordic Semiconductor hat mehrere Developer Boards in seinem Lieferprogramm, die sich für Matter-Applikationen eignen, weil die Boards schon seit Längerem Wi-Fi, Thread und BLE unterstützen und Matter auf diesen drei Standards in der Applikationsschicht (OSI Layer 7) lediglich aufsetzt. Wichtig ist aber, dass das gewählte Board explizit als für Matter geeignet ausgewiesen ist, also die dafür notwendigen Treiber und Tools mit Beispielen zur Verfügung gestellt werden, was beispielsweise auf das nRF7002-DK zutrifft (Bild 2). Das Kit enthält lediglich das Board ohne irgendwelches Zubehör.
Auf dem Board sind ein nRF7002-Chip als Wi-Fi-6-Dual-Band-Companion-IC (2,4 und 5 GHz) vorhanden sowie zwei nRF5340-SoCs mit einem integrierten Cortex-M33-128-MHz-Application-Core und einem Cortex-M33-64-MHz-Network-Core für NFC, BLE, ZigBee, ANT und Thread. Dabei fungiert der eine nRF5340-SoC auf dem Board nur als Interface und Debugger-Schaltung (Segger). Diese ICs sind per QSPI verbunden. Außerdem gibt es Arduino-Pfostenleisten, zwei User- und einen Reset-Taster sowie mehrere LEDs. Angeschlossen wird das System an eine USB-Micro-Buchse.
nRF-Connect-SDK-Installation und -Deinstallation
Für die Programmierung und Software-Entwicklung stellt Nordic die Entwicklungsumgebung nRF Connect SDK [1] zur Verfügung, die für Windows, Linux und macOS verfügbar ist. Das SDK bietet Unterstützung für die verschiedenen Nahfunkverfahren der Serien nRF52, nRF53, nRF70 (Ultra Low Power Wi-Fi) und nRF91 (LTE-M, NB-IoT).
Neben den erforderlichen Bibliotheken, Treibern, Stacks und Protokollen sind einige Matter-Beispiele für unterschiedliche Boards und Home-Kit-Applikationen integriert. In die SDK-Umgebung ist das Echtzeitbetriebssystem Zephyr eingebettet, dessen Routinen und Tools für bestimmte Applikationen – zum Beispiel für Matter – notwendig sind. In Bild 3 ist eine vereinfachte Darstellung einzelner Software-Komponenten im SDK-Stack gezeigt.
Für die komplette Entwicklungsumgebung sind mehrere Pakete notwendig, was den Installationsvorgang unübersichtlich und relativ aufwendig macht. Die Pakete stellt Nordic allesamt ohne Registrierung kostenlos zur Verfügung.
Zunächst ist »nRF Command Line Tools« (cmake, mergehex, nrfjprog) mit dem J-Link Driver (Debugger) von Segger zu installieren, wobei alle vorgeschlagenen Optionen nur bestätigt werden müssen. Danach soll das Programm »nRF Connect for Desktop« (nrfconnect-setup5xx) installiert werden, gefolgt vom eigentlichen SDK, das die genaue Bezeichnung »nRF Connect SDK for VS Code« trägt und mit Visual Studio (VS) von Microsoft arbeitet. So ist zunächst Visual Studio Code von der Website code.visualstudio.com/download zu beziehen und anschließend zu installieren (VSCodeUser-Setup).
In Visual Studio ist daraufhin das »nRF Connect for VS Code Extension Pack« zu installieren. Danach wird in VS das Extension Pack geöffnet und auf »Install Toolchain« geklickt, um damit die neueste Toolchain zu installieren. Nun fehlt immer noch das eigentliche nRF-SDK, das über »Manage SDKs – Install SDK« und Auswahl der aktuellen finalen Version (zum Beispiel v 2.70) installiert wird, die keine Bezeichnung wie »cs« oder »dev« aufweisen sollte.
Damit ist die Installation der Entwicklungsumgebung beendet. Diese lässt sich danach aber nicht mehr rückstandsfrei aus einem Windows-System entfernen, was nicht Stand der Technik sein sollte und später für unerwartete Fehler (zum Beispiel Versionskonflikte) verantwortlich sein kann. Die installierte Nordic-Software bietet in der Windows-Systemsteuerung zwar die entsprechenden Deinstallationsfunktionen; dennoch bleiben bestimmte Verzeichnisse, Workspaces, Toolchains, nRF-Extensions und eine Vielzahl von Systemeinträgen in Windows erhalten – es handelt sich um mehrere Gigabytes (siehe zum Beispiel Verzeichnisse ncs oder auch users/.nrfconnect-apps).
Wenn man beispielsweise während der Systementwicklung zu dem Ergebnis kommt, dass das SDK mit seinen Dateien und Festlegungen möglicherweise der »Übeltäter« für ein Nichtfunktionieren – zum Beispiel des Build-Vorgangs – ist, sollte eine Neuinstallation der Software wieder einen »sauberen« Neustart der Softwareentwicklung ermöglichen. Dies ist aber leider nicht der Fall. Wenn eben Dateien der vorherigen Installation erhalten bleiben, treten möglicherweise wieder die gleichen Fehler auf wie vor der Neuinstallation.
Genau dieses Phänomen ist bei unserem Versuch, eine Matter-Applikation zu erzeugen, x-mal aufgetreten. Erst nach der Installation auf einem PC, auf dem noch nie irgendeine Nordic-Software oder eine ähnliche Entwicklungsumgebung installiert war (und der Klärung der tatsächlichen Fehlerursache, siehe unten), war der Build-Vorgang des Matter-Beispiels erfolgreich durchführbar.
Entwicklungsstart mit einfachem Beispiel
Um neue Hardware und Software für eine Applikation zu testen, ist es allgemeine Praxis, mit einem einfachen Beispiel zu beginnen. Deshalb wird auch hier nicht gleich ein Matter-Beispiel aufgerufen, das mit zahlreichen Abhängigkeiten (Bild 3) aufwartet, sondern eines, das lediglich eine LED auf dem Board zum Blinken bringt; einfacher geht es nicht. Bei Nordic wird das LED-Beispiel als »Blinky« bezeichnet.
Im Folgenden sind die Schritte angegeben, die notwendig sind, um das Blinky-Beispiel in nRF Studio anzulegen:
- Öffnen der nRF Extension (Bild 4) und »Create a new Application« wählen
- Option »Copy a Sample« auswählen, es erscheint der Sample Browser
- Select the SDK Version: nRF Connect SDK v2.7.0
- Suche nach Blinky Sample, Beispiel wird gefunden
- Neues Verzeichnis anlegen, zum Beispiel: c:\nordicprogs\Blinky1
- Eingabetaste (Enter/Return) betätigen
- Angezeigt wird »Created the new application – Open« -> betätigen
- Abfrage, ob der Workspace gespeichert werden soll: Yes – Bezeichnung eingeben
- Angezeigt wird: »Do you trust the authors of these files in this folder?« – »Yes, I trust the authors« anklicken
- Damit ist das Beispiel angelegt. Als Nächstes folgt die Erzeugung des Programms, also der Build Process, bei dem die benötigten Dateien eingebunden, konfiguriert und in ein Hex-File für den darauf folgenden Flash-Programmiervorgang umgesetzt werden (Bild 5).
Build Configuration
Unter »Applications« (Bild 6) stehen der Eintrag für das zuvor angelegte Beispiel Blinky1 und »Add build configuration«, was anzuklicken ist. Daraufhin öffnet sich die Seite »Add Build Configuration« (Bild 5). Die wichtigste Angabe ist zunächst unter »Board target« notwendig, dort ist das an den USB des Computers angeschlossene Board auszuwählen. Eine automatische Erkennung, wie sie bei anderen Herstellern üblich ist, gibt es hier leider nicht; es ist auch nicht immer zweifelsfrei zu erkennen, welcher Eintrag zum angeschlossenen Board passt. Denn es gibt für das gleiche Board oftmals mehrere Möglichkeiten (Bild 5), die sich in bestimmten Punkten (zum Beispiel CPU, Security) voneinander unterscheiden, was jedoch an dieser Stelle nicht unmittelbar zu erkennen ist.
Es folgen mehrere Optionen für verschiedene Konfigurationsdateien (Base Configuration, Extra Kconfig fragments etc.), für die man aber die jeweiligen Voreinstellungen (Defaults) übernehmen kann und den Build-Vorgang dann über »Build Configuration« auslöst.
Um den Vorgang besser verfolgen zu können, empfiehlt es sich, das Terminal-Fenster am unteren Bildschirmrand nach oben zu ziehen. Das vergrößert den Anzeigebereich, und so ist gleich erkennenbar, ob unter »Problems« Warnings oder Errors auftauchen.
Der Build-Vorgang dauert selbst bei einem so einfachen Beispiel wie Blinky recht lange. Selbst wenn ein sehr schneller Computer zum Einsatz kommt, beträgt die erforderliche Zeit – im Vergleich mit anderen Entwicklungssystemen – ein Vielfaches. Während des Vorgangs erscheinen zahlreiche Meldungen, wobei einige wie: »Do you want to install the recommended C/C++ Extension Pack from Microsoft for the c++ language?« eine Bestätigung erfordern
Offensichtlich ist dann ein Microsoft Extension Pack notwendig. Eine Installation während des Build-Vorgangs ist jedoch nicht ratsam, denn er wird dadurch gestört und kann nicht erfolgreich beendet werden. Bei einem neu installierten System kommt es vor, dass während des ersten Build-Vorgangs meist noch weitere Nachinstallationen angemahnt werden. So ist es nicht ungewöhnlich, dass mehrere Anläufe für einen erfolgreichen Build notwendig werden.
Dieses »unerfreuliche« Systemverhalten kann gerade beim Einstieg für einigen Unmut sorgen, was sich sogar verschlimmert, wenn sich in dem PC noch andere Visual-Studio-Installationen befinden. In solch einem Fall ist es beim Build-Vorgang (Compile, Link) nicht eindeutig, welche der vorhandenen Make Configurations zum Einsatz kommen soll. Dabei hängt es auch vom jeweils zu bearbeitenden Programm ab, ob der Vorgang ohne Fehler durchläuft oder ob es zu (zahlreichen) Fehlerausgaben kommt, die sich – zumindest auf den ersten Blick – keineswegs auf Anhieb einer unpassenden Make Configuration zuordnen lassen.
In der Symbolbar lässt sich unter Cmake (Dreieckssymbol, Bild 6) und Configure festlegen, welcher Compiler zum Einsatz kommen soll. Dabei ist allerdings nicht sichergestellt, dass sich die hier angezeigten Compiler tatsächlich (noch) auf dem Computer befinden oder ob nur noch ihre Hinterlassenschaften in der Registry vorhanden sind. Das SDK selbst kann dies nicht erkennen, sodass man letztendlich selbst ausprobieren und überprüfen muss, ob es zu einer Fehlermeldung kommt (Compiler not present) und man daraufhin eine andere Variante wählen muss.
Spätestens beim Aufruf von »Add Build Configuration« (Bild 5) wird man beim Fehlen einer gültigen Compiler-Angabe dazu aufgefordert, einen anzugeben. Man sollte an dieser Stelle stattdessen die automatische Suche (Scan for Kits: Search for compilers on this computer) wählen, sodass automatisch einer vom SDK selektiert wird; das sollte dann funktionieren.
Das Build-System des nRF-Connect-SDK beruht auf dem Echtzeitbetriebssystem Zephyr, das wie die Nordic-Erweiterungen unter Open Source firmiert. Diese modulare Systemumgebung hat eindeutig definierte Abhängigkeiten (Bild 3), was einerseits zu einer gewissen Portabilität auf unterschiedliche Hardware führt. Andererseits lässt sich dieses System (für Einsteiger) nur schwer erfassen und macht den Build-Prozess zu einer längeren Prozedur, weil im Grunde genommen stets ein (komplettes) Betriebssystem kompiliert wird.
Der Flash-Vorgang
Nach erfolgreicher Beendigung des Build-Prozesses, der ohne Fehler absolviert wird (Blinky1: build), lässt sich das Programm in den Flash-Speicher des Boards schreiben. Zunächst ist jedoch »Connected Devices« zu kontrollieren. Hier muss das angeschlossene Board angezeigt werden (Bild 6). Etwas verwirrend ist dabei, dass sich die Bezeichnung von derjenigen unterscheidet, die unter Board target (Bild 5) angeklickt wurde.
Dann ist im Funktionsbaum unter »Actions« der Punkt »Flash« anzuklicken, woraufhin der Programmiervorgang im Terminalfenster zu verfolgen ist. Nach dem Abschluss des Flash-Vorgangs startet das Programm aus dem Flash automatisch, und die LED1 (Bild 2) auf dem Board blinkt.
Zum »Flashen« eines anderen Programms, das unter »Applications« als fertiger Build auftauchen muss, ist dieses zu selektieren und daraufhin wieder »Actions – Flash« auszulösen. Falls im aktiven Programm (main.c) etwas geändert wird, kann das Programm danach direkt neu »geflasht« werden, denn der Build-Vorgang wird zuvor automatisch erneut durchlaufen.
Matter-Applikation – Light Bulb
Ein typisches Beispiel für eine Matter-Applikation ist Light Bulb, eine nachgebildete Glühlampe, die sich per App ein- und ausschalten und optional sogar dimmen lässt. Als Light Bulb fungiert eine LED auf dem Board, deren Funktion sich mit einem Taster überprüfen lässt. Unter [2] ist dazu eine Beschreibung zu finden, die ungeeignet ist für Einsteiger, die in einem Matter-Netzwerk lediglich die Light Bulb erproben wollen.
Die Dokumentation dazu wirkt überdimensioniert, sodass das eigentliche Ziel schnell aus dem Fokus gerät, wenn zum Beispiel Details zu Chip Tools, IPv6, Trusted Firmware oder AWS bearbeitet werden, nicht jedoch, wie das Board zu programmieren oder in ein handelsübliches Matter-Netzwerk zu integrieren ist. Eine zielgerichtete Dokumentation, die den Weg zu einem Matter Device in leicht nachvollziehbaren Schritten beschreibt, wäre hier wünschenswert. Die zweifellos nützlichen Informationen in der Matter-Dokumentation, zum Beispiel zur BLE- und Thread-Umsetzung, sollten keine Voraussetzung dafür sein, ein Matter-Gerät mit einem einfachen Beispiel programmieren und in Betrieb nehmen zu können. Nordic hat dazu jedoch eine andere Meinung und empfiehlt, dass die notwendigen Kenntnisse von Grund auf in der Nordic Developer Academy [4] erworben werden sollten.
Wichtig ist in der Dokumentation [2] der dort angegebene QR-Code unter »Onboarding Information« für die Integration des programmierten Boards mit dem Light-Bulb-Beispiel in ein Matter-Netzwerk.
Das Light-Bulb-Beispiel wurde zwar in der oben erläuterten Vorgehensweise und mit den gleichen Voreinstellungen für die Build Configuration wie bei Blinky eingestellt; allerdings scheiterte der Build-Vorgang (Bild 7), weil dabei eine ganze Reihe von Fehlern auftraten, was gleichermaßen bei den anderen Matter-Beispielen passierte. Das erneute Studium der Dokumentationen und verschiedenste Anpassungen der Konfigurationsdateien brachten keinen Erfolg. Eine Neuinstallation des nRF-Connect-SDK verschärfte die Situation sogar noch (siehe oben).
Um sicherzugehen, dass das Board nicht defekt ist, wurde das Programm »nRF Connect for Desktop« mit der Funktion »Quick Start – Open – Detect« aufgerufen. Dies lieferte allerdings nur die Meldung: »Not supported yet (Family 70, Device: nRF7002DK, SN: 001050791743, Custom Name: none)«, es wurde demnach nicht erkannt. Nordic sagt dazu, dass das Programm nur bestimmte Development Kits erkennt und dass nRF7002 möglicherweise in einer späteren Version unterstützt wird. Es ist aber etwas merkwürdig, wenn die Dokumentation und das Video auf die Notwendigkeit dieses Programms hinweisen, das jedoch (noch) nicht mit dem Board funktionieren kann.
Lösung des Build-Problems
Weil dieses Build-Problem bisher noch nicht bekannt zu sein schien, wurde ein Ticket in der Entwickler-Community »Nordic DevZone« [3] unter der Bezeichnung »nRF Studio don´t work with Matter Examples« geöffnet, womit eine sechswöchige Kommunikation begann. Nach kurzer Zeit stellte sich jedoch der Eindruck ein, dass die Beteiligten aneinander vorbei argumentierten, da Nordic nicht akzeptieren wollte, dass sich das Light-Bulb-Beispiel mit der eingesetzten aktuellen Software nicht kompilieren lässt, während das einfache Blinky-Beispiel in der gleichen Umgebung fehlerfrei durchläuft. Eigentlich sollte man davon ausgehen können, dass das Unternehmen eine finale Software mit der dafür vorgesehenen Elektronik erprobt hat, was Nordic auch während der Kommunikation mehrere Male versicherte. Dem war jedoch nicht so.
Erschwerend kommt hinzu, dass man durch die Nordic-Problemanalyse zu neuen Nebenschauplätzen (Bootloader, Flash Area, FOTA) navigiert wurde, sodass die (letztlich einfache) Lösung in immer weitere Ferne zu rücken schien. Wer sich selbst ein Bild vom Vorgang machen möchte, sei auf das Ticket [5] verwiesen.
Die Lösung lag erstaunlicherweise nur einen Mausklick weit entfernt: Statt »Build System Default« (Bild 5) oder »No Sysbuild« ist »Use Sysbuild« zu selektieren. Damit läuft der Build-Prozess ohne eine weitere Veränderung durch, allerdings wieder mit Meldungen unter »Problems«, die jedoch nach dem folgenden Flash-Vorgang verschwinden. Laut Nordic sei dies normal, und man arbeite daran, dies zu ändern.
Die Unterschiede zwischen diesen drei Build-Optionen werden aus der Dokumentation nicht ersichtlich. Ihre Funktion hängt laut Nordic von der jeweiligen SDK-Version ab. Die No-Sysbuild-Option war vor der SDK-Version 2.7 üblich, während Use Sysbuild als Higher-Level-Build-System fungiert, das mehrere Images zusammenfasst, wie es eben für Matter mit verschiedenen Files und Protocol Stacks notwendig ist. Das Build-Problem ist mittlerweile von Nordic bestätigt und mit der SDK-Version 2.8.0 beseitigt worden, bei der man wieder die voreingestellte Option »Build System Default« verwenden soll.
Nach dem Flash-Vorgang ist das Matter Device fertiggestellt. Die Integration in ein Matter-Netzwerk [6] SmartThings (Samsung) mit Aeotec-Hub geht dann rasch und ohne Besonderheiten vonstatten, sodass die Light Bulb mit der App (Bild 8) geschaltet werden kann.
Fazit
Es ist erstaunlich, dass ein Matter-Pionier wie Nordic Semiconductor mit dem nRF-Connect-SDK eine vergleichsweise langsame und unübersichtliche Entwicklungs-Software anbietet, die sich zudem von einem (Windows-)PC nicht wieder rückstandsfrei entfernen lässt. Generell ist an der hakelig wirkenden Software noch einiges zu tun, damit auch Tools wie »nRF Connect for Desktop« mit den dafür vorgesehenen Boards funktionieren. Nordic bietet zwar eine Vielzahl von Dokumentationen und Online-Hilfen an, doch diese sind mitunter zu wenig zielgerichtet und nur unzureichend auf einen schnellen Matter-Einstieg ausgerichtet.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
