Användningsscenarier för C SDK och Inbäddad C SDK
Microsoft tillhandahåller Azure IoT-enhets-SDK:er och mellanprogram för inbäddade och begränsade enhetsscenarier. Den här artikeln hjälper enhetsutvecklare att bestämma vilken som ska användas för ditt program.
Följande diagram visar fyra vanliga scenarier där kunder ansluter enheter till Azure IoT med hjälp av en C-baserad (C99) SDK. Resten av den här artikeln innehåller mer information om varje scenario.
Scenario 1 – Azure IoT C SDK (för Linux och Windows)
Från och med 2015 var Azure IoT C SDK det första Azure SDK som skapades för att ansluta enheter till IoT-tjänster. Det är en stabil plattform som har skapats för att tillhandahålla följande funktioner för att ansluta enheter till Azure IoT:
- IoT Hub-tjänster
- Enhetsetableringstjänstklienter
- Tre alternativ för kommunikationstransport (MQTT, AMQP och HTTP), som skapas och underhålls av Microsoft
- Flera val av vanliga TLS-staplar (OpenSSL, Schannel och Bed TLS enligt målplattformen)
- TCP-socketar (Win32, Berkeley eller Mbed)
Att tillhandahålla kommunikationstransport, TLS- och socketabstraktion har en prestandakostnad. Många sökvägar kräver malloc och memcpy anropar mellan de olika abstraktionsskikten. Den här prestandakostnaden är liten jämfört med ett skrivbord eller en Raspberry Pi-enhet. Men på en verkligt begränsad enhet blir kostnaden betydande omkostnader med möjlighet till minnesfragmentering. Kommunikationstransportlagret kräver också att en doWork funktion anropas minst var 100:e millisekunder. Dessa frekventa anrop gör det svårare att optimera SDK för batteridrivna enheter. Förekomsten av flera abstraktionslager gör det också svårt för kunder att använda eller ändra till ett visst bibliotek.
Scenario 1 rekommenderas för Windows- eller Linux-enheter, som normalt är mindre känsliga för minnesanvändning eller strömförbrukning. Windows- och Linux-baserade enheter kan dock också använda Embedded C SDK enligt scenario 2. Andra alternativ för Windows- och Linux-baserade enheter är de andra SDK:erna för Azure IoT-enheter: Java SDK, .NET SDK, Node SDK och Python SDK.
Scenario 2 – Inbäddad C SDK (för bare metal-scenarier och mikrostyrenheter)
År 2020 släppte Microsoft Azure SDK för Embedded C (även kallat Embedded C SDK). Denna SDK byggdes på kundernas feedback och ett växande behov av att stödja begränsade mikrostyrenhetsenheter. Vanligtvis har begränsade mikrostyrenheter mindre minne och processorkraft.
Embedded C SDK har följande viktiga egenskaper:
- Ingen dynamisk minnesallokering. Kunder måste allokera datastrukturer där de önskar, till exempel i globalt minne, en heap eller en stack. Sedan måste de skicka adressen till den allokerade strukturen till SDK-funktioner för att initiera och utföra olika åtgärder.
- Endast MQTT. Endast MQTT-användning är perfekt för begränsade enheter eftersom det är ett effektivt, lätt nätverksprotokoll. För närvarande stöds endast MQTT v3.1.1.
- Ta med din egen nätverksstack. Embedded C SDK utför inga I/O-åtgärder. Med den här metoden kan kunderna välja de MQTT-, TLS- och Socket-klienter som passar bäst för målplattformen.
- Liknande funktionsuppsättning som C SDK. Embedded C SDK innehåller liknande funktioner som Azure IoT C SDK, med följande undantag som Embedded C SDK inte tillhandahåller:
- Ladda upp till blob
- Möjligheten att köra som en IoT Edge-modul
- AMQP-baserade funktioner som batchbearbetning av innehållsmeddelanden och enhetsmultering
- Mindre övergripande fotavtryck. Embedded C SDK, som du ser i ett exempel som visar hur du ansluter till IoT Hub, kan ta så lite som 74 KB ROM och 8,26 KB RAM-minne.
Embedded C SDK stöder mikrostyrenheter utan operativsystem, mikrostyrenheter med ett realtidsoperativsystem (som Eclipse ThreadX), Linux och Windows. Kunder kan implementera anpassade plattformslager för att använda SDK på anpassade enheter. SDK:t innehåller även vissa plattformslager som Arduino och Swift. Microsoft uppmuntrar communityn att skicka in andra plattformslager för att öka de färdiga plattformar som stöds. Wind River VxWorks är ett exempel på ett plattformslager som skickas av communityn.
Embedded C SDK lägger till vissa programmeringsfördelar på grund av dess flexibilitet jämfört med Azure IoT C SDK. I synnerhet kommer program som använder begränsade enheter att dra nytta av enorma resursbesparingar och större programmatisk kontroll. Om du använder Eclipse ThreadX eller FreeRTOS kan du i jämförelse ha samma fördelar tillsammans med andra funktioner per RTOS-implementering.
Scenario 3 – Eclipse ThreadX med Azure IoT-mellanprogram (för Eclipse ThreadX-baserade projekt)
Scenario 3 omfattar användning av Eclipse ThreadX och Azure IoT-mellanprogrammet. Eclipse ThreadX bygger på Embedded C SDK och lägger till MQTT- och TLS-stöd. Mellanprogrammet för Eclipse ThreadX exponerar API:er för programmet som liknar de inbyggda Eclipse ThreadX-API:erna. Den här metoden gör det enklare för utvecklare att använda API:erna och ansluta sina Eclipse ThreadX-baserade enheter till Azure IoT. Eclipse ThreadX är en helt integrerad, effektiv inbäddad plattform i realtid som tillhandahåller alla nätverks- och IoT-funktioner som du behöver för din lösning.
Exempel för flera populära utvecklarpaket från ST, NXP, Renesas och Microchip finns tillgängliga. De här exemplen fungerar med Azure IoT Hub eller Azure IoT Central och är tillgängliga som IAR Workbench- eller halvledar-IDE-projekt på GitHub.
Eftersom den baseras på Embedded C SDK är Azure IoT-mellanprogrammet för Eclipse ThreadX inte minnesallokering. Kunder måste allokera SDK-datastrukturer i globalt minne, en heap eller en stack. När kunderna har allokerat en datastruktur måste de skicka strukturens adress till SDK-funktionerna för att initiera och utföra olika åtgärder.
Scenario 4 – FreeRTOS med FreeRTOS-mellanprogram (för användning med FreeRTOS-baserade projekt)
Scenario 4 tar det inbäddade C-mellanprogrammet till FreeRTOS. Det inbäddade C-mellanprogrammet bygger på Embedded C SDK och lägger till MQTT-stöd via coreMQTT-biblioteket med öppen källkod. Det här mellanprogrammet för FreeRTOS fungerar på MQTT-nivå. Den upprättar MQTT-anslutningen, prenumererar på och avbryter prenumerationer från ämnen och skickar och tar emot meddelanden. Frånkopplingar hanteras av kunden via mellanprogram-API:er.
Kunder styr TLS/TCP-konfigurationen och anslutningen till slutpunkten. Den här metoden ger flexibilitet mellan programvaru- eller maskinvaruimplementeringar av endera stacken. Inga bakgrundsuppgifter skapas av Azure IoT-mellanprogrammet för FreeRTOS. Meddelanden skickas och tas emot synkront.
Kärnimplementeringen tillhandahålls på den här GitHub-lagringsplatsen. Exempel för flera populära utvecklarpaket finns tillgängliga, inklusive NXP1060, STM32 och ESP32. Exemplen fungerar med Azure IoT Hub, Azure IoT Central och Azure Device Provisioning Service och är tillgängliga på den här GitHub-lagringsplatsen.
Eftersom den baseras på Azure Embedded C SDK är Azure IoT-mellanprogrammet för FreeRTOS även icke-minnesallokering. Kunder måste allokera SDK-datastrukturer i globalt minne, en heap eller en stack. När kunderna har allokerat en datastruktur måste de skicka adressen till de allokerade strukturerna till SDK-funktionerna för att initiera och utföra olika åtgärder.
Tekniska användningsscenarier för C-baserad SDK
Följande diagram sammanfattar tekniska alternativ för varje SDK-användningsscenario som beskrivs i den här artikeln.
C-baserad SDK-jämförelse med minne och protokoll
I följande tabell jämförs de fyra scenarierna för enhets-SDK-utveckling baserat på minnes- och protokollanvändning.
| Minne tilldelning |
Minne användning |
Protokoll stödd |
Rekommenderas för | |
|---|---|---|---|---|
| Azure IoT C SDK | Mestadels dynamisk | Obegränsad. Kan sträcka sig över till 1 MB eller mer i RAM-minne. |
AMQP HTTP MQTT v3.1.1 |
Mikroprocessorbaserade system Microsoft Windows Linux Apple OS X |
| Azure SDK för Embedded C | Endast statisk | Begränsas av mängden allokerar dataprogram. |
MQTT v3.1.1 | Mikrostyrenheter Implementeringar utan operativsystem RTOS-baserade implementeringar |
| Azure IoT Middleware för Eclipse ThreadX | Endast statisk | Begränsad | MQTT v3.1.1 | Mikrostyrenheter RTOS-baserade implementeringar |
| Azure IoT Middleware för FreeRTOS | Endast statisk | Begränsad | MQTT v3.1.1 | Mikrostyrenheter RTOS-baserade implementeringar |
Azure IoT-funktioner som stöds av varje SDK
I följande tabell jämförs de fyra scenarierna för enhets-SDK-utveckling baserat på stöd för Azure IoT-funktioner.
| Azure IoT C SDK | Azure SDK för Inbäddad C |
Azure IoT mellanprogram för Eclipse ThreadX |
Azure IoT mellanprogram för FreeRTOS |
|
|---|---|---|---|---|
| SAS-klientautentisering | Ja | Ja | Ja | Ja |
| x509-klientautentisering | Ja | Ja | Ja | Ja |
| Enhetsetablering | Ja | Ja | Ja | Ja |
| Telemetri | Ja | Ja | Ja | Ja |
| Meddelanden från moln till enhet | Ja | Ja | Ja | Ja |
| Direktmetoder | Ja | Ja | Ja | Ja |
| Enhetstvilling | Ja | Ja | Ja | Ja |
| IoT Plug-And-Play | Ja | Ja | Ja | Ja |
| Batchbearbetning av telemetri (AMQP, HTTP) |
Ja | Nej | Nej | Nej |
| Laddar upp till Azure Blob | Ja | Nej | Nej | Nej |
| Automatisk integrering i IoT Edge-värdbaserade containrar |
Ja | Nej | Nej | Nej |
Nästa steg
Mer information om enhetsutveckling och tillgängliga SDK:er för Azure IoT finns i följande tabell.
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för