Zephyr：资源有限系统商的模块化OS！

关注了就能看到更多这么棒的文章哦～

Zephyr: a modular OS for resource-constrained devices

March 14, 2023
This article was contributed by Koen Vervloesem
DeepL assisted translation
https://lwn.net/Articles/925924/

为资源受限的设备编写应用程序，比如内存很小或者没有内存管理单元（MMU）的设备，会带来一些挑战。在这些设备上运行 Linux 发行版通常不是一个好的选择，但是有一些操作系统就试图在运行 Linux 发行版和进行裸机（bare-metal）开发之间寻找机会。其中之一就是 Zephyr，这是一个由 Linux 基金会于 2016 年推出的实时操作系统（RTOS）。LWN 也在 Zephyr 四周年之际对其进行了一次介绍。在正式宣布的七年之后，Zephyr 已经取得了很多进展，现在拥有着一个很活跃的生态系统。

Zephyr 是一个面向连网并且资源很有限的设备的 RTOS，比如物联网（IoT）传感器、蓝牙追踪器、心率监测器、智能手表和嵌入式控制器。运行 Zephyr 的一个典型设备通常有一个时钟频率低于 100MHz 的微控制器，没有 MMU，带有 32KB 到 256KB 的静态 RAM，以及 512KB 或更少的片上闪存（on-chip flash memory）。

Zephyr 的大部分代码都是基于 Apache 2.0 许可证发布的，除了来自 Nordic Semiconductor 和 NXP Semiconductors 的驱动程序，这部分是使用了 3-Clause BSD 许可证。有一些构建工具使用了 GPLv2 许可证。在其 FAQ 中，该项目解释了选择 Apache 2.0 许可证的原因，主要是它很宽松，使得该项目能够扩大组织中的参与度和成员，包括那些过去通常不参与开源开发的组织。

Modular operating system

Zephyr 的目标主要是单一用途的设备，仅运行一个应用程序。该应用程序与操作系统、任何外部库以及甚至 shell 一起编译，所有这些都静态链接到单个可执行文件中。然后可以将此固件二进制文件刷入设备，并在单个地址空间中的微控制器上运行。Zephyr 的构建系统基于 CMake。每个 Zephyr 应用程序都有一个 CMakeLists.txt 文件，告诉构建系统在哪里找到所需的代码文件以及如何链接生成出应用程序。

开发人员可以直接使用 CMake 构建其应用程序，但 Zephyr 的默认构建工具是 west。在 Zephyr 应用程序目录中运行 west build 命令会在幕后调用 CMake。Zephyr 开发人员将 west 描述为“meta-tool”。它不仅用于构建应用程序，还可以将其烧写到设备里面，甚至管理代码仓库。

Zephyr 项目由许多子系统组成，可以单独启用或禁用这些子系统来生成最终的 firmware image。由于这种模块化的特性，使得这个 RTOS 可以在具有各种功能的设备上运行，从具有 8KB RAM 的最小微控制器（仅使用最少的子系统）到足以运行 Linux 的开发板都可以。

为了选择子系统并设置其他配置选项，Zephyr 使用 Kconfig，即 Linux 内核的配置系统。有选项可以启用和禁用子系统（例如蓝牙、IPv6 和 I²C），或者深入配置这些子系统。体系架构特有的一些选项，还有驱动程序和库等都是以相同的方式进行配置。

构建配置（a build configuration）也可以分成几个文件。为此，Zephyr 具备 overlay configuration file 的概念。它具有添加到默认配置文件中的那些额外配置选项。overlay 配置文件对于构建 firmware 的 debug 版本非常有用，或者生成最小版本、完整版本等。

Hardware abstraction layer

像 Linux 内核一样，Zephyr 也使用 devicetree，这是一个描述硬件的分层结构。对于可以支持的每个开发板，都有一个 devicetree，描述了具备哪些硬件，如 UART、串行外设接口（SPI）总线、通用输入/输出（GPIO）引脚、SRAM、闪存等等。在需要构建一个应用程序时，开发者指定目标板，然后构建系统就针对这个开发板来选择合适的 devicetree 并生成一个 C 头文件。

