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 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.
Skapa lösningar från slutpunkt till slutpunkt i Microsoft Azure för att skapa Azure Functions, implementera och hantera webbappar, utveckla lösningar som använder Azure Storage med mera.
Den här självstudien visar enhetsutvecklare hur de ansluter en enhet på ett säkert sätt till Azure IoT Hub. Du använder en Azure IoT-enhets-SDK för C, C#, Python, Node.js eller Java för att skapa en enhetsklient för Windows, Linux eller Raspberry Pi (Raspbian). Sedan ansluter och skickar du telemetri.
En översikt över Azure IoT-tillgångs- och enhetsutveckling, inklusive en introduktion till enhets-SDK:er, modellering, IoT Edge-moduler och en undersökning av tillgängliga verktyg.