你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

C SDK 和嵌入式 C SDK 使用方案

项目
04/15/2024

Microsoft 为嵌入式设备和受限设备方案提供 Azure IoT 设备 SDK 和中间件。本文可帮助设备开发人员确定为你的应用程序使用哪一种。

下图显示了客户使用基于 C 的 (C99) SDK 将设备连接到 Azure IoT 的 4 种常见方案。本文的其余部分提供了有关每个方案的更多详细信息。

常见 SDK 方案的示意图。

方案 1 - Azure IoT C SDK（适用于 Linux 和 Windows）

从 2015 年开始，Azure IoT C SDK 是第一个创建用于将设备连接到 IoT 服务的 Azure SDK。它是一个稳定的平台，旨在提供下列用于将设备连接到 Azure IoT 的功能：

IoT 中心服务
设备预配服务客户端
3 种通信传输选择（MQTT、AMQP 和 HTTP），由 Microsoft 创建和维护
多种常用 TLS 堆栈选择（OpenSSL、Schannel 和 Bed TLS，由目标平台决定）
TCP 套接字（Win32、Berkeley 或 Mbed）

提供通信传输、TLS 和套接字抽象需要付出性能代价。许多路径需要在各个抽象层之间调用 malloc 和 memcpy。与桌面设备或 Raspberry Pi 设备相比，此性能成本很小。然而，在真正受限的设备上，由于内存碎片的可能性，成本变成了巨大的开销。通信传输层还需要至少每 100 毫秒调用一次 doWork 函数。这些频繁的调用使得为电池供电的设备优化 SDK 更加困难。存在多个抽象层也使得客户很难使用或更改任何给定库。

对于 Windows 或 Linux 设备，建议使用方案 1 - 这些设备通常对内存使用量或功耗不太敏感。但是，基于 Windows 和 Linux 的设备也可使用嵌入式 C SDK，如方案 2 所示。用于基于 Windows 和 Linux 的设备的其他选项包括其他 Azure IoT 设备 SDK：Java SDK、.NET SDK、Node SDK 和 Python SDK。

方案 2 - 嵌入式 C SDK（适用于裸机场景和微控制器）

2020 年，Microsoft 发布了适用于嵌入式 C 的 Azure SDK（也称为嵌入式 C SDK）。此 SDK 的构建基础是客户的反馈以及对支持受约束的微控制器设备的日益增长的需求。通常，受约束的微控制器降低了内存和处理能力。

嵌入式 C SDK 具有以下关键特征：

无动态内存分配。客户必须将数据结构分配到所需位置（全局内存、堆或堆栈等）。然后，他们必须将已分配结构的地址传递到 SDK 函数，以便进行初始化并执行各种操作。
仅限 MQTT。 “仅限 MQTT”用法非常适合受约束的设备，因为它是一种高效的轻型网络协议。目前仅支持 MQTT v3.1.1。
拥有自己的网络堆栈。嵌入式 C SDK 不执行 I/O 操作。通过此方法，客户可选择最适合其目标平台的 MQTT、TLS 和套接字客户端。
与 C SDK 类似的功能集。嵌入式 C SDK 提供与 Azure IoT C SDK 类似的功能，但不提供以下功能：
- 上传到 Blob
- 作为 IoT Edge 模块运行的能力
- 基于 AMQP 的功能，例如内容消息批处理和设备多路复用
整体内存占用量更小。正如在演示如何连接到 IoT 中心的示例中所见，嵌入式 C SDK 可以占用仅 74 KB 的 ROM 和 8.26 KB 的 RAM。

嵌入式 C SDK 支持不带操作系统的微控制器、使用实时操作系统的微控制器（如 Eclipse ThreadX）、Linux 和 Windows。客户可实现自定义平台层，以在自定义设备上使用 SDK。 SDK 还提供一些平台层，例如 Arduino 和 Swift。 Microsoft 鼓励社区提交其他平台层来增加现成的受支持平台。 Wind River VxWorks 是社区提交的平台层示例。

与 Azure IoT C SDK 相比，嵌入式 C SDK 具有灵活性，因此增加了一些编程优势。特别是，使用受约束的设备的应用程序将受益于大幅资源节省和更优的编程控制。相比之下，如果使用 Eclipse ThreadX 或 FreeRTOS，可获得相同的优势，还可为每个 RTOS 实现获得其他功能。

方案 3 - 使用 Azure IoT 中间件的 Eclipse ThreadX（适用于基于 Eclipse ThreadX 的项目）

