Scénarios d’usage du SDK C et du SDK Embedded C

Microsoft fournit des Azure IoT device SDK et des intergiciels pour les scénarios d’appareils incorporés et limités. Cet article aide les développeurs d’appareils à choisir celui à utiliser pour votre application.

Le diagramme suivant montre quatre scénarios courants dans lesquels les clients connectent des appareils à Azure IoT, à l’aide d’un SDK C (C99). Le reste de cet article fournit plus de détails sur chaque scénario.

Scénario 1 : Kit de développement logiciel (SDK) C Azure IoT (pour Linux et Windows)

À compter de 2015, le SDK C Azure IoT a été le premier Kit de développement logiciel (SDK) Azure créé pour connecter des appareils aux services IoT. Il s’agit d’une plateforme stable conçue pour fournir les fonctionnalités suivantes pour connecter des appareils à Azure IoT :

• Services de IoT Hub
• Clients du service de provisionnement des appareils
• Trois choix de transport de communication (MQTT, AMQP et HTTP), créés et gérés par Microsoft
• Plusieurs choix de piles TLS courantes (OpenSSL, Schannel et Bed TLS en fonction de la plateforme cible)
• Sockets TCP (Win32, Berkeley ou Mbed)

La fourniture d’un transport de communication, de TLS et d’abstraction de socket a un coût de performances. De nombreux chemins nécessitent malloc et memcpy appels entre les différentes couches d’abstraction. Ce coût de performances est faible par rapport à un ordinateur de bureau ou à un appareil Raspberry Pi. Pourtant, sur un appareil véritablement limité, le coût devient une surcharge importante avec la possibilité de fragmentation de la mémoire. La couche de transport de communication nécessite également qu’une fonction doWork soit appelée au moins toutes les 100 millisecondes. Ces appels fréquents compliquent l’optimisation du SDK pour les appareils alimentés par batterie. L’existence de plusieurs couches d’abstraction rend également difficile l’utilisation ou la modification par les clients d’une bibliothèque donnée.

Le scénario 1 est recommandé pour les appareils Windows ou Linux, qui sont normalement moins sensibles à l’utilisation de la mémoire ou à la consommation d’énergie. Toutefois, les appareils Windows et Linux peuvent également utiliser le SDK Embedded C comme indiqué dans le scénario 2. D’autres options pour les appareils Windows et Linux incluent les autres Azure IoT device SDK : SDK Java, SDK, .NET, SDK Node et SDK Python.

Scénario 2 : SDK Embedded C (pour les scénarios matériel nu et les micro-contrôleurs)

En 2020, Microsoft a publié le SDK Azure pour Embedded C (également appelé SDK Embedded C). Ce SDK repose sur les commentaires des clients et un besoin croissant de prendre en charge les appareils micro-contrôleurs contraints. En règle générale, les micro-contrôleurs limités ont réduit la puissance de mémoire et de traitement.

Le SDK Embedded C présente les caractéristiques clés suivantes :

• Pas d’allocation de mémoire dynamique. Les clients doivent allouer des structures de données où ils souhaitent, comme dans la mémoire globale, un tas ou une pile. Puis ils doivent passer l’adresse de la structure allouée dans des fonctions SDK pour initialiser et effectuer diverses opérations.
• MQTT uniquement. L’utilisation de MQTT uniquement est idéale pour les appareils limités, car il s’agit d’un protocole réseau léger et efficace. Actuellement, seul MQTT v3.1.1 est pris en charge.
• Apporter votre propre pile réseau. Le SDK Embedded C n’effectue aucune opération d’E/S. Cette approche permet aux clients de sélectionner les clients MQTT, TLS et Socket qui ont le meilleur ajustement à leur plateforme cible.
• Ensemble de fonctionnalités similaire à celui du SDK C. Le SDK Embedded C fournit des fonctionnalités similaires à celles du SDK C Azure IoT, avec les exceptions suivantes que le SDK Embedded C ne fournit pas :
  • Charger vers l’objet blob
  • Possibilité d’exécuter en tant que module IoT Edge
  • Fonctionnalités basées sur AMQP, telles que le traitement par lot de messages de contenu et le multiplexage d’appareils
• Empreinte globale plus petite. Le SDK Embedded C, comme le montre un exemple qui montre comment se connecter à IoT Hub, peut prendre jusqu’à 74 Ko de ROM et 8,26 Ko de RAM.

Le kit de développement logiciel (SDK) C intégré prend en charge les micro-contrôleurs sans système d’exploitation, les micro-contrôleurs avec un système d’exploitation en temps réel (comme Eclipse ThreadX), Linux et Windows. Les clients peuvent implémenter des couches de plateforme personnalisées pour utiliser le SDK sur des appareils personnalisés. Le SDK fournit également certaines couches de plateforme telles que Arduino et Swift. Microsoft encourage la communauté à envoyer d’autres couches de plateforme pour augmenter le nombre de plateformes prises en charge prêtes à l’emploi. Wind River VxWorks est un exemple de couche de plateforme soumise par la communauté.

