C SDK- en Ingesloten C SDK-gebruiksscenario's
Microsoft biedt AZURE IoT-apparaat-SDK's en middleware voor ingesloten en beperkte apparaatscenario's. Dit artikel helpt ontwikkelaars van apparaten te bepalen welke moet worden gebruikt voor uw toepassing.
In het volgende diagram ziet u vier veelvoorkomende scenario's waarin klanten apparaten verbinden met Azure IoT, met behulp van een C99-SDK (C99). De rest van dit artikel bevat meer informatie over elk scenario.
Scenario 1: Azure IoT C SDK (voor Linux en Windows)
Vanaf 2015 was Azure IoT C SDK de eerste Azure SDK die is gemaakt om apparaten te verbinden met IoT-services. Het is een stabiel platform dat is gebouwd om de volgende mogelijkheden te bieden voor het verbinden van apparaten met Azure IoT:
- IoT Hub-services
- Device Provisioning Service-clients
- Drie keuzes voor communicatietransport (MQTT, AMQP en HTTP), die door Microsoft worden gemaakt en onderhouden
- Meerdere opties van algemene TLS-stacks (OpenSSL, Schannel en Bed TLS op basis van het doelplatform)
- TCP-sockets (Win32, Berkeley of Mbed)
Het leveren van communicatietransport, TLS en socketabstractie heeft een prestatiekosten. Veel paden vereisen en memcpy aanroepen malloc tussen de verschillende abstractielagen. Deze prestatiekosten zijn klein vergeleken met een desktop- of Raspberry Pi-apparaat. Maar op een echt beperkt apparaat worden de kosten aanzienlijk overhead met de mogelijkheid van geheugenfragmentatie. Voor de communicatietransportlaag moet ook ten minste elke 100 milliseconden een doWork functie worden aangeroepen. Deze frequente aanroepen maken het moeilijker om de SDK te optimaliseren voor apparaten met accu's. Het bestaan van meerdere abstractielagen maakt het ook moeilijk voor klanten om een bepaalde bibliotheek te gebruiken of te wijzigen.
Scenario 1 wordt aanbevolen voor Windows- of Linux-apparaten, die normaal gesproken minder gevoelig zijn voor geheugengebruik of energieverbruik. Windows- en Linux-apparaten kunnen echter ook de Embedded C SDK gebruiken, zoals wordt weergegeven in Scenario 2. Andere opties voor Windows- en Linux-apparaten zijn de andere SDK's voor Azure IoT-apparaten: Java SDK, .NET SDK, Node SDK en Python SDK.
Scenario 2 – Embedded C SDK (voor Bare Metal-scenario's en microcontrollers)
In 2020 heeft Microsoft de Azure SDK voor Embedded C uitgebracht (ook wel de Embedded C SDK genoemd). Deze SDK is gebouwd op basis van feedback van klanten en een groeiende behoefte aan ondersteuning van beperkte microcontrollerapparaten. Normaal gesproken hebben beperkte microcontrollers minder geheugen en verwerkingskracht.
De Embedded C SDK heeft de volgende belangrijke kenmerken:
- Er is geen dynamische geheugentoewijzing. Klanten moeten gegevensstructuren toewijzen waar ze behoefte aan hebben, zoals in het globale geheugen, een heap of een stack. Vervolgens moeten ze het adres van de toegewezen structuur doorgeven aan SDK-functies om verschillende bewerkingen te initialiseren en uit te voeren.
- Alleen MQTT. Alleen MQTT-gebruik is ideaal voor beperkte apparaten omdat het een efficiënt, lichtgewicht netwerkprotocol is. Momenteel wordt alleen MQTT v3.1.1 ondersteund.
- Bring your own network stack. De Embedded C SDK voert geen I/O-bewerkingen uit. Met deze aanpak kunnen klanten de MQTT-, TLS- en Socket-clients selecteren die het beste bij hun doelplatform passen.
- Vergelijkbare functieset als de C SDK. De Embedded C SDK biedt vergelijkbare functies als de Azure IoT C SDK, met de volgende uitzonderingen die de Embedded C SDK niet biedt:
- Uploaden naar blob
- De mogelijkheid om te worden uitgevoerd als een IoT Edge-module
- Op AMQP gebaseerde functies, zoals batchverwerking van inhoudsberichten en multiplexing van apparaten
- Kleinere totale voetafdruk. De Embedded C SDK, zoals u kunt zien in een voorbeeld dat laat zien hoe u verbinding maakt met IoT Hub, kan 74 kB ROM en 8,26 KB RAM-geheugen in beslag nemen.
De Embedded C SDK ondersteunt microcontrollers zonder besturingssysteem, microcontrollers met een realtime besturingssysteem (zoals Eclipse ThreadX), Linux en Windows. Klanten kunnen aangepaste platformlagen implementeren om de SDK te gebruiken op aangepaste apparaten. De SDK biedt ook enkele platformlagen, zoals Arduino en Swift. Microsoft moedigt de community aan om andere platformlagen in te dienen om de kant-en-klare ondersteunde platforms te verhogen. Wind River VxWorks is een voorbeeld van een platformlaag die door de community wordt ingediend.
De Embedded C SDK voegt enkele programmeervoordelen toe vanwege de flexibiliteit in vergelijking met de Azure IoT C SDK. Met name toepassingen die gebruikmaken van beperkte apparaten profiteren van enorme besparingen op resources en een grotere programmatische controle. Ter vergelijking: als u Eclipse ThreadX of FreeRTOS gebruikt, kunt u dezelfde voordelen hebben, samen met andere functies per RTOS-implementatie.
Scenario 3: Eclipse ThreadX met Azure IoT middleware (voor Op Eclipse ThreadX gebaseerde projecten)
Scenario 3 omvat het gebruik van Eclipse ThreadX en de Azure IoT-middleware. Eclipse ThreadX is gebouwd boven op de Embedded C SDK en voegt MQTT- en TLS-ondersteuning toe. De middleware voor Eclipse ThreadX maakt API's beschikbaar voor de toepassing die vergelijkbaar is met de systeemeigen Eclipse ThreadX-API's. Deze aanpak maakt het eenvoudiger voor ontwikkelaars om de API's te gebruiken en hun Eclipse ThreadX-apparaten te verbinden met Azure IoT. Eclipse ThreadX is een volledig geïntegreerd, efficiënt, realtime ingesloten platform dat alle netwerk- en IoT-functies biedt die u nodig hebt voor uw oplossing.
Voorbeelden voor verschillende populaire ontwikkelaarskits van ST, NXP, Renesas en Microchip zijn beschikbaar. Deze voorbeelden werken met Azure IoT Hub of Azure IoT Central en zijn beschikbaar als IAR Workbench- of halfgeleider IDE-projecten op GitHub.
Omdat deze is gebaseerd op de Embedded C SDK, is de Azure IoT-middleware voor Eclipse ThreadX niet-geheugentoewijzing. Klanten moeten SDK-gegevensstructuren toewijzen in het globale geheugen, een heap of een stack. Nadat klanten een gegevensstructuur hebben toegewezen, moeten ze het adres van de structuur doorgeven aan de SDK-functies om verschillende bewerkingen te initialiseren en uit te voeren.
Scenario 4 : FreeRTOS met FreeRTOS middleware (voor gebruik met projecten op basis van FreeRTOS)
Scenario 4 brengt de ingesloten C-middleware naar FreeRTOS. De ingesloten C-middleware is gebouwd op de Embedded C SDK en voegt MQTT-ondersteuning toe via de open source coreMQTT-bibliotheek. Deze middleware voor FreeRTOS werkt op MQTT-niveau. Hiermee wordt de MQTT-verbinding tot stand gebracht, worden onderwerpen geabonneerd en afgemeld en worden berichten verzonden en ontvangen. Verbroken verbindingen worden verwerkt door de klant via middleware-API's.
Klanten beheren de TLS/TCP-configuratie en -verbinding met het eindpunt. Deze aanpak biedt flexibiliteit tussen software- of hardware-implementaties van beide stacks. Er worden geen achtergrondtaken gemaakt door de Azure IoT-middleware voor FreeRTOS. Berichten worden synchroon verzonden en ontvangen.
De kernimplementatie vindt u in deze GitHub-opslagplaats. Voorbeelden voor verschillende populaire ontwikkelaarskits zijn beschikbaar, waaronder de NXP1060, STM32 en ESP32. De voorbeelden werken met Azure IoT Hub, Azure IoT Central en Azure Device Provisioning Service en zijn beschikbaar in deze GitHub-opslagplaats.
Omdat deze is gebaseerd op de Azure Embedded C SDK, wordt de Azure IoT-middleware voor FreeRTOS ook niet-geheugentoewijzingen. Klanten moeten SDK-gegevensstructuren toewijzen in het globale geheugen, een heap of een stack. Nadat klanten een gegevensstructuur hebben toegewezen, moeten ze het adres van de toegewezen structuren doorgeven aan de SDK-functies om verschillende bewerkingen te initialiseren en uit te voeren.
Scenario's voor technisch gebruik van C-SDK's
In het volgende diagram ziet u een overzicht van de technische opties voor elk SDK-gebruiksscenario dat in dit artikel wordt beschreven.
Vergelijking van op C gebaseerde SDK op basis van geheugen en protocollen
In de volgende tabel worden de vier ontwikkelscenario's voor de apparaat-SDK vergeleken op basis van geheugen- en protocolgebruik.
| Geheugen toewijzing |
Geheugen gebruik |
Protocollen ondersteund |
Aanbevolen voor | |
|---|---|---|---|---|
| Azure IoT C SDK | Meestal dynamisch | Onbeperkt. Kan overspannen tot 1 MB of meer in ram-geheugen. |
AMQP HTTP MQTT v3.1.1 |
Op microprocessor gebaseerde systemen Microsoft Windows Linux Apple OS X |
| Azure SDK voor Embedded C | Alleen statisch | Beperkt door het aantal gegevenstoepassing wijst toe. |
MQTT v3.1.1 | Microcontrollers Bare-metal-implementaties Implementaties op basis van RTOS |
| Azure IoT Middleware voor Eclipse ThreadX | Alleen statisch | Beperkt | MQTT v3.1.1 | Microcontrollers Implementaties op basis van RTOS |
| Azure IoT Middleware voor FreeRTOS | Alleen statisch | Beperkt | MQTT v3.1.1 | Microcontrollers Implementaties op basis van RTOS |
Azure IoT-functies die door elke SDK worden ondersteund
In de volgende tabel worden de vier ontwikkelscenario's voor de SDK van het apparaat vergeleken op basis van ondersteuning voor Azure IoT-functies.
| Azure IoT C SDK | Azure SDK voor Ingesloten C |
Azure IoT middleware voor Eclipse ThreadX |
Azure IoT middleware voor FreeRTOS |
|
|---|---|---|---|---|
| SAS-clientverificatie | Ja | Ja | Ja | Ja |
| x509-clientverificatie | Ja | Ja | Ja | Ja |
| Apparaatinrichting | Ja | Ja | Ja | Ja |
| Telemetrie | Ja | Ja | Ja | Ja |
| Cloud-naar-apparaat-berichten | Ja | Ja | Ja | Ja |
| Directe methoden | Ja | Ja | Ja | Ja |
| Apparaatdubbel | Ja | Ja | Ja | Ja |
| IoT Plug-And-Play | Ja | Ja | Ja | Ja |
| Telemetrie batchverwerking (AMQP, HTTP) |
Ja | No | No | Nr. |
| Uploadt naar Azure Blob | Ja | No | No | Nr. |
| Automatische integratie in Gehoste IoT Edge-containers |
Ja | No | No | Nr. |
Volgende stappen
Zie de volgende tabel voor meer informatie over apparaatontwikkeling en de beschikbare SDK's voor Azure IoT.