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, zu entscheiden, welche sie für ihre Anwendung verwenden sollten.
Das folgende Diagramm zeigt vier häufige Szenarien, in denen Kunden Geräte mit Azure IoT verbinden, wobei ein C-basiertes (C99) SDK verwendet wird. Der Rest dieses Artikels enthält weitere Details zu jedem Szenario.
Szenario 1 – Azure IoT C SDK (für Linux und Windows)
Ab 2015 war Azure IoT C SDK das erste Azure-SDK, das zum Verbinden von Geräten mit IoT-Diensten erstellt wurde. Es handelt sich um eine stabile Plattform, die erstellt wurde, um die folgenden Funktionen für die Verbindung von Geräten mit Azure IoT bereitzustellen:
- IoT Hub-Dienste
- Gerätebereitstellungsdienst-Clients
- Drei Auswahlmöglichkeiten des Kommunikationstransports (MQTT, AMQP und HTTP), die von Microsoft erstellt und verwaltet werden
- Mehrere Wahlmöglichkeiten aus gängigen TLS-Stapeln (OpenSSL, Schannel und Bed TLS, je nach der Zielplattform)
- TCP-Sockets (Win32, Berkeley oder Mbed)
Die Bereitstellung von Kommunikationstransport, TLS und Socket-Abstraktion bringt Leistungskosten mit sich. 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. Doch auf einem wirklich eingeschränkten Gerät wird der Kostenaufwand mit der Möglichkeit der Speicherfragmentierung erheblich. 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. Die Existenz 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 Arbeitsspeichernutzung 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 umfassen die anderen Azure IoT-Geräte-SDKs: Java SDK, .NET SDK, Node SDK und Python SDK.
Szenario 2 – Embedded C SDK (für Bare-Metal-Szenarien und Mikrocontroller)
Im Jahr 2020 veröffentlichte Microsoft das Azure-SDK für Embedded C (auch bekannt als Embedded C SDK). 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 verfügt über die folgenden wichtigsten Merkmale:
- Keine dynamische Speicherbelegung. Kunden müssen Datenstrukturen je nach Bedarf zuordnen, wie etwa in globalem Speicher, einem Heap oder einem Stapel. Sie müssen dann die Adresse der zugewiesenen Struktur an SDK-Funktionen weitergeben, um diverse Abläufe zu initialisieren und durchzuführen.
- Nur MQTT. Ausschließlich MQTT-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.
- Verwendung eigener Netwerkstapel. Das Embedded C SDK führt keine E/A-Vorgänge aus. Mit diesem Ansatz können Kunden die MQTT-, TLS- und Socket-Clients auswählen, die am besten zu ihrer Zielplattform passen.
- Ein ähnliches Featureset wie das C SDK. Das Embedded C SDK bietet ähnliche Features wie das Azure IoT C SDK, mit den folgenden Ausnahmen, die das Embedded C SDK nicht bereitstellt:
- In Blob hochladen
- Die Möglichkeit der Ausführung als IoT Edge-Modul
- AMQP-basierte Features wie Inhaltsnachrichten-Batchverarbeitung und Gerätemultiplexing
- Ein insgesamt schlankeres Profil. Das Eingebettete C SDK, wie in einem Beispiel dargestellt, in dem gezeigt wird, wie eine Verbindung mit IoT Hub hergestellt wird, kann nur 74 KB ROM und 8,26 KB RAM erfordern.
Das Embedded C-SDK unterstützt Mikrocontroller ohne Betriebssystem, Mikrocontroller mit einem Echtzeitbetriebssystem (wie Eclipse ThreadX), Linux und Windows. Kunden können benutzerdefinierte Plattformschichten implementieren, um das SDK auf benutzerdefinierten Geräten zu verwenden. Das SDK bietet außerdem einige Plattformebenen wie Arduino, und Swift. Wir bieten einige Plattformschichten an und ermutigen die Community, Plattformschichten einzureichen, um die Anzahl der unterstützten Plattformen zu erhöhen. Wind River VxWorks ist ein Beispiel für eine Plattformebene, die von der Community eingereicht wurde.
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 programmatischen Steuerung. Im Vergleich dazu können Sie, wenn Sie Eclipse ThreadX oder FreeRTOS verwenden, die gleichen Vorteile zusammen mit anderen Features mit der RTOS-Implementierung erhalten.
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-Support hinzu. Die Middleware für Eclipse ThreadX macht APIs für die Anwendung verfügbar, die mit den systemeigenen Eclipse ThreadX-APIs vergleichbar sind. Durch diesen Ansatz können Entwicklerinnen und Entwickler die APIs verwenden und ihre Eclipse ThreadX-basierten Geräte mit Azure IoT verbinden. Eclipse ThreadX ist eine vollständig integrierte, effiziente, in Echtzeit eingebettete Plattform, die alle Netzwerk- und IoT-Features 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 Embedded C-SDK basiert, weist die Azure IoT-Middleware für Eclipse ThreadX keinen Arbeitsspeicher zu. Kunden müssen SDK-Datenstrukturen im globalen Arbeitsspeicher oder einem Heap oder einem Stapel zuordnen. 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 baut auf dem Embedded C SDK auf und fügt MQTT-Unterstützung über die Open-Source-coreMQTT-Bibliothek hinzu. Diese Middleware für FreeRTOS arbeitet auf MQTT-Ebene. Es richtet die MQTT-Verbindung ein, abonniert und bestellt Themen ab und sendet und empfängt Nachrichten. Verbindungstrennungen werden vom Kunden über Middleware-APIs gehandhabt.
Kunden steuern die TLS/TCP-Konfiguration und die Verbindung mit dem Endpunkt. Dieser Ansatz ermöglicht Flexibilität zwischen Software- oder Hardwareimplementierungen eines Stapels. Es werden keine Hintergrundaufgaben von der Azure IoT-Middleware für FreeRTOS erstellt. Nachrichten werden synchron gesendet und empfangen.
Die Kernimplementierung wird in diesem GitHub-Repository bereitgestellt. Beispiele für mehrere beliebte Entwicklerkits sind verfügbar, einschließlich NXP1060, STM32 und ESP32. Die Beispiele funktionieren mit Azure IoT Hub, Azure IoT Central und dem Azure-Gerätebereitstellungsservice und sind in diesem GitHub-Repository verfügbar.
Da sie auf Embedded C SDK basiert, weist die Azure IoT-Middleware für Azure RTOS keinen Arbeitsspeicher zu. Kunden müssen SDK-Datenstrukturen im globalen Arbeitsspeicher oder einem Heap oder einem Stapel zuordnen. 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.
Technische Nutzungsszenarien für C-basiertes SDK
Das folgende Diagramm fasst technische Optionen für jedes in diesem Artikel beschriebene SDK-Nutzungsszenario zusammen.
C-basiertes SDK – Vergleich nach Arbeitsspeicher und Protokollen
In der folgenden Tabelle werden die vier Geräte-SDK-Entwicklungsszenarien basierend auf Arbeitsspeicher- und Protokollnutzung verglichen.
| Arbeitsspeicher Zuteilung |
Arbeitsspeicher Nutzung |
Protokolle unterstützt |
Empfohlen für | |
|---|---|---|---|---|
| Azure IoT C SDK | Meist dynamisch | Unrestricted. Kann bis zu 1 MB oder mehr an RAM umfassen. |
AMQP HTTP MQTT v3.1.1 |
Mikroprozessorbasierte Systeme Microsoft Windows Linux Apple OS X |
| Azure SDK für Embedded C | Nur statisch | Eingeschränkt nach der Menge, die von Datenanwendung zugewiesen wird. |
MQTT v3.1.1 | Mikrocontroller Bare-Metal-Implementierungen RTOS-basierte Implementierungen |
| Azure IoT-Middleware für Eclipse ThreadX | Nur statisch | Eingeschränkt | MQTT v3.1.1 | Mikrocontroller RTOS-basierte Implementierungen |
| Azure IoT-Middleware für FreeRTOS | Nur statisch | Eingeschränkt | MQTT v3.1.1 | Mikrocontroller RTOS-basierte Implementierungen |
Azure IoT-Features, die von jedem SDK unterstützt werden
In der folgenden Tabelle werden die vier Geräte-SDK-Entwicklungsszenarien basierend auf Unterstützung fr Azure IoT-Features verglichen.
| Azure IoT C SDK | Azure-SDK für Embedded C |
Azure IoT Middleware für Eclipse ThreadX |
Azure IoT Middleware für FreeRTOS |
|
|---|---|---|---|---|
| SAS-Clientauthentifizierung | Ja | Ja | Ja | Ja |
| x509-Clientauthentifizierung | Ja | Ja | Ja | Ja |
| Gerätebereitstellungs- | Ja | Ja | Ja | Ja |
| Telemetrie | Ja | Ja | Ja | Ja |
| Cloud-zu-Gerät-Nachrichten | Ja | Ja | Ja | Ja |
| Direkte Methoden | Ja | Ja | Ja | Ja |
| Gerätezwilling | Ja | Ja | Ja | Ja |
| IoT Plug & Play | Ja | Ja | Ja | Ja |
| Telemetriebatching (AMQP, HTTP) |
Ja | Nr. | Nr. | No |
| Uploads in Azure Blob | Ja | Nr. | Nr. | No |
| Automatische Integration in auf IoT Edge gehostete Container |
Ja | Nr. | Nr. | Nein |
Nächste Schritte
Weitere Informationen zur Geräteentwicklung und den verfügbaren SDKs für Azure IoT finden Sie in der folgenden Tabelle.