Zephyr RTOS 嵌入式 C 编程（使用嵌入式 RTOS POSIX API）1. 简介

本书内容概览

本书是一本基础指南，介绍如何使用 Zephyr RTOS 框架以 C 语言开发嵌入式及物联网/工业物联网(IoT/IIoT) 应用程序。它面向计划启动 Zephyr RTOS 项目，或评估在即将开展的项目中使用 Zephyr RTOS 潜在优势的工程师和程序员。

作为读者，您可能具备数字电子和嵌入式系统编程背景，曾用 C 语言和汇编语言开发专用嵌入式系统应用。或许即将开发的应用需求表明，传统的裸机编程方式可能并非最佳选择。又或者您接手了一些文档匮乏的复杂多任务代码，而参与开发这些代码的程序员或顾问已离开项目，您的公司正考虑将代码迁移至实时多任务操作系统。

本书旨在向您展示 Zephyr 的功能，并介绍在着手实际基于 RTOS 的实时项目之前所需掌握的基本 RTOS 编程技能。本书也可视为对构成 Zephyr RTOS 的丰富复杂框架的指南，以及 Zephyr 代码库中示例的导引。

或者，您可能具备嵌入式 Linux 开发经验，但需要在虽强大却因体积限制无法运行完整 Linux 系统的处理器上开发应用。Zephyr 的独特之处在于它吸收并适配了许多使 Linux 如此特别的概念与技术，例如对 POSIX API 的支持以及采用 Kconfig 和 devicetree 等 Linux 技术。

什么是 RTOS？何时及为何需要它？

现代微控制器的尺寸和复杂度差异显著，既有闪存不足 10KB、RAM 小于 2KB 的 8 位微控制器，也有可连接千兆字节内存的多核 64 位微控制器。在嵌入式计算领域的低端产品中可见 SoC（片上系统）处理器架构，而高端产品则采用 SoM（模块化系统）板卡。

对于执行单一专门任务或少量固定任务的小型系统，例如牙刷或电钻中控制电机的电机控制器，其代码可以实现为裸机应用程序。现代互联应用的复杂性意味着它们并不适合作为裸机应用程序来实现。现代微控制器供应商通常提供集成开发环境（IDE），这些环境通过图形界面配置外设并将驱动程序代码”引入”项目，从而使开发人员能够专注于他们试图构建的应用程序。例如 Microchip 的 Harmony 工具和意法半导体的 STM32CubeIDE。嵌入式系统应用程序也可以使用 IDE（如微软的 VS Code 配合适当插件）进行开发。

可将操作系统视为一种提供服务的软件，这些服务可用于开发需要同时处理多项工作（任务）的应用程序。操作系统的核心是调度程序，其职责是决定接下来运行哪个任务。在协作式多任务操作系统中，任务会一直运行，直到其自行暂停当前操作并将控制权转移给调度程序，由调度程序决定下一个运行的任务。而在抢占式多任务操作系统中，操作系统可随时抢占正在运行的任务。抢占可能由于更高优先级的任务准备就绪，或当前任务需要访问正被其他任务占用的资源。实时性概念指系统对某些事件（如按键操作、通信外设数据到达或 ADC（模数转换）完成）的响应时长。实时系统通常分为硬实时和软实时两种类型。在硬实时系统中，若响应时间超过规定时长即视为错误。而在软实时系统中，响应时间以统计学意义衡量——多数情况下能满足完成时限要求，但偶尔会出现超时情况。

传统的裸机多任务处理通常采用”超级循环”处理非时效性任务，而时效性任务则由中断处理程序完成。经典 Arduino IDE 也遵循此模式。

在现代世界中，联网设备（包括有线和无线网络）运行相对复杂的网络协议栈并以安全方式实现这一功能时，标准的裸机方法会遇到困难。一台联网设备可能拥有多个接口，例如有线或无线以太网、USB 以及诸如 CAN 总线、RS232 或 RS485 等串行通信。相关代码相当复杂，且需要同时处理底层细节和设备执行的其他任务（例如定期采集传感器读数），这进一步增加了复杂性。联网设备可能需要与多个其他设备交互，且通信流量模式可能难以预测。更糟糕的是，流量可能呈突发性，系统需要保护自身免受大流量突发导致的过载影响。

面向分组的通信协议（如 TCP/IP）采用多层架构，数据包会包含对应各层及其功能的多个报头。协议支持多路复用的情况很常见。例如，TCP/IP 协议栈同时处理 UDP、TCP 流量以及 ICMP 流量，对于 UDP 和 TCP 而言，可能存在与设备上运行的不同进程相关联的流量，每个进程通过特定标识符（端口号）进行区分。

从设计与实现的角度来看，多任务处理方式允许各个任务被独立开发后再整合，这得益于实时操作系统提供的调度机制以及任务间通信与同步机制（如信号量和消息队列）。

