你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Microsoft 为嵌入式设备和受限设备方案提供 Azure IoT 设备 SDK 和中间件。 本文可帮助设备开发人员确定为你的应用程序使用哪一种。
下图显示了客户使用基于 C 的 (C99) SDK 将设备连接到 Azure IoT 的 4 种常见方案。 本文的其余部分提供了有关每个方案的更多详细信息。
从 2015 年开始，Azure IoT C SDK 是第一个创建用于将设备连接到 IoT 服务的 Azure SDK。 它是一个稳定的平台，旨在提供下列用于将设备连接到 Azure IoT 的功能：
提供通信传输、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。
2020 年，Microsoft 发布了适用于嵌入式 C 的 Azure SDK（也称为嵌入式 C SDK）。 此 SDK 的构建基础是客户的反馈以及对支持受约束的微控制器设备的日益增长的需求。 通常，受约束的微控制器降低了内存和处理能力。
嵌入式 C SDK 具有以下关键特征：
嵌入式 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 涉及使用 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 将嵌入式 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 函数中，以进行初始化和执行各种操作。
下图总结了本文中所述的每个 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 的实现 |
下表根据对 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 | 否 |
若要详细了解 Azure IoT 的设备开发和可用 SDK，请参阅下表。
培训
学习路径
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
认证
Microsoft Certified: Azure Developer Associate - Certifications
在 Microsoft Azure 中构建端到端解决方案，以创建 Azure Functions、实现和管理 Web 应用、开发使用 Azure 存储的解决方案等。
文档
Azure IoT 设备和服务 SDK - Azure IoT
IoT SDK 和库的列表。 包括用于设备开发的 SDK 和用于生成服务应用程序的 SDK。
指向可用于生成设备应用和后端应用的 Azure IoT 中心 SDK 的链接。
了解如何使用 Azure IoT 服务、SDK 和工具通过常规设备和嵌入式设备进行设备开发。