方案 3 涉及使用 Eclipse ThreadX 和 Azure IoT 中间件。 Eclipse ThreadX 基于嵌入式 C SDK 构建而成，并添加了 MQTT 和 TLS 支持。 Eclipse ThreadX 的中间件公开了与本机 Eclipse ThreadX API 类似的应用程序 API。通过此方法，开发者可更容易地使用 API 并将基于 Eclipse ThreadX 的设备连接到 Azure IoT。 Eclipse ThreadX 是一个完全集成、高效、实时的嵌入式平台，可提供解决方案所需的所有网络和 IoT 功能。

提供了 ST、NXP、Renesas 和 Microchip 中几个常用开发人员工具包的示例。这些示例适用于 Azure IoT 中心或 Azure IoT Central，并在 GitHub 上作为 IAR Workbench 或半导体 IDE 项目提供。

它以嵌入式 C SDK 为基础，因此 Eclipse ThreadX 的 Azure IoT 中间件为非内存分配。客户必须在全局内存、堆或堆栈中分配 SDK 数据结构。客户分配数据结构后，必须将该结构的地址传递到 SDK 函数中，以进行初始化和执行各种操作。

方案 4 - 具有 FreeRTOS 中间件的 FreeRTOS（适用于基于 FreeRTOS 的项目）

方案 4 将嵌入式 C 中间件引入 FreeRTOS。嵌入式 C 中间件基于嵌入式 C SDK 构建，并通过开源 coreMQTT 库添加 MQTT 支持。 FreeRTOS 的此中间件在 MQTT 级别运行。它会建立 MQTT 连接、订阅和取消订阅主题，并发送和接收消息。客户通过中间件 API 处理断开连接的情况。

由客户来控制 TLS/TCP 配置和与终结点的连接。通过此方法，在任一堆栈的软件或硬件实现之间可灵活操作。 Azure IoT 中间件不为 FreeRTOS 创建后台任务。消息是同步发送和接收的。

此 GitHub 存储库中提供了核心实现。提供了几个常用开发人员工具包的示例，包括 NXP1060、STM32 和 ESP32。这些示例适用于 Azure IoT 中心、Azure IoT Central 和 Azure 设备预配服务，并在此 GitHub 存储库中提供。

它基于 Azure 嵌入式 C SDK，因此 FreeRTOS 的 Azure IoT 中间件也是非内存分配的。客户必须在全局内存、堆或堆栈中分配 SDK 数据结构。客户分配数据结构后，必须将已分配结构的地址传递到 SDK 函数中，以进行初始化和执行各种操作。

基于 C 的 SDK 技术使用方案

下图总结了本文中所述的每个 SDK 使用方案的技术选项。

基于 C 的 SDK 比较（按内存和协议）

下表根据内存和协议使用情况比较了 4 种设备 SDK 开发方案。

	内存分配	内存使用情况	协议受支持	推荐用于
Azure IoT C SDK	大多数是动态的	Unrestricted。可在 RAM 中扩展到 1 MB 或更多。	AMQP HTTP MQTT v3.1.1	基于微处理器的系统 Microsoft Windows Linux Apple OS X
适用于嵌入式 C 的 Azure SDK	仅限静态	受应用程序分配的数据量限制。	MQTT v3.1.1	微控制器裸机实现基于 RTOS 的实现
用于 Eclipse ThreadX 的 Azure IoT 中间件	仅限静态	受限	MQTT v3.1.1	微控制器基于 RTOS 的实现
适用于 FreeRTOS 的 Azure IoT 中间件	仅限静态	受限	MQTT v3.1.1	微控制器基于 RTOS 的实现

每个 SDK 支持的 Azure IoT 功能

下表根据对 Azure IoT 功能的支持比较了 4 种设备 SDK 开发方案。

	Azure IoT C SDK	Azure SDK for Embedded C	Azure IoT 中间件 Eclipse ThreadX	Azure IoT 中间件 FreeRTOS
SAS 客户端身份验证	是	是	是	是
x509 客户端身份验证	是	是	是	是
设备预配	是	是	是	是
遥测	是	是	是	是
云到设备消息	是	是	是	是
直接方法	是	是	是	是
设备孪生	是	是	是	是
IoT 即插即用	是	是	是	是
遥测批处理（AMQP、HTTPS）	是	否	No	否
上传到 Azure Blob	是	否	No	否
IoT Edge 托管容器中的自动集成	是	否	No	否

通过