Was ist das neue nRF Connect SDK für Nordic? Evolution, Revolution oder Alternative?

Letzte Woche, Nordic Semiconductor hinzugefügt nRF52 Serie Unterstützung für die nRF Connect SDK.



Die Hauptfrage, die die meisten Menschen haben, ist, was es ist und warum es wichtig ist. Diese Frage ist besonders relevant für diejenigen, die Erfahrung mit dem nRF5 SDK haben, und es gibt viele davon.

Ich stelle sofort fest, dass der Artikel in erster Linie für diejenigen geschrieben wurde, die traditionelle Ansätze bei der Entwicklung von Cortex-M-Level- oder Close-Geräten verwenden. Daher scheinen einige Definitionen und Analogien aus der Sicht derjenigen, die auf hohem Niveau arbeiten (was auf der Linux-Seite geschieht), möglicherweise nicht vollständig korrekt zu sein, aber es wird für diejenigen, die gerade so anfangen, einfacher zu verstehen sein.

Kommentare und Erläuterungen sind immer willkommen.


Ein wenig darüber, wer Nordic ist und wie es ihnen jetzt gut geht
Nordic . , , Bluetooth Low Energy, 90% . : Starline, Pandora, Scher-Khan . Redmond, Ready4Sky. . 2 .

Nordic Semiconductor 40%, 2.5 , (TI). , . , Samsung Xiaomi Nordic , , .

, Nordic, , . nRF5x STM ( ).

:

  • ( )
  • SDK
  • ( )
  • Altium

, Nordic Semiconductor .

Hier stellt sich die Hauptfrage, warum das neue SDK veröffentlicht wurde und wie es sich vom aktuellen unterscheidet. Wenn ja, ist mit der aktuellen Lösung alles in Ordnung.

Das aktuelle nRF5-SDK arbeitet auf der Grundlage einer einfachen Warteschlange. In den meisten Fällen reicht dies aus, um fast jede Aufgabe zu implementieren (obwohl einige Unternehmen immer noch ihre eigenen SDKs verwenden, dies sind jedoch Ausnahmen von den Regeln). Das neue nRF Connect SDK verwendet einen radikal anderen Ansatz, der auf Zephyr RTOS basiert. Betrachten Sie die Unterschiede genauer.
RTOS (RTOS) haben sowohl bestimmte Vor- als auch bekannte Nachteile. Letztere umfassen:

  • zusätzlicher Aufwand für die Wartung des Betriebssystems
  • große Komplexität der Entwicklung bei einfachen Projekten
  • erhöhte Build-Komplexität

Der Rest des RTOS sind:

  • Erhöhte Zuverlässigkeit durch Kontrolle der einzelnen Flüsse

Innerhalb von Nordic ist dies seit der Einführung des neuen Systems in Package (SIP) mit LTE Cat-M / NB-IoT / GPS - der nRF91-Serie - interessant und relevant geworden. Dieses SIP weist aufgrund des neuen Cortex-M33-Kerns und anderer Anforderungen an die Netzwerkkomponente, die aufgrund des Übergangs von BLE zu Mobilfunknetzen auftraten, eine höhere Leistung auf. Eine weitere Neuerung war das SDR-Modem, das auf einem separaten Kern arbeitet und mit dem die interne Interaktion organisiert werden musste. Zum ersten Mal erschien hier das RTOS-basierte SDK, und für diejenigen, die zum ersten Mal auf einen neuen Ansatz stießen, wurden bereits in der Vorbereitungsphase eine Reihe von Fragen aufgeworfen. Ein spezieller Assistent wurde ebenfalls für die korrekte Montage der Entwicklungsumgebung freigegeben - Getting Started Assistant. Er sagt Ihnen, welche Komponenten Sie installieren müssen (es gibt viele davon, siehe unten) und überprüft, ob alles korrekt installiert ist.

Bild

Unter diesem Gesichtspunkt können wir den Übergang zu Zephyr mit dem Auftreten des ersten Massen-ARM Cortex-M und dem Übergang zu 32 Bit vergleichen. Jetzt verwenden die meisten 32-Bit-MKs als Haupt-MKs, über die es einen Artikel über Habré gibt. Es wird auch über den Übergang berichtet, der anfangs unnötig kompliziert schien. Aber im Laufe der Zeit kamen fast alle zu dem Schluss, dass dies zum Standard geworden ist.

