Scenari di utilizzo di C SDK C e Embedded C SDK
Microsoft offre SDK e middleware per dispositivi IoT di Azure per scenari di dispositivi incorporati e vincolati. Questo articolo aiuta gli sviluppatori di dispositivi a decidere quale usare per l'applicazione.
Il diagramma seguente illustra quattro scenari comuni in cui i clienti connettono i dispositivi ad Azure IoT, usando un SDK basato su C (C99). Il resto di questo articolo fornisce altri dettagli su ogni scenario.
Scenario 1: Azure IoT C SDK (per Linux e Windows)
A partire dal 2015, Azure IoT C SDK è stato il primo SDK di Azure creato per connettere i dispositivi ai servizi IoT. Si tratta di una piattaforma stabile creata per fornire le funzionalità seguenti per la connessione dei dispositivi ad Azure IoT:
- servizi hub IoT
- Client del servizio Device Provisioning
- Tre opzioni di trasporto di comunicazione (MQTT, AMQP e HTTP), create e gestite da Microsoft
- Più scelte di stack TLS comuni (OpenSSL, Schannel e Bed TLS in base alla piattaforma di destinazione)
- Socket TCP (Win32, Berkeley o Mbed)
La fornitura di trasporto di comunicazione, l'astrazione TLS e socket ha un costo delle prestazioni. Molti percorsi richiedono e memcpy chiamano malloc tra i vari livelli di astrazione. Questo costo delle prestazioni è ridotto rispetto a un dispositivo Desktop o Raspberry Pi. Tuttavia, in un dispositivo veramente vincolato, il costo diventa un sovraccarico significativo con la possibilità di frammentazione della memoria. Il livello di trasporto delle comunicazioni richiede anche una doWork funzione da chiamare almeno ogni 100 millisecondi. Queste chiamate frequenti rendono più difficile ottimizzare l'SDK per i dispositivi a batteria. L'esistenza di più livelli di astrazione rende difficile anche ai clienti usare o modificare qualsiasi libreria specifica.
Lo scenario 1 è consigliato per i dispositivi Windows o Linux, che in genere sono meno sensibili all'utilizzo della memoria o al consumo energetico. Tuttavia, i dispositivi basati su Windows e Linux possono anche usare Embedded C SDK, come illustrato nello scenario 2. Altre opzioni per i dispositivi windows e basati su Linux includono gli altri SDK per dispositivi Azure IoT: Java SDK, .NET SDK, Node SDK e Python SDK.
Scenario 2 : Embedded C SDK (per scenari Bare Metal e micro-controller)
Nel 2020 Microsoft ha rilasciato Azure SDK per Embedded C (noto anche come Embedded C SDK). Questo SDK è stato creato in base al feedback dei clienti e a una crescente necessità di supportare dispositivi micro-controller vincolati.This SDK was built based on customers feedback and a growing need to support constrained micro-controller devices. In genere, i micro controller vincolati hanno una potenza di elaborazione e memoria ridotta.
Embedded C SDK presenta le caratteristiche chiave seguenti:
- Nessuna allocazione dinamica della memoria. I clienti devono allocare strutture di dati in cui desiderano, ad esempio nella memoria globale, in un heap o in uno stack. Devono quindi passare l'indirizzo della struttura allocata nelle funzioni SDK per inizializzare ed eseguire varie operazioni.
- Solo MQTT. L'utilizzo solo MQTT è ideale per i dispositivi vincolati perché è un protocollo di rete efficiente e leggero. Attualmente è supportato solo MQTT v3.1.1.
- Usare uno stack di rete personalizzato. Embedded C SDK non esegue operazioni di I/O. Questo approccio consente ai clienti di selezionare i client MQTT, TLS e Socket più adatti alla piattaforma di destinazione.
- Set di funzionalità simile a C SDK. Embedded C SDK offre funzionalità simili a quella di Azure IoT C SDK, con le eccezioni seguenti che Embedded C SDK non fornisce:
- Caricare nel BLOB
- Possibilità di eseguire come modulo IoT Edge
- Funzionalità basate su AMQP, ad esempio l'invio in batch di messaggi di contenuto e il multiplexing dei dispositivi
- Footprint complessivo più piccolo. Embedded C SDK, come illustrato in un esempio che mostra come connettersi a hub IoT, può richiedere fino a 74 KB di ROM e 8,26 KB di RAM.
Embedded C SDK supporta micro-controller senza sistema operativo, micro-controller con un sistema operativo in tempo reale (ad esempio Eclipse ThreadX), Linux e Windows. I clienti possono implementare livelli di piattaforma personalizzati per usare l'SDK nei dispositivi personalizzati. L'SDK fornisce anche alcuni livelli della piattaforma, ad esempio Arduino e Swift. Microsoft incoraggia la community a inviare altri livelli di piattaforma per aumentare le piattaforme supportate predefinite. Wind River VxWorks è un esempio di livello piattaforma inviato dalla community.
Embedded C SDK offre alcuni vantaggi di programmazione grazie alla flessibilità rispetto ad Azure IoT C SDK. In particolare, le applicazioni che usano dispositivi vincolati trarranno vantaggio da enormi risparmi di risorse e un maggiore controllo a livello di codice. In confronto, se si usa Eclipse ThreadX o FreeRTOS, è possibile avere questi stessi vantaggi insieme ad altre funzionalità per ogni implementazione di RTOS.
Scenario 3: Eclipse ThreadX con middleware IoT di Azure (per i progetti basati su Eclipse ThreadX)
Lo scenario 3 prevede l'uso di Eclipse ThreadX e del middleware IoT di Azure. Eclipse ThreadX si basa su Embedded C SDK e aggiunge il supporto MQTT e TLS. Il middleware per Eclipse ThreadX espone le API per l'applicazione simili alle API ThreadX eclipse native. Questo approccio semplifica agli sviluppatori l'uso delle API e la connessione dei dispositivi basati su Eclipse ThreadX ad Azure IoT. Eclipse ThreadX è una piattaforma incorporata completamente integrata, efficiente e in tempo reale, che offre tutte le funzionalità di rete e IoT necessarie per la soluzione.
Sono disponibili esempi per diversi kit di sviluppo popolari di ST, NXP, Renesas e Microprocessor. Questi esempi funzionano con hub IoT di Azure o Azure IoT Central e sono disponibili come progetti IDE IAR Workbench o semiconduttori in GitHub.
Poiché si basa su Embedded C SDK, il middleware IoT di Azure per Eclipse ThreadX non viene allocato in memoria. I clienti devono allocare strutture di dati SDK in memoria globale, un heap o uno stack. Dopo che i clienti allocano una struttura di dati, devono passare l'indirizzo della struttura nelle funzioni SDK per inizializzare ed eseguire varie operazioni.
Scenario 4: FreeRTOS con middleware FreeRTOS (da usare con progetti basati su FreeRTOS)
Lo scenario 4 introduce il middleware C incorporato in FreeRTOS. Il middleware C incorporato si basa su Embedded C SDK e aggiunge il supporto MQTT tramite la libreria coreMQTT open source. Questo middleware per FreeRTOS opera a livello MQTT. Stabilisce la connessione MQTT, sottoscrive e annulla la sottoscrizione agli argomenti e invia e riceve messaggi. Le disconnessioni vengono gestite dal cliente tramite API middleware.
I clienti controllano la configurazione e la connessione TLS/TCP all'endpoint. Questo approccio consente la flessibilità tra implementazioni software o hardware di uno stack. Nessuna attività in background viene creata dal middleware IoT di Azure per FreeRTOS. I messaggi vengono inviati e ricevuti in modo sincrono.
L'implementazione principale viene fornita in questo repository GitHub. Sono disponibili esempi per diversi kit di sviluppo più diffusi, tra cui il NXP1060, STM32 ed ESP32. Gli esempi funzionano con hub IoT di Azure, Azure IoT Central e il servizio Device Provisioning di Azure e sono disponibili in questo repository GitHub.
Poiché si basa su Azure Embedded C SDK, il middleware IoT di Azure per FreeRTOS è anche l'allocazione non in memoria. I clienti devono allocare strutture di dati SDK in memoria globale, un heap o uno stack. Dopo che i clienti allocano una struttura di dati, devono passare l'indirizzo delle strutture allocate nelle funzioni SDK per inizializzare ed eseguire varie operazioni.
Scenari di utilizzo tecnico dell'SDK basati su C
Il diagramma seguente riepiloga le opzioni tecniche per ogni scenario di utilizzo dell'SDK descritto in questo articolo.
Confronto dell'SDK basato su C per memoria e protocolli
La tabella seguente confronta i quattro scenari di sviluppo di SDK per dispositivi in base all'utilizzo della memoria e del protocollo.
| Memoria allocazione |
Memoria uso |
Protocolli sostenuto |
Consigliato per | |
|---|---|---|---|---|
| Azure IoT C SDK | Principalmente dinamico | Unrestricted. Può estendersi fino a 1 MB o più di RAM. |
AMQP HTTP MQTT v3.1.1 |
Sistemi basati su microprocessore Microsoft Windows Linux Apple OS X |
| Azure SDK per Embedded C | Solo statico | Limitato in base alla quantità di l'applicazione dati alloca. |
MQTT v3.1.1 | Micro-controller Implementazioni bare metal Implementazioni basate su RTOS |
| Middleware di Azure IoT per Eclipse ThreadX | Solo statico | Limitata | MQTT v3.1.1 | Micro-controller Implementazioni basate su RTOS |
| Middleware IoT di Azure per FreeRTOS | Solo statico | Limitata | MQTT v3.1.1 | Micro-controller Implementazioni basate su RTOS |
Funzionalità di Azure IoT supportate da ogni SDK
La tabella seguente confronta i quattro scenari di sviluppo di SDK per dispositivi in base al supporto per le funzionalità di Azure IoT.
| Azure IoT C SDK | Azure SDK per C incorporato |
Azure IoT middleware per Eclipse ThreadX |
Azure IoT middleware per FreeRTOS |
|
|---|---|---|---|---|
| Autenticazione client di firma di accesso condiviso | Sì | Sì | Sì | Sì |
| Autenticazione client x509 | Sì | Sì | Sì | Sì |
| Provisioning dei dispositivi | Sì | Sì | Sì | Sì |
| Telemetria | Sì | Sì | Sì | Sì |
| Messaggi da cloud a dispositivo | Sì | Sì | Sì | Sì |
| Metodi diretti | Sì | Sì | Sì | Sì |
| Dispositivo gemello | Sì | Sì | Sì | Sì |
| IoT Plug-And-Play | Sì | Sì | Sì | Sì |
| Invio in batch di dati di telemetria (AMQP, HTTP) |
Sì | No | No | No |
| Caricamenti nel BLOB di Azure | Sì | No | No | No |
| Integrazione automatica in Contenitori ospitati in IoT Edge |
Sì | No | No | No |
Passaggi successivi
Per altre informazioni sullo sviluppo di dispositivi e sugli SDK disponibili per Azure IoT, vedere la tabella seguente.