Udostępnij za pośrednictwem


Scenariusze użycia zestawu SDK języka C i osadzonego zestawu C SDK

Firma Microsoft udostępnia zestawy SDK urządzeń IoT platformy Azure i oprogramowanie pośredniczące dla scenariuszy osadzonych i ograniczonych urządzeń. Ten artykuł ułatwia deweloperom urządzeń podjęcie decyzji o tym, który z nich ma być używany w aplikacji.

Na poniższym diagramie przedstawiono cztery typowe scenariusze, w których klienci łączą urządzenia z usługą Azure IoT przy użyciu zestawu SDK opartego na języku C (C99). Pozostała część tego artykułu zawiera więcej szczegółów na temat każdego scenariusza.

Diagram typowych scenariuszy zestawu SDK.

Scenariusz 1 — zestaw SDK języka C usługi Azure IoT (dla systemów Linux i Windows)

Począwszy od 2015 r., zestaw AZURE IoT C SDK był pierwszym zestawem Azure SDK utworzonym w celu łączenia urządzeń z usługami IoT. Jest to stabilna platforma, która została utworzona, aby zapewnić następujące możliwości łączenia urządzeń z usługą Azure IoT:

  • Usługi IoT Hub
  • Klienci usługi Device Provisioning Service
  • Trzy opcje transportu komunikacyjnego (MQTT, AMQP i HTTP), które są tworzone i obsługiwane przez firmę Microsoft
  • Wiele opcji typowych stosów TLS (OpenSSL, Schannel i Bed TLS zgodnie z platformą docelową)
  • Gniazda TCP (Win32, Berkeley lub Mbed)

Zapewnienie transportu komunikacyjnego, abstrakcji protokołu TLS i gniazd ma koszt wydajności. Wiele ścieżek wymaga malloc wywołań i memcpy między różnymi warstwami abstrakcji. Ten koszt wydajności jest niewielki w porównaniu z komputerem stacjonarnym lub urządzeniem Raspberry Pi. Jednak na naprawdę ograniczonym urządzeniu koszt staje się znaczącym obciążeniem z możliwością fragmentacji pamięci. Warstwa transportu komunikacji wymaga doWork również wywołania funkcji co najmniej co 100 milisekund. Te częste wywołania utrudniają optymalizowanie zestawu SDK dla urządzeń zasilanych baterią. Istnienie wielu warstw abstrakcji sprawia również, że klienci mogą używać danej biblioteki lub zmieniać ją.

Scenariusz 1 jest zalecany w przypadku urządzeń z systemem Windows lub Linux, które zwykle są mniej wrażliwe na użycie pamięci lub zużycie energii. Jednak urządzenia z systemami Windows i Linux mogą również używać osadzonego zestawu SDK języka C, jak pokazano w scenariuszu 2. Inne opcje dla urządzeń z systemami Windows i Linux obejmują inne zestawy SDK urządzeń Usługi Azure IoT: zestaw SDK języka Java, zestaw SDK platformy .NET, zestaw SDK platformy Node i zestaw SDK języka Python.

Scenariusz 2 — osadzony zestaw C SDK (w scenariuszach bez systemu operacyjnego i mikrokontrolerach)

W 2020 r. firma Microsoft wydała zestaw Azure SDK dla osadzonego języka C (znany również jako osadzony zestaw SDK języka C). Ten zestaw SDK został utworzony na podstawie opinii klientów i rosnącej potrzeby obsługi ograniczonych urządzeń mikrokontrolerów. Zwykle ograniczone mikrokontrolery mają zmniejszoną ilość pamięci i mocy obliczeniowej.

Zestaw EMBEDDED C SDK ma następujące kluczowe cechy:

  • Brak alokacji pamięci dynamicznej. Klienci muszą przydzielić struktury danych, w których chcą, na przykład w pamięci globalnej, stercie lub stosie. Następnie muszą przekazać adres przydzielonej struktury do funkcji zestawu SDK, aby zainicjować i wykonać różne operacje.
  • Tylko MQTT. Użycie tylko protokołu MQTT jest idealne dla urządzeń ograniczonych, ponieważ jest to wydajny, lekki protokół sieciowy. Obecnie obsługiwany jest tylko protokół MQTT w wersji 3.1.1.
  • Korzystanie z własnego stosu sieciowego. Osadzony zestaw SDK języka C nie wykonuje żadnych operacji we/wy. Takie podejście umożliwia klientom wybór klientów MQTT, TLS i Socket, którzy mają najlepsze dopasowanie do swojej platformy docelowej.
  • Podobny zestaw funkcji jako zestaw SDK języka C. Zestaw EMBEDDED C SDK udostępnia podobne funkcje jak zestaw SDK języka C usługi Azure IoT, z następującymi wyjątkami, które nie zapewniają osadzonego zestawu SDK języka C:
    • Przekazywanie do obiektu blob
    • Możliwość uruchamiania jako modułu usługi IoT Edge
    • Funkcje oparte na protokole AMQP, takie jak przetwarzanie wsadowe komunikatów zawartości i multipleksowanie urządzeń
  • Mniejszy całkowity ślad. Osadzony zestaw SDK języka C, jak widać w przykładzie, który pokazuje, jak nawiązać połączenie z usługą IoT Hub, może zająć nawet 74 KB pamięci ROM i 8,26 KB pamięci RAM.