Es ist erwähnenswert, dass Zephyr OS nicht das einzige RTOS ist, das auf nordischen Chips ausgeführt wird. Beispiele für Projekte mit FreeRTOSAb 2016 in SDK v.11 verfügbar, und noch früher in SDK v.9 gab es Keil RTX-Unterstützung für die nRF51-Familie (2015). Früher waren dies jedoch eher experimentelle Funktionen, und die RTOS-Hersteller unterstützten sie in größerem Umfang. Was jetzt im Prinzip wahr ist.

Die inoffizielle Zephyr-Unterstützung für die nRF5x-Familien wurde bereits 2016 veröffentlicht .

Zephyr Nordic hat beschlossen, erst jetzt ein komplett neues SDK für RTOS zu erstellen.

Hierfür gibt es eine Reihe von Voraussetzungen:

  • Eine Reihe von Technologien werden von Linux geerbt:

    • Arbeiten Sie mit Streams und Warteschlangen in Echtzeit (besonders wichtig für zeitabhängige Protokolle wie BLE).
    • Bibliotheken für Netzwerk und Sicherheit
    • flexibles Hardwarebeschreibungsmodell mit Energieoptimierung
    • Bibliotheken für die Arbeit mit Peripheriegeräten (Sensoren usw.)

  • :




    • , Nordic,

  • ( )
  • ( ) . , , .

Um zu verstehen, wie dramatisch sich verändert hat, ist das Strukturdiagramm aus der offiziellen Dokumentation gut geeignet. Grau zeigt die Komponenten an, die Teil von Zephyr sind.

Bild

In der Praxis treten bei der Implementierung dieses Ansatzes eine Reihe kognitiver Probleme auf. Entwickler, die an das Produkt und die Lösungen gewöhnt sind, erleben Dissonanzen mit einer Vielzahl von Änderungen.

Betrachten Sie die Version der Entwicklung unter Windows, da dies weitere Fragen zu denjenigen aufwirft, die an die Entwicklung unter Linux gewöhnt sind.

Folgende Pakete sind erforderlich:

  • Chocolatey (Paketmanager)
  • Git (Versionskontrollsystem)
  • Ninja (geschwindigkeitsorientiertes Build-System)
  • CMake (High-Level-Build-System)
  • DTC-MSYS2 ( (device tree))
  • GPerf ( )
  • west ( )
  • pip ( Python)
  • Python3
  • GNU Arm Embedded Toolchain (GCC, GDB ARM)

Für diejenigen, die zum ersten Mal mit ähnlichen Versorgungsunternehmen konfrontiert sind, scheint es, dass alles unnötig kompliziert ist und das alte Paradigma verwendet werden könnte, dass die bestehenden Entwicklungsansätze sehr effektiv sind. Wenn Sie jedoch genauer hinschauen, wird alles viel interessanter.

Mit Chocolatey und pip können Sie beispielsweise alle erforderlichen Pakete über die Konsole für OS bzw. Python installieren. Und Python selbst ist, wie die meisten der fraglichen Software, in einem Befehl zusammengefasst:

hoco install python xxx

Es wird auch mit einem Befehl aktualisiert:

choco upgrade all

Der Ansatz ist für Windows-Benutzer etwas ungewöhnlich, für diejenigen, die mit Konsolenpaket-Managern unter Linux (apt, zypper usw.) vertraut sind, nichts Neues. Ich habe oft die Situation bemerkt, dass Softwareentwickler für MK Software nur aktualisieren, wenn sie das Betriebssystem auf einem PC neu installieren. Über warum es schlecht ist, werden wir nicht reden, ich stelle nur fest, dass hier dieses Problem automatisch gelöst wird.

Viel interessanter sind die Innovationen im Bereich Konfiguration und Montage von Projekten.