Le SDK Embedded C offre des avantages en matière de programmation en raison de sa flexibilité par rapport au SDK C Azure IoT. En particulier, les applications qui utilisent des appareils limités bénéficieront d’énormes économies de ressources et d’un meilleur contrôle programmatique. Par comparaison, si vous utilisez Eclipse ThreadX ou FreeRTOS, vous pouvez bénéficier de ces mêmes avantages, ainsi que d’autres fonctionnalités par implémentation RTOS.

Scénario 3 : Eclipse ThreadX avec un intergiciel Azure IoT (pour les projets basés sur Eclipse ThreadX)

Le scénario 3 implique l’utilisation d’Eclipse ThreadX et de l’intergiciel Azure IoT. Eclipse ThreadX repose sur le kit de développement logiciel (SDK) C intégré et ajoute la prise en charge de MQTT et TLS. L’intergiciel pour Eclipse ThreadX expose des API qui sont semblables aux API Eclipse ThreadX natives pour l’application. Cette approche simplifie l’utilisation des API par les développeurs et la connexion de leurs appareils basés sur Eclipse ThreadX à Azure IoT. Eclipse ThreadX est une plateforme intégrée, efficace et en temps réel qui fournit toutes les fonctionnalités de mise en réseau et IoT nécessaire à votre solution.

Des exemples pour plusieurs kits de développement populaires de ST, NXP, Renesas et Microchip sont disponibles. Ces exemples fonctionnent avec Azure IoT Hub ou Azure IoT Central et sont disponibles en tant que projets IAR Workbench ou IDE semi-conducteurs sur GitHub.

Étant donné qu’il est basé sur le kit de développement logiciel (SDK) C intégré, l’intergiciel Azure IoT pour Eclipse ThreadX n’alloue pas de mémoire. Les clients doivent allouer des structures de données du SDK en mémoire globale, ou un tas ou une pile. Une fois que les clients allouent une structure de données, ils doivent passer l’adresse de la structure dans les fonctions du SDK pour initialiser et effectuer diverses opérations.

Scénario 4 : FreeRTOS avec intergiciel FreeRTOS (pour une utilisation avec des projets basés sur FreeRTOS)

Le scénario 4 apporte l’intergiciel Embedded C à FreeRTOS. L’intergiciel Embedded C repose sur le SDK Embedded C et ajoute la prise en charge de MQTT via la bibliothèque open source coreMQTT. Ce middleware pour FreeRTOS fonctionne au niveau MQTT. Il établit la connexion MQTT, s’abonne et se désabonne des rubriques, et envoie et reçoit des messages. Les déconnexions sont gérées par le client via des API middleware.

Les clients contrôlent la configuration TLS/TCP et la connexion au point de terminaison. Cette approche permet une flexibilité entre les implémentations logicielles ou matérielles de l’une ou l’autre des piles. Aucune tâche en arrière-plan n’est créée par l’intergiciel Azure IoT pour FreeRTOS. Les messages sont envoyés et reçus de manière synchrone.

L’implémentation principale est fournie dans ce référentiel GitHub. Des échantillons pour plusieurs kits de développement populaires sont disponibles, notamment les kits NXP1060, STM32 et ESP32. Les échantillons fonctionnent avec Azure IoT Hub, Azure IoT Central et le service Azure Device Provisioning et sont disponibles dans ce référentiel GitHub.

Étant donné qu’il est basé sur le SDK Embedded C, l’intergiciel Azure IoT pour Azure RTOS n’alloue pas de mémoire. Les clients doivent allouer des structures de données du SDK en mémoire globale, ou un tas ou une pile. Une fois que les clients allouent une structure de données, ils doivent passer l’adresse des structures allouées dans les fonctions du SDK pour initialiser et effectuer diverses opérations.

Scénarios d’utilisation technique du SDK basé sur C

Le diagramme suivant récapitule les options techniques pour chaque scénario d’utilisation du SDK décrit dans cet article.

Comparaison du SDK basé sur C par mémoire et protocoles

Le tableau suivant compare les quatre scénarios de développement SDK d’appareil en fonction de l’utilisation de la mémoire et du protocole.

Fonctionnalités Azure IoT prises en charge par chaque SDK

Le tableau suivant compare les quatre scénarios de développement SDK d’appareil en fonction de la prise en charge des fonctionnalités Azure IoT.

Étapes suivantes

Pour en savoir plus sur le développement d’appareils et les kits SDK disponibles pour Azure IoT, consultez le tableau suivant.

• Développement d’appareil Azure IoT
• Quel kit SDK utiliser ?