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.

Diagrama de cenários comuns do SDK.

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.

Diagrama com detalhes do desenvolvedor para os quatro cenários de uso do C SDK.

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.