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.
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.
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ę.