采用实时操作系统(RTOS)开发嵌入式应用的核心动机在于，它提供了一个框架及其相关抽象层和 API 接口，这些技术支持开发能够处理构成应用程序各项任务的时间、优先级和可抢占性的代码，从而满足任务时限要求并使系统表现出确定性行为。从开发者视角来看，RTOS 可视为提供服务的平台——不仅提供任务调度、同步和进程间通信服务，还可根据需要提供文件系统服务、通信服务及安全服务。

什么是实时操作系统？

RTOS 中的 OS 代表操作系统（Operating System）。操作系统可视为提供任务调度与控制服务的模块（库）集合，其中任务是指执行整个应用程序中特定工作的代码段。现代高级操作系统还会为广泛使用的设备和外设提供驱动程序、通信协议栈以及可构建实际应用的应用程序层模块，此外还包括安全与内存保护或内存管理服务等诸多功能。RTOS 中的 RT 代表实时（Real Time）。

此处的实时性指的是可预测且可复现的行为。这种行为在统计学意义上可能是可预测的，例如对某些事件的响应时间会遵循具有特定均值和方差的统计分布。这属于”软”实时系统。对于某些应用，可能要求响应时间始终小于某个特定值，这类应用被称为”硬” 实时应用。也存在同时包含”硬”实时和”软”实时特性的系统。

在需要功能安全的系统中使用开源 RTOS

对于涉及高度功能安全的应用，还会产生一个问题：是否可以将开源软件用于那些”功能安全”是强制性要求的系统。

在安全关键系统中使用 RTOS 代码通常涉及采用经过严格测试和验证的代码，以确保其符合一个或多个已发布的安全标准。以 FreeRTOS 为例，它既有开源版本，也有名为 SAFERTOS 的预认证版本，该版本已通过 IEC 61508 认证，适用于安全关键应用。目前，Zephyr RTOS 尚未推出预认证版本。Zephyr 项目的目标是最终能够提供经过认证、可用于安全关键应用的版本，这一目标体现在 Zephyr 的开发和代码审查流程中。

在需要功能安全的系统中使用开源软件所引发的问题包括以下考虑因素：

开源软件通常需要经过重大改造才能投入使用。

这类改造大多是在非公开环境下进行的（如果许可证允许的话）。

原始源代码与”认证”代码之间可能存在完全脱节。

将开源代码转化为功能安全的成本”高昂”。

在项目生命周期早期遵循标准是关键因素。

有许多标准涉及安全关键系统和软件，这个标准家族的部分成员如示意图中的部分族谱所示

从开源项目发展为可用于安全关键系统的认证实例是 FreeRTOS。SAFERTOS 始于 FreeRTOS 内核的功能模型，但随后从 HAZOP 角度重新设计、分析并测试了内核代码，并按照 IEC 61508-3 SIL 3 开发生命周期实现。

Zephyr 实时操作系统计划的愿景是最终提供一个可用于安全关键系统的开源 RTOS。Zephyr RTOS 已具备安全关键型 RTOS 所需的许多功能特性，但真正的核心在于系统及其开发流程的正式验证与测试。接下来几节将探讨其中部分问题。

使开源操作系统适合功能安全导向应用的特性包括：

开源实现

小型可信代码库（按代码行数计算）

安全导向的架构

内置安全模型

符合 POSIX 标准的 C 语言库

支持确定性线程调度

支持多核线程调度

证明开发符合 ISO 标准

实施责任

行业采用

认证友好型接口

Zephyr 项目的使命宣言是”为资源受限的联网设备提供一流的实时操作系统，确保安全可靠”。Zephyr RTOS 官网上展示了遵循安全关键系统软件开发测试标准流程的各个步骤和方法，包括采用软件开发的 V 模型所规范的验证与确认环节。在 2022 年欧洲开源峰会上关于这些议题的有益讨论值得已关注。

从开发安全关键系统的高质量 RTOS 角度来看，遵循 V 模型的开源项目会遇到诸多问题，例如功能的形式化规范、生成全面文档、实现从需求到源代码的可追溯性，以及提供完整的贡献者数量及其相关信息。

从认证机构的角度来看，问题在于他们不熟悉开源开发模式，且缺乏经过验证的开源软件认证方法。

目前，Zephyr 在嵌入式系统安全、防护、可移植性和可靠性编码方面遵循的标准是 MISRA C:2012（含第 1 号修正案，遵循 MISRA C 合规性:2016 指南），并参考使用 SEI CERT C 和 JPL（加州理工学院喷气推进实验室）标准。关于功能安全，目标是遵循 IEC 61508:2010（最初为 SIL 3，最终目标是达到 SIL 4）。IEC 61508 被开发机器人系统和自动驾驶汽车的公司广泛采用。