设备驱动程序和应用程序都可以 include 这个生成的头文件来访问硬件。Zephyr 有一个设备驱动程序通用模型（generic model）：每种类型的驱动程序（例如 UART、I²C、SPI）都有一个通用的 API。因此，应用程序开发人员通常不需要针对每个设备来查找如何使用该特定的驱动程序。一些硬件制造商，如 Nordic Semiconductor、STMicroelectronics 和 NXP Semiconductors，都为 Zephyr 维护了他们自己的硬件抽象层（HAL）。这可以使应用开发者对制造商对 Zephyr 的支持有一些信心。

现有的 devicetree 可以用 devicetree overlay 方式来定制和修改。例如，如果有一个开发板增加了一些外部传感器，那么为它来生成应用程序时，开发者可以创建一个描述额外的传感器的 overlay 文件。如果文件名由开发板的名称和文件扩展名.overlay 组成，Zephyr 的构建系统就会自动使用该 overlay 文件。然后会合并到没有传感器的标准板的 devicetree 中。这样以来，应用程序代码就能够访问传感器。

Communication

Zephyr 支持大量的协议和硬件标准，从很底层的硬件标准和协议，到高级的网络和应用协议。所有这些都是不同的子系统，如果应用程序需要就可以单独启用。

对于微控制器跟传感器等电路板上的其他组件之间的通信，Zephyr 支持 I²C、SPI、I²S 音频，以及使用 UART 的串行通信。当然，如果板子把 UART 引脚暴露出来作为日志记录或者 shell 访问用的话，也也可用于跟外部的通信。USB 和用于汽车环境和工业自动化上的 CAN （Controller Area Network）则是另外两种可用的外部通信机制。

由于 Zephyr 是针对物联网设备的，因此对网络和无线通信协议的支持就是至关重要的。在开放系统互连（OSI，Open Systems Interconnection）模型的低层，就是这些以太网、点对点协议（PPP）、LoRa 和 IEEE 802.15.4 等协议。而在更上层一点是有对 Thread 的支持的，这是一种用于家庭自动化应用的基于 IPv6 的低功耗无线网状网络技术，基于 OpenThread 的实现。Zephyr 的蓝牙协议栈提供了完整的蓝牙低能耗（BLE）协议栈以及经典蓝牙的部分内容，这也是一个很受欢迎的选择。例如，流行的 BLE 芯片制造商 Nordic Semiconductor 将其 nRF Connect SDK 建立在 Zephyr 之上。

Zephyr 的网络堆栈特别关注 IoT 环境中使用的应用协议。这包括受限应用协议（CoAP, Constrained Application Protocol），它提供了一个轻量级的 REST API。在 CoAP 的基础上，轻量级 M2M（LwM2M）可用于设备管理、报告和控制。此外，Zephyr 有一个消息队列遥测传输（MQTT, Message Queuing Telemetry Transport）客户端函数库，支持 MQTT 3.1.0 和 3.1.1。它们可以直接通过 TCP 或 TLS 来传输，或着用在 WebSocket 连接之上。

Filesystems and device management

Zephyr 的 Virtual Filesystem Switch（VFS）为文件系统提供了一个通用的 API。目前支持 FAT 和 littlefs（一种为微控制器设计的 fail-safe 文件系统）。存储可以是在内部或外部 flash 存储设备上，在 SD 卡上，或在 RAM 中。应用程序可以在不同的 mount 位置来挂载多个文件系统。

对于基于 Zephyr 的设备的远程管理，Zephyr 操作系统中有一个基于开源项目 MCUmgr 的子系统。mcumgr 这个命令行工具允许用户通过 BLE、UART 串口连接或基于 IP 的 UDP 来管理他们的设备。用户可以查看、删除和上传系统映像文件，从文件系统中下载和上传任意文件、重新启动设备、并打开一个 shell。

Device Firmware Upgrade（DFU）子系统与 MCUboot 集成在了一起，这是一个不受限于特定硬件或操作系统的 32 位微控制器的引导程序。在使用了这种引导程序的设备上，Zephyr 应用程序可以通过 MCUboot 的串行恢复模式（serial recovery mode）进行 flash 烧写。MCUboot 还能够验证固件映像文件。可以创建一个公钥/私钥对，然后用私钥对固件文件进行签名；引导程序只有在能够用相应的公钥验证通过签名时才接受这个更新。

Quality, security, and Long-Term Support

