Nutzungsszenarien für das C SDK und Embedded C SDK

Microsoft stellt Azure IoT-Geräte-SDKs und Middleware für eingebettete und eingeschränkte Geräteszenarien bereit. Dieser Artikel hilft Geräteentwicklern bei der Entscheidung, welche Für Ihre Anwendung verwendet werden soll.

Das folgende Diagramm zeigt vier häufige Szenarien, in denen Kunden Geräte mit Azure IoT verbinden und dabei ein C-basiertes SDK (C99) verwenden. Der Rest dieses Artikels enthält weitere Details zu den einzelnen Szenarien.

Szenario 1 – Azure IoT C SDK (für Linux und Windows)

Ab 2015 wurde das Azure IoT C SDK als erstes Azure SDK erstellt, um Geräte mit IoT-Diensten zu verbinden. Es handelt sich um eine stabile Plattform, die entwickelt wurde, um die folgenden Funktionen zum Verbinden von Geräten mit Azure IoT bereitzustellen:

• IoT Hub-Dienste
• Clients des Gerätebereitstellungsdienstes
• Drei Auswahlmöglichkeiten des Kommunikationstransports (MQTT, AMQP und HTTP), die von Microsoft erstellt und verwaltet werden
• Mehrere Auswahlmöglichkeiten allgemeiner TLS-Stapel (OpenSSL, Schannel und Bed TLS entsprechend der Zielplattform)
• TCP-Sockets (Win32, Berkeley oder Mbed)

Die Bereitstellung von Kommunikationstransport, TLS und Socket-Abstraktion verursacht Leistungskosten. Viele Pfade erfordern malloc und memcpy Aufrufe zwischen den verschiedenen Abstraktionsebenen. Diese Leistungskosten sind klein im Vergleich zu einem Desktop oder einem Raspberry Pi-Gerät. Auf einem wirklich eingeschränkten Gerät wird der Aufwand jedoch zu erheblichem Overhead mit der Möglichkeit der Speicherfragmentierung. Die Kommunikationstransportschicht erfordert außerdem, dass mindestens alle 100 Millisekunden eine doWork Funktion aufgerufen wird. Diese häufigen Aufrufe erschweren es, das SDK für akkubetriebene Geräte zu optimieren. Das Vorhandensein mehrerer Abstraktionsebenen macht es auch für Kunden schwierig, eine bestimmte Bibliothek zu verwenden oder zu ändern.

Szenario 1 wird für Windows- oder Linux-Geräte empfohlen, die normalerweise weniger empfindlich für die Speicherauslastung oder den Stromverbrauch sind. Windows- und Linux-basierte Geräte können jedoch auch das embedded C SDK verwenden, wie in Szenario 2 dargestellt. Weitere Optionen für Windows- und Linux-basierte Geräte sind die anderen Azure IoT-Geräte-SDKs: Java SDK, .NET SDK, Node SDK und Python SDK.

Szenario 2 – Eingebettetes C SDK (für Bare Metal-Szenarien und Mikrocontroller)

Im Jahr 2020 veröffentlichte Microsoft das Azure SDK für Embedded C (auch als Embedded C SDK bezeichnet). Dieses SDK basiert auf Kundenfeedback und einer wachsenden Notwendigkeit, eingeschränkte Mikrocontrollergeräte zu unterstützen. In der Regel haben eingeschränkte Mikrocontroller weniger Arbeitsspeicher und Verarbeitungsleistung.

Das Embedded C SDK weist die folgenden wichtigsten Merkmale auf:

• Keine dynamische Speicherzuweisung. Kunden müssen Datenstrukturen dort zuordnen, wo sie es wünschen, z. B. im globalen Speicher, einem Heap oder einem Stack. Anschließend müssen sie die Adresse der zugeordneten Struktur an SDK-Funktionen übergeben, um verschiedene Vorgänge zu initialisieren und auszuführen.
• nur MQTT MQTT-only-Verwendung eignet sich ideal für eingeschränkte Geräte, da es sich um ein effizientes, einfaches Netzwerkprotokoll handelt. Derzeit wird nur MQTT v3.1.1 unterstützt.
• Bringen Sie Ihren eigenen Netzwerkstack mit. Das Eingebettete C SDK führt keine E/A-Vorgänge aus. Mit diesem Ansatz können Kunden die MQTT-, TLS- und Socketclients auswählen, die am besten zu ihrer Zielplattform passen.
• Ähnliches Featureset wie das C SDK. Das Embedded C SDK bietet ähnliche Features wie das Azure IoT C SDK mit den folgenden Ausnahmen, die vom Embedded C SDK nicht bereitgestellt werden:
  • In BLOB hochladen
  • Die Möglichkeit zum Ausführen als IoT Edge-Modul
  • AMQP-basierte Funktionen wie Batchverarbeitung von Inhaltsnachrichten und Geräte-Multiplexing
• Kleinere Gesamtgröße. Das Embedded C SDK, wie in einem Beispiel gezeigt, das zeigt, wie eine Verbindung zum IoT Hub hergestellt wird, benötigt bis zu 74 KB ROM und 8,26 KB RAM.