Ninja wurde als Ersatz für make entworfen und positioniert und konzentrierte sich auf die Build-Geschwindigkeit. Dies ist besonders gut in Anwendungen geeignet, wenn Projekte mit einer Reihe kleiner Dateien neu erstellt werden müssen, bei denen keine Änderungen vorgenommen wurden. Der Effekt kann eine Größenordnung oder sogar zwei betragen , siehe Tests .

CmakeIm Gegenzug können Konfigurationsdateien für Ninja in einer höheren Sprache (Skriptsprache) für die Plattform generiert werden, auf der die Assembly stattfinden soll. Über Cmake können auf Habré gelesen werden, zum Beispiel hier , hier und hier ,
gperf erzeugt eine Tabelle von Zeigern, die Speicher speichert, finden Sie in Schritt 3 der Baugruppe unten.

Wir sollten auch auf einen neuen Ansatz zur Beschreibung von Eisen achten. Es erschien ein Gerätebaum , der die Hardwarestruktur des Geräts beschreibt. Dies ist ein direktes Ergebnis der Unterstützung von Zephyr durch die Linux Foundation.

Die Pluspunkte sind, dass sich die Hardwarebeschreibung jetzt in einer separaten .dts-Datei befindet, die eine einfache Struktur hatEs ist einfach zu ändern und den Code zwischen verschiedenen Chipfamilien zu portieren.
Als Beispiel, wie viel ich das grundlegende dtsi auf nRF52840 klar veranschaulichen kann , das wiederum in der Beschreibung des nRF52840-DK nrf52840dk_nrf52840.dts-
Boards verwendet wird. Die Anzahl der von Zephyr unterstützten Motherboards liegt bereits bei über 200 .

Wie bereits erwähnt, hat Nordic Zephyr zuerst für die nRF91-Serie, dann für die nRF53 veröffentlicht, und jetzt hat es endlich den massivsten nRF52 erreicht.

Durch die Umstellung auf RTOS kann das Problem der Anpassung des Codes an neue Hardware gelöst werden. Selbst unter den Chips einer Familie erforderte der Übergang bestimmte Ressourcen von der Entwicklungsseite, wenn er von einem Übergang zu einem anderen Softdevice (vorkompilierte BLE-Bibliothek) begleitet wurde. Ganz zu schweigen vom Übergang beispielsweise von 51 oder 91 zu 52, wenn sich die Hardwareplattform selbst erheblich ändert. Jetzt wird diese Aufgabe viel einfacher und schneller gelöst.

Eisen bei Nordic wird ständig verbessert, dies muss jedoch separat geschrieben werden. Als Teil dieses Artikels können wir nur feststellen, dass der Schwerpunkt auf der Integration mit RTOS, Sicherheit, Energieeffizienz und Verbesserung des Funkkanals liegt (BLE 5.2). Vielen Dank können Sie sagen, die Dual-Core-Cortex-M33, ARM Cryptocell und ARM TrustZone.

Zum Erstellen von Gerätebaum verwendetDevice Tree Compiler , der Teil von MSYS2 ist (verbessertes Build-System basierend auf Cygwin und MinGW-64).

Der zweite Teil der Projektkonfiguration befindet sich in KConfig (Kernel-Konfiguration), die ebenfalls von Linux geerbt wurde. Sie können die erforderlichen Blöcke über eine grafische Oberfläche auswählen und Parameter für die Montage für eine bestimmte Aufgabe festlegen. Dies ist besonders wichtig bei begrenzten Ressourcen von Systemen auf einem Chip.

Sie können herkömmliche Dienstprogramme wie menuconfig verwenden oder im Rahmen von Segger Embedded Studio (der offiziell empfohlenen IDE) eine integrierte Schnittstelle verwenden, die über den entsprechenden Menüpunkt gestartet werden kann: Projekt> nRF Connect SDK-Projekt konfigurieren



Eine beispielhafte Projektkonfiguration mit SSL / TLS basierend auf nRF9160 ist unten dargestellt. Wie Sie darin sehen können, können Sie sowohl die Hardwarefunktionen des Projekts (Plattform, Anzahl der Threads, Plug-in-Kernelmodule) als auch die Software (Schlüssel, Adressen usw.) konfigurieren.





