Cenários de uso do C SDK e do C SDK incorporado
A Microsoft fornece SDKs de dispositivo IoT do Azure e middleware para cenários de dispositivos incorporados e restritos. Este artigo ajuda os desenvolvedores de dispositivos a decidir qual usar para seu aplicativo.
O diagrama a seguir mostra quatro cenários comuns nos quais os clientes conectam dispositivos ao Azure IoT, usando um SDK baseado em C (C99). O restante deste artigo fornece mais detalhes sobre cada cenário.
Cenário 1 – Azure IoT C SDK (para Linux e Windows)
A partir de 2015, o Azure IoT C SDK foi o primeiro SDK do Azure criado para conectar dispositivos a serviços de IoT. É uma plataforma estável que foi criada para fornecer os seguintes recursos para conectar dispositivos ao Azure IoT:
- Serviços do Hub IoT
- Clientes do Serviço de Provisionamento de Dispositivos
- Três opções de transporte de comunicação (MQTT, AMQP e HTTP), que são criadas e mantidas pela Microsoft
- Múltiplas escolhas de pilhas TLS comuns (OpenSSL, Schannel e Bed TLS de acordo com a plataforma de destino)
- Soquetes TCP (Win32, Berkeley ou Mbed)
Fornecer transporte de comunicação, TLS e abstração de soquete tem um custo de desempenho. Muitos caminhos exigem malloc e memcpy chamam entre as várias camadas de abstração. Esse custo de desempenho é pequeno em comparação com um desktop ou um dispositivo Raspberry Pi. No entanto, em um dispositivo verdadeiramente restrito, o custo torna-se uma sobrecarga significativa com a possibilidade de fragmentação da memória. A camada de transporte de comunicação também requer uma doWork função a ser chamada pelo menos a cada 100 milissegundos. Essas chamadas frequentes tornam mais difícil otimizar o SDK para dispositivos alimentados por bateria. A existência de várias camadas de abstração também torna difícil para os clientes usar ou alterar para uma determinada biblioteca.
O cenário 1 é recomendado para dispositivos Windows ou Linux, que normalmente são menos sensíveis ao uso de memória ou consumo de energia. No entanto, dispositivos baseados em Windows e Linux também podem usar o SDK C incorporado, conforme mostrado no Cenário 2. Outras opções para dispositivos baseados em Windows e Linux incluem os outros SDKs de dispositivo IoT do Azure: Java SDK, .NET SDK, Node SDK e Python SDK.
Cenário 2 – SDK C incorporado (para cenários bare metal e microcontroladores)
Em 2020, a Microsoft lançou o SDK do Azure para Embedded C (também conhecido como Embedded C SDK). Este SDK foi criado com base no feedback dos clientes e numa necessidade crescente de suportar dispositivos microcontroladores restritos. Normalmente, os microcontroladores restritos têm memória e poder de processamento reduzidos.
O SDK C incorporado tem as seguintes características principais:
- Sem alocação de memória dinâmica. Os clientes devem alocar estruturas de dados onde desejarem, como na memória global, em um heap ou em uma pilha. Em seguida, eles devem passar o endereço da estrutura alocada para funções SDK para inicializar e executar várias operações.
- Apenas MQTT. O uso somente MQTT é ideal para dispositivos restritos porque é um protocolo de rede eficiente e leve. Atualmente, apenas o MQTT v3.1.1 é suportado.
- Traga sua própria pilha de rede. O SDK C incorporado não executa operações de E/S. Essa abordagem permite que os clientes selecionem os clientes MQTT, TLS e Socket que melhor se ajustam à sua plataforma de destino.
- Conjunto de recursos semelhante ao C SDK. O SDK C incorporado fornece recursos semelhantes ao SDK do Azure IoT C SDK, com as seguintes exceções que o SDK C incorporado não fornece:
- Carregar para blob
- A capacidade de executar como um módulo IoT Edge
- Recursos baseados em AMQP, como lote de mensagens de conteúdo e multiplexação de dispositivos
- Menor pegada total. O SDK C incorporado, como mostrado em um exemplo que mostra como se conectar ao Hub IoT, pode levar apenas 74 KB de ROM e 8,26 KB de RAM.
O Embedded C SDK suporta microcontroladores sem sistema operacional, microcontroladores com um sistema operacional em tempo real (como o Eclipse ThreadX), Linux e Windows. Os clientes podem implementar camadas de plataforma personalizadas para usar o SDK em dispositivos personalizados. O SDK também fornece algumas camadas de plataforma, como Arduino e Swift. A Microsoft incentiva a comunidade a enviar outras camadas de plataforma para aumentar as plataformas suportadas prontas para uso. Wind River VxWorks é um exemplo de uma camada de plataforma submetida pela comunidade.
O SDK C incorporado adiciona alguns benefícios de programação devido à sua flexibilidade em comparação com o SDK do Azure IoT C. Em particular, as aplicações que utilizam dispositivos restritos beneficiarão de enormes poupanças de recursos e de um maior controlo programático. Em comparação, se você usar o Eclipse ThreadX ou FreeRTOS, poderá ter esses mesmos benefícios junto com outros recursos por implementação de RTOS.
Cenário 3 – Eclipse ThreadX com middleware do Azure IoT (para projetos baseados no Eclipse ThreadX)
O cenário 3 envolve o uso do Eclipse ThreadX e do middleware do Azure IoT. O Eclipse ThreadX é construído sobre o SDK do Embedded C e adiciona suporte a MQTT e TLS. O middleware do Eclipse ThreadX expõe APIs para o aplicativo que são semelhantes às APIs nativas do Eclipse ThreadX. Essa abordagem torna mais simples para os desenvolvedores usar as APIs e conectar seus dispositivos baseados no Eclipse ThreadX ao Azure IoT. O Eclipse ThreadX é uma plataforma embarcada totalmente integrada, eficiente e em tempo real, que fornece todos os recursos de rede e IoT que você precisa para sua solução.
Amostras para vários kits de desenvolvimento populares da ST, NXP, Renesas e Microchip estão disponíveis. Esses exemplos funcionam com o Hub IoT do Azure ou o Azure IoT Central e estão disponíveis como IAR Workbench ou projetos IDE de semicondutores no GitHub.
Como é baseado no SDK C incorporado, o middleware do Azure IoT para Eclipse ThreadX não é alocador de memória. Os clientes devem alocar estruturas de dados SDK na memória global, ou um heap, ou uma pilha. Depois que os clientes alocam uma estrutura de dados, eles devem passar o endereço da estrutura para as funções do SDK para inicializar e executar várias operações.
Cenário 4 – FreeRTOS com middleware FreeRTOS (para uso com projetos baseados em FreeRTOS)
O cenário 4 traz o middleware C incorporado para o FreeRTOS. O middleware C incorporado é construído sobre o SDK C incorporado e adiciona suporte MQTT através da biblioteca coreMQTT de código aberto. Este middleware para FreeRTOS opera no nível MQTT. Ele estabelece a conexão MQTT, assina e cancela a inscrição de tópicos, e envia e recebe mensagens. As desconexões são tratadas pelo cliente por meio de APIs de middleware.
Os clientes controlam a configuração TLS/TCP e a conexão com o ponto de extremidade. Essa abordagem permite flexibilidade entre implementações de software ou hardware de qualquer pilha. Nenhuma tarefa em segundo plano é criada pelo middleware do Azure IoT para FreeRTOS. As mensagens são enviadas e recebidas de forma síncrona.
A implementação principal é fornecida neste repositório GitHub. Amostras para vários kits de desenvolvimento populares estão disponíveis, incluindo o NXP1060, STM32 e ESP32. Os exemplos funcionam com o Hub IoT do Azure, o Azure IoT Central e o Serviço de Provisionamento de Dispositivo do Azure e estão disponíveis neste repositório do GitHub.
Como é baseado no SDK do Azure Embedded C, o middleware do Azure IoT para FreeRTOS também não é alocador de memória. Os clientes devem alocar estruturas de dados SDK na memória global, ou um heap, ou uma pilha. Depois que os clientes alocam uma estrutura de dados, eles devem passar o endereço das estruturas alocadas para as funções do SDK para inicializar e executar várias operações.
Cenários de uso técnico do SDK baseado em C
O diagrama a seguir resume as opções técnicas para cada cenário de uso do SDK descrito neste artigo.
Comparação do SDK baseado em C por memória e protocolos
A tabela a seguir compara os quatro cenários de desenvolvimento do SDK do dispositivo com base no uso de memória e protocolo.
| Memória Alocação |
Memória Utilização |
Protocolos suportado |
Recomendado para | |
|---|---|---|---|---|
| Azure IoT C SDK | Principalmente dinâmico | Sem restrições. Pode abranger para 1 MB ou mais na RAM. |
AMQP HTTP MQTT v3.1.1 |
Sistemas baseados em microprocessadores Microsoft Windows Linux Maçã OS X |
| SDK do Azure para C incorporado | Apenas estática | Limitado pela quantidade de aplicação de dados aloca. |
MQTT v3.1.1 | Microcontroladores Implementações bare-metal Implementações baseadas em RTOS |
| Azure IoT Middleware para Eclipse ThreadX | Apenas estática | Restrito | MQTT v3.1.1 | Microcontroladores Implementações baseadas em RTOS |
| Azure IoT Middleware para FreeRTOS | Apenas estática | Restrito | MQTT v3.1.1 | Microcontroladores Implementações baseadas em RTOS |
Recursos do Azure IoT suportados por cada SDK
A tabela a seguir compara os quatro cenários de desenvolvimento do SDK do dispositivo com base no suporte para recursos do Azure IoT.
| Azure IoT C SDK | SDK do Azure para C incorporado |
Azure IoT middleware para Eclipse ThreadX |
Azure IoT middleware para FreeRTOS |
|
|---|---|---|---|---|
| Autenticação de cliente SAS | Sim | Sim | Sim | Sim |
| Autenticação de cliente x509 | Sim | Sim | Sim | Sim |
| Provisionamento de dispositivos | Sim | Sim | Sim | Sim |
| Telemetria | Sim | Sim | Sim | Sim |
| Mensagens da nuvem para o dispositivo | Sim | Sim | Sim | Sim |
| Métodos Diretos | Sim | Sim | Sim | Sim |
| Dispositivo Duplo | Sim | Sim | Sim | Sim |
| IoT Plug-And-Play | Sim | Sim | Sim | Sim |
| Telemetria em lote (AMQP, HTTP) |
Sim | No | No | Não |
| Carrega para o Blob do Azure | Sim | No | No | Não |
| Integração automática em Contêineres hospedados do IoT Edge |
Sim | No | No | Não |
Próximos passos
Para saber mais sobre o desenvolvimento de dispositivos e os SDKs disponíveis para o Azure IoT, consulte a tabela a seguir.