Das Embedded C SDK unterstützt Mikrocontroller ohne Betriebssystem, Mikrocontroller mit einem Echtzeitbetriebssystem (wie Eclipse ThreadX), Linux und Windows. Kunden können benutzerdefinierte Plattformebenen implementieren, um das SDK auf benutzerdefinierten Geräten zu verwenden. Das SDK bietet auch einige Plattformebenen wie Arduino und Swift. Microsoft ermutigt die Community, andere Plattformebenen zu übermitteln, um die sofort einsatzbereiten unterstützten Plattformen zu erhöhen. Wind River VxWorks ist ein Beispiel für eine Plattformebene, die von der Community eingereicht wird.

Das Embedded C SDK bietet aufgrund seiner Flexibilität im Vergleich zum Azure IoT C SDK einige Programmiervorteile. Insbesondere Anwendungen, die eingeschränkte Geräte verwenden, profitieren von enormen Ressourceneinsparungen und einer größeren programmgesteuerten Steuerung. Wenn Sie Eclipse ThreadX oder FreeRTOS verwenden, können Sie die gleichen Vorteile zusammen mit anderen Features pro RTOS-Implementierung haben.

Szenario 3 – Eclipse ThreadX mit Azure IoT Middleware (für Eclipse ThreadX-basierte Projekte)

Szenario 3 umfasst die Verwendung von Eclipse ThreadX und der Azure IoT-Middleware. Eclipse ThreadX basiert auf dem Embedded C SDK und fügt MQTT- und TLS-Unterstützung hinzu. Die Middleware für Eclipse ThreadX macht APIs für die Anwendung verfügbar, die den nativen Eclipse ThreadX-APIs ähneln. Dieser Ansatz vereinfacht es Entwicklern, die APIs zu verwenden und ihre Eclipse ThreadX-basierten Geräte mit Azure IoT zu verbinden. Eclipse ThreadX ist eine vollständig integrierte, effiziente, in Echtzeit eingebettete Plattform, die alle Netzwerk- und IoT-Funktionen bereitstellt, die Sie für Ihre Lösung benötigen.

Beispiele für mehrere beliebte Entwicklerkits von ST, NXP, Renesas und Microchip sind verfügbar. Diese Beispiele funktionieren mit Azure IoT Hub oder Azure IoT Central und sind als IAR Workbench- oder Halbleiter-IDE-Projekte auf GitHub verfügbar.

Da sie auf dem Embedded C SDK basiert, ist die Azure IoT-Middleware für Eclipse ThreadX nicht speicherfrei. Kunden müssen SDK-Datenstrukturen im globalen Speicher, einem Heap oder einem Stack zuweisen. Nachdem Kunden eine Datenstruktur zugewiesen haben, müssen sie die Adresse der Struktur an die SDK-Funktionen übergeben, um verschiedene Vorgänge zu initialisieren und auszuführen.

Szenario 4 – FreeRTOS mit FreeRTOS-Middleware (für die Verwendung mit FreeRTOS-basierten Projekten)

Szenario 4 bringt die eingebettete C-Middleware zu FreeRTOS. Die eingebettete C-Middleware basiert auf dem Embedded C SDK und fügt MQTT-Unterstützung über die Open Source CoreMQTT-Bibliothek hinzu. Diese Middleware für FreeRTOS funktioniert auf MQTT-Ebene. Es stellt die MQTT-Verbindung her, abonniert Themen, abbestellt Themen und sendet und empfängt Nachrichten. Die Trennungen werden vom Kunden über Middleware-APIs verarbeitet.

Kunden steuern die TLS/TCP-Konfiguration und die Verbindung mit dem Endpunkt. Dieser Ansatz ermöglicht Flexibilität zwischen Software- und Hardwareimplementierungen eines Stacks. Von der Azure IoT-Middleware für FreeRTOS werden keine Hintergrundaufgaben erstellt. Nachrichten werden synchron gesendet und empfangen.

Die Kernimplementierung wird in diesem GitHub-Repository bereitgestellt. Beispiele für mehrere beliebte Entwicklerkits sind verfügbar, darunter die NXP1060, STM32 und ESP32. Die Beispiele funktionieren mit Azure IoT Hub, Azure IoT Central und Azure Device Provisioning Service und sind in diesem GitHub-Repository verfügbar.

Da sie auf dem Azure Embedded C SDK basiert, ist auch die Azure IoT-Middleware für FreeRTOS speicherzuteilungsfrei. Kunden müssen SDK-Datenstrukturen im globalen Speicher, einem Heap oder einem Stack zuweisen. Nachdem Kunden eine Datenstruktur zugewiesen haben, müssen sie die Adresse der zugeordneten Strukturen an die SDK-Funktionen übergeben, um verschiedene Vorgänge zu initialisieren und auszuführen.

Szenarien für die technische Verwendung des C-basierten SDK

Das folgende Diagramm fasst technische Optionen für jedes in diesem Artikel beschriebene SDK-Verwendungsszenario zusammen.

C-basiertes SDK-Vergleich nach Speicher und Protokollen

In der folgenden Tabelle werden die vier Geräte-SDK-Entwicklungsszenarien verglichen, die auf der Speicher- und Protokollverwendung basieren.

Von jedem SDK unterstützte Azure IoT-Features

In der folgenden Tabelle werden die vier Geräte-SDK-Entwicklungsszenarien verglichen, die auf der Unterstützung von Azure IoT-Features basieren.

Nächste Schritte

Weitere Informationen zur Geräteentwicklung und den verfügbaren SDKs für Azure IoT finden Sie in der folgenden Tabelle.

• Azure IoT-Geräteentwicklung
• Welches SDK sollte ich verwenden?