Betrachten Sie die Phasen der Projektmontage: Insgesamt gibt es fünf:

  • Konfiguration - Vorverarbeitung aller Konfigurationen (Gerätebaum, KConfig), am Ausgang erhalten wir Header-Dateien, die die Hardware und Konfiguration für Ninja beschreiben
  • Pre-Assembly (I) - Verarbeiten von Strukturen auf hoher Ebene, Kompilieren von Systemdateien und Offsets (Offset), Erstellen von Aufruftabellen
  • Erstmontage (II) - Zusammenstellung der Hauptquellcodes und deren Verpackung in Archive, Verknüpfung
  • (III) — (GPerf),
  • - (IV) — hex, bin

Weitere Informationen zum Zephyr-Montagesystem mit Bildern finden Sie in der offiziellen Dokumentation . Es gibt ziemlich viele Texte und Bilder, daher werden wir die Details im Rahmen dieses Artikels nicht berücksichtigen.
Es ist wichtig zu verstehen, dass die hier verwendeten Tools keinen Ersatz für den C-Präprozessor (cpp) und den C-Linker (ld) darstellen. Beide werden in allen Phasen außer der Nachbearbeitung verwendet. Das Ergebnis ihrer Arbeit unterliegt jedoch zusätzlichen Verbesserungen, die es ermöglichen, sowohl die Montagezeit als auch den Speicherbedarf erheblich zu reduzieren.

Sie können die Ergebnisse von Programmen, die mit zwei SDKs erstellt wurden, nicht direkt vergleichen. Da Bibliotheken und Ansätze sehr unterschiedlich sind und es solche Tests noch nicht gibt. Man kann definitiv sagen, dass sich die Lösung auf mittleren und oberen Chips der Linie (nRF52832 und höher) gut anfühlt, und es bleibt eine große Ressourcenreserve. Es kann jedoch nicht gesagt werden, dass das neue SDK nicht auf jüngere Chips wie nRF52810 anwendbar ist. Es ist notwendig, das Problem genauer zu betrachten.

Zurück zur Frage im Titel des Artikels können wir sagen, dass dieses Paradigma definitiv eine neue Realität ist. Was auf den ersten Blick deutliche Verbesserungen bringt. Mindestens 2 neue Chipfamilien des größten BLE-Herstellers der Welt arbeiten präzise und nur mit dieser Technologie und es wird keine Rendite erwartet. Meiner Meinung nach ist dies eine Revolution, die im Voraus vorbereitet wurde.

Update : Am 14. Mai hielt Nordic ein Webinar über das neue SDK ab, in dem angekündigt wurde, dass alle Versionen von BLE, die älter als 5.0 sind, nur im nRF Connect SDK verfügbar sein werden. Dementsprechend werden Directino Finding alias AoA / AoD (BLE 5.1) und LE Audio (BLE 5.2), auf die viele warten, dieses Jahr neue Tools mitbringen, und Änderungen in der Entwicklung werden früher als erwartet eintreten.

Ergebnisse:

  • Die Änderungen sind radikal, der Code, der mit dem aktuellen nRF5 SDK arbeitet, ist nicht mit dem neuen kompatibel (nRF Connect SDK)
  • Wenn Sie mit Devicetree und KConfig zu RTOS wechseln, erhalten Sie eine zusätzliche Abstraktionsebene für Hardware, was wiederum die Entwicklung und Übertragung des Projekts auf eine neue Plattform erheblich beschleunigt
  • Der Wechsel zu Zephyr bietet sofort Unterstützung für eine große Anzahl von Protokollen und Bibliotheken. Für IoT-Geräte sind die Netzwerk- und Sicherheitsfunktionen am interessantesten, bei denen Linux traditionell stark ist
  • Zephyr OS verwendet während der Montage eine Reihe von Werkzeugen, wodurch die Montagezeit und der Speicherbedarf erheblich reduziert werden können, was besonders für eingebettete Anwendungen wichtig ist
  • Das neue SDK ermöglicht die Verwendung von Entwicklern auf höherer Ebene, die viel mehr auf dem Markt sind als Entwickler auf niedriger Ebene. Dies löst das Problem des Personals und der Erhöhung des Marktanteils.

All Articles