如今，编写符合 MISRA 指南的嵌入式 C 代码已成为业界普遍接受的做法。关于 MISRA 与开源代码结合时出现的问题包括以下几点：

某些规则存在很大争议；应如何处理这些规则？

决定偏离哪些指南及其原因

MISRA C 是专有标准，如何使其更广泛地普及？

寻找能够检查代码的”开源”工具，并将其与持续集成(CI)系统整合

嵌入式系统开发中广泛遵循的 MISRA 规则示例：规则 15.5—— 函数应在末尾设置单一退出点：

最具可读性的代码结构

降低错误遗漏函数退出代码的可能性

许多安全标准要求如此

《1. 引言》

ISO 26262

协调认证与开源的关系

协调一个拥有众多潜在贡献者的开源项目与一个能够产出安全关键系统认证软件的项目颇具挑战性，这代表着”正在进行的工作”。

目前正在探索和尝试多种方法，其中包括以下几种：

对源代码树（分支）进行快照、验证并控制更新，这是一种可行的软件认证方法。

将支持的功能集作为前期决策进行定义时需谨记：支持的功能越多，需要提供的文档量就越大，需执行的软件测试工作也越多。在此背景下，尽可能实现信息追踪自动化，并通过测试与问题追踪系统自动生成文档将至关重要。

尽早从认证机构获得概念验证批准。

一种理想的开发流程能够结合开源开发和关键系统认证的最佳特性，它将基于分叉开发模式——包含灵活的开放实例路径和可审计实例路径[3]。是否将可审计路径与开放实例路径对齐，取决于新增功能的需求和认证流程的成本。

Zephyr 作为模块化 RTOS

模块化 RTOS 的核心思想是将其开发为一组可组合的组件，从而构建仅包含应用程序所需功能的系统。这种方法并非首创，微软早期 Windows NT 操作系统版本就采用模块化设计，能够根据具体任务需求构建最合适的操作系统变体。

因此，Zephyr 致力于提供一种以模块化开源架构为核心的 RTOS 应用开发解决方案，适用于在资源受限的联网嵌入式控制器上实现各种用例和设计架构。Zephyr 采用 Apache 2.0 许可证，由 Linux 基金会托管，并对蓝牙和 TCP/IP 提供广泛支持。

Zephyr OS 的模块化特性可以概念化为图
1-3所示的分层模型。

Zephyr 作为全功能实时操作系统

需要了解 Zephyr 的一个重要方面是：Zephyr 并非单一组件——它提供的是完整解决方案。功能特性包括以下内容：

安全特性：

线程隔离

堆栈保护（硬件/软件）

质量管理（QM）

构建时配置

无动态内存分配

功能安全(FuSA) (2019)

安全特性：

用户空间支持

加密支持

软件更新

可配置模块化内核

可将 Zephyr 内核配置为在 8K RAM 中运行

实现可扩展的应用程序代码

只需包含应用程序所需内容

跨平台能力：

Zephyr 支持多种架构（ARM Cortex M、RISC-V、ARC、MIPS、Extensa）。

原生移植

应用程序可在 Linux、Windows 和 macOS 平台上开发

开源：

基于 Apache II 许可证授权

由 Linux 基金会管理

透明的开发流程

可在 GitHub 上分叉

互联互通：

全面支持蓝牙5.0

蓝牙控制器

BLE 网状网络

线程支持

功能完备的原生网络协议栈

设备固件升级(DFU) (IP + BLE)

Zephyr 框架的丰富特性在图 1-4[4]中得到了充分展示。

图 1-4
Zephyr 框架组件支撑基于 Zephyr 的应用程序

选择 Zephyr 操作系统的理由

支持 Zephyr 的一个主要论点在于其模块化设计、广泛的适用场景以及对多种平台的全面支持。Zephyr 操作系统解决了地址碎片化、基础设施模块化等问题，并支持 POSIX API 等标准规范，其根本目标是让开发者能专注于面向最终用户的接口开发，而无需重复实现底层接口。

Zephyr 提供以产品为核心的长期支持，重点在于强化现有功能的稳定性而非引入新特性。其可审计代码库源自 Zephyr 操作系统功能集的一个子集。

Zephyr 实时操作系统的独特之处

与其他许多实时操作系统(RTOS)不同，Zephyr 不受任何单一公司控制。该项目由非营利组织 Linux 基金会管理，其使命是通过围绕开源项目构建可持续生态系统，从而加速技术发展及其商业应用。由于 Zephyr 不依附于任何商业组织的独立性特质，以及其开发与采用完全基于开源 GitHub 仓库的开放模式，相较于亚马逊支持的 FreeRTOS 和微软主导的 Azure RTOS（ThreadX），Zephyr 吸引了更多开发者贡献。