Zephyr 项目遵循一个松散的基于 Linux 内核的发布流程，发布周期大约为四个月。在这个过程中对于质量和安全会非常关注。有一个安全工作组负责处理已经发现的漏洞，同时也致力于完善操作系统的安全架构。开发人员采取的安全措施都记录在案。2019 年，Zephyr 是获得核心基础设施倡议最佳实践 "金" 徽章的三个开源项目之一。目前，有 15 个项目取得了这一成就，Zephyr 仍在其中。有了这个徽章，该项目就证明了它在开发中遵循了安全的最佳实践。

长期支持（LTS）版本是以大约两年一次的周期发布的。它们需要独立于 main 代码树来维护至少两年半的时间。一个 LTS 版本不会得到新的功能或实质性的改进了，但它会不断吸收严重或与安全有关的 bug fix。这给公司提供了一个稳定基础，他们的产品可以建立在此之上。

第一个 LTS 版本是 2019 年 4 月的 Zephyr 1.14，支持 8 种架构上的 160 种板卡配置。随后在 2021 年 10 月发布了第二个 LTS 版本，即 Zephyr 2.7，支持了 12 种架构的 400 种板卡配置。该项目维基中的发布里程碑日期目前的目标是第三个 LTS 版本的 Zephyr 3.6，预计在 2024 年 2 月。

Sample applications

虽然很难快速掌握 Zephyr，而且开发文档可能会让人感到不知所措，但该项目提供了大量的示例应用程序，从简单的闪烁 LED 的 Blinky 应用程序到复杂的网络应用和蓝牙实例都有。一些示例应用程序是针对特定的板子或特定的传感器的，而另一个例子展示了如何使用一个外部函数库。它们中的每一个都带有了文档，解释了代码的作用，包括如何构建 firmware 以及有什么功能。

许多示例应用程序广泛使用 devicetree 的 overlay 以及配置文件的 overlay，以使它们尽可能地通用。例如，Socket Echo 服务器就支持 OpenThread、IEEE 802.15.4、蓝牙互联网协议支持规范（IPSP）、PPP、TLS 或 IP tunnel，都使用了各自的 overlay 配置文件作为对通用配置的修改。

当开始开发一个新的应用程序时，可以很容易地从其中的一个样本应用程序开始，然后在此基础上进行开发。所有的示例代码都可以在 GitHub 的 Zephyr 仓库中找到。还有一个通用的示例应用程序，可以作为新的 Zephyr 应用程序的模板。

Board support and Zephyr in the wild

开发人员正在不断增加对新开发板的支持。目前，Zephyr 支持超过 450 个来自不同架构的开发板。其中大多数是 32 位 ARM 板，但也支持 Arm64 架构、Xtensa（包括流行的 ESP32 微控制器）和 RISC-V。对特定功能的支持因板卡或架构的不同而不同。例如，ESP32 微控制器对 Wi-Fi 和蓝牙的支持需要 Espressif 的 HAL，该 HAL 利用了一些二进制 Blob 文件。

Zephyr 已经存在于不少开源项目中，例如在键盘的 ZMK 固件中就用了它。还有用于 PineTime 智能手表的 Zephyr 固件，以及基于 Zephyr 的 open-hardware 以及 open-firmware 的智能手表 ZSWatch。另一方面，商业硬件制造商通常不愿意提供太多关于他们如何构建固件的信息，但 Zephyr 的新闻发布经常会展示一些基于该操作系统的产品。

不过，也并不全是关于物联网产品的。负责电池充电、USB 电源传输、键盘处理和其他底层任务的嵌入式控制器也很适合 Zephyr。2021 年 7 月，谷歌决定将其 Chromebook 转移到 Zephyr 嵌入式控制器上。这简化了 Chromebook 制造商对其设备所需的定制步骤。英特尔还创建了基于 Zephyr 的嵌入式控制器固件，OEM 可以将其作为他们制造的 PC 中的嵌入式控制器的基础。他们仍然需要将其与板级支持包（BSP, board-support package）和 HAL 结合起来，用于特定的硬件。

Conclusion

Zephyr 是一个灵活的、模块化的实时操作系统，适用于那些对 Linux 来说不够强大的设备。很多功能都是默认已经包含的，而且许可证对商业使用也很友好。此外，在七年的时间里，该项目已经成功地建立了一个繁荣的生态系统，其中许多硬件制造商也通过维护他们自己的 HAL 和贡献代码发挥了核心作用。无论是嵌入式控制器还是无线物联网设备，都有很多理由来考虑使用 Zephyr。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～