Zestaw EMBEDDED C SDK obsługuje mikrokontrolery bez systemu operacyjnego, mikrokontrolerów z systemem operacyjnym w czasie rzeczywistym (np. Eclipse ThreadX), Linux i Windows. Klienci mogą implementować niestandardowe warstwy platformy do używania zestawu SDK na urządzeniach niestandardowych. Zestaw SDK udostępnia również niektóre warstwy platformy, takie jak Arduino i Swift. Firma Microsoft zachęca społeczność do przesyłania innych warstw platform w celu zwiększenia gotowej do użycia platformy. Wind River VxWorks to przykład warstwy platformy przesłanej przez społeczność.

Osadzony zestaw SDK języka C dodaje pewne korzyści programistyczne ze względu na jego elastyczność w porównaniu z zestawem SDK języka C usługi Azure IoT. W szczególności aplikacje korzystające z ograniczonych urządzeń skorzystają z ogromnych oszczędności zasobów i większej kontroli programowej. Dla porównania, jeśli używasz środowiska Eclipse ThreadX lub FreeRTOS, możesz mieć te same korzyści wraz z innymi funkcjami na implementację systemu RTOS.

Scenariusz 3 — Środowisko Eclipse ThreadX z oprogramowaniem pośredniczącym Azure IoT (dla projektów opartych na wątkach środowiska Eclipse)

Scenariusz 3 obejmuje używanie środowiska Eclipse ThreadX i oprogramowania pośredniczącego Azure IoT. Środowisko Eclipse ThreadX jest oparte na osadzonym zestawie SDK języka C i dodaje obsługę protokołów MQTT i TLS. Oprogramowanie pośredniczące dla środowiska Eclipse ThreadX uwidacznia interfejsy API aplikacji podobne do natywnych interfejsów API Eclipse ThreadX. Takie podejście ułatwia deweloperom korzystanie z interfejsów API i łączenie urządzeń opartych na technologii Eclipse ThreadX z usługą Azure IoT. Eclipse ThreadX to w pełni zintegrowana, wydajna, osadzona platforma w czasie rzeczywistym, która zapewnia wszystkie funkcje sieciowe i IoT potrzebne do rozwiązania.

Dostępne są przykłady dla kilku popularnych zestawów deweloperskich z języków ST, NXP, Renesas i Microchip. Te przykłady współpracują z usługą Azure IoT Hub lub Azure IoT Central i są dostępne jako projekty IAR Workbench lub półprzewodnikowe środowisko IDE w usłudze GitHub.

Ponieważ jest on oparty na osadzonym zestawie SDK języka C, oprogramowanie pośredniczące usługi Azure IoT dla środowiska Eclipse ThreadX nie jest przydzielane w pamięci. Klienci muszą przydzielić struktury danych zestawu SDK w pamięci globalnej lub stercie albo stosie. Gdy klienci przydzielą strukturę danych, muszą przekazać adres struktury do funkcji zestawu SDK, aby zainicjować i wykonać różne operacje.

Scenariusz 4 — FreeRTOS z oprogramowaniem pośredniczącym FreeRTOS (do użycia z projektami opartymi na freeRTOS)

Scenariusz 4 powoduje przeniesienie osadzonego oprogramowania pośredniczącego C do systemu FreeRTOS. Osadzone oprogramowanie pośredniczące języka C jest oparte na osadzonym zestawie SDK języka C i dodaje obsługę MQTT za pośrednictwem biblioteki coreMQTT typu open source. To oprogramowanie pośredniczące dla FreeRTOS działa na poziomie MQTT. Ustanawia połączenie MQTT, subskrybuje i anuluje subskrypcję tematów oraz wysyła i odbiera komunikaty. Rozłączenia są obsługiwane przez klienta za pośrednictwem interfejsów API oprogramowania pośredniczącego.

Klienci kontrolują konfigurację protokołu TLS/TCP i połączenie z punktem końcowym. Takie podejście umożliwia elastyczność między implementacjami oprogramowania lub sprzętu stosu. Żadne zadania w tle nie są tworzone przez oprogramowanie pośredniczące usługi Azure IoT dla systemu FreeRTOS. Komunikaty są wysyłane i odbierane synchronicznie.

Podstawowa implementacja jest dostępna w tym repozytorium GitHub. Dostępne są przykłady dla kilku popularnych zestawów deweloperskich, w tym NXP1060, STM32 i ESP32. Przykłady współpracują z usługami Azure IoT Hub, Azure IoT Central i Azure Device Provisioning Service i są dostępne w tym repozytorium GitHub.

Ponieważ jest ona oparta na zestawie Azure Embedded C SDK, oprogramowanie pośredniczące usługi Azure IoT dla systemu FreeRTOS również nie jest przydzielane w pamięci. Klienci muszą przydzielić struktury danych zestawu SDK w pamięci globalnej lub stercie albo stosie. Gdy klienci przydzielą strukturę danych, muszą przekazać adres przydzielonych struktur do funkcji zestawu SDK, aby zainicjować i wykonać różne operacje.

Scenariusze użycia technicznego zestawu SDK opartego na języku C

Na poniższym diagramie przedstawiono podsumowanie opcji technicznych dla każdego scenariusza użycia zestawu SDK opisanego w tym artykule.

Diagram ze szczegółami dla deweloperów dla czterech scenariuszy użycia zestawu C SDK.

Porównanie zestawu SDK opartego na języku C przez pamięć i protokoły

W poniższej tabeli porównaliśmy cztery scenariusze tworzenia zestawu SDK urządzeń na podstawie pamięci i użycia protokołu.

  Pamięć
przydział
Pamięć
zwyczaj
Protokołów
Obsługiwane
Zalecane dla
Azure IoT C SDK Głównie dynamiczne Nieograniczony. Może obejmować
do 1 MB lub więcej w pamięci RAM.
AMQP
HTTP
MQTT v3.1.1
Systemy oparte na mikroprocesorach
Microsoft Windows
Linux
Apple OS X
Zestaw Azure SDK dla osadzonego języka C Tylko statyczne Ograniczone o ilość
alokuje aplikację danych.
MQTT v3.1.1 Mikrokontrole
Implementacje bez systemu operacyjnego
Implementacje oparte na systemie RTOS
Oprogramowanie pośredniczące usługi Azure IoT dla środowiska Eclipse ThreadX Tylko statyczne Podlega ograniczeniom MQTT v3.1.1 Mikrokontrole
Implementacje oparte na systemie RTOS
Oprogramowanie pośredniczące usługi Azure IoT dla systemu FreeRTOS Tylko statyczne Podlega ograniczeniom MQTT v3.1.1 Mikrokontrole
Implementacje oparte na systemie RTOS

Funkcje usługi Azure IoT obsługiwane przez każdy zestaw SDK

W poniższej tabeli porównano cztery scenariusze tworzenia zestawu SDK urządzeń na podstawie obsługi funkcji usługi Azure IoT.

  Azure IoT C SDK Zestaw Azure SDK dla
Osadzony język C
Azure IoT
oprogramowanie pośredniczące dla
Eclipse ThreadX
Azure IoT
oprogramowanie pośredniczące dla
FreeRTOS
Uwierzytelnianie klienta SAS Tak Tak Tak Tak
Uwierzytelnianie klienta x509 Tak Tak Tak Tak
Aprowizowanie urządzeń Tak Tak Tak Tak
Telemetria Tak Tak Tak Tak
Komunikaty z chmury do urządzenia Tak Tak Tak Tak
Metody bezpośrednie Tak Tak Tak Tak
Bliźniacza reprezentacja urządzenia Tak Tak Tak Tak
IoT Plug-And-Play Tak Tak Tak Tak
Przetwarzanie wsadowe telemetrii
(AMQP, HTTP)
Tak Nie. Nie. Nie.
Przekazywanie do obiektu blob platformy Azure Tak Nie. Nie. Nie.
Automatyczna integracja w programie
Kontenery hostowane w usłudze IoT Edge
Tak Nie. Nie. Nie.

Następne kroki

Aby dowiedzieć się więcej na temat programowania urządzeń i dostępnych zestawów SDK dla usługi Azure IoT, zobacz poniższą tabelę.