Embed Book

主题

第四层：实时操作系统（RTOS） ​

RTOS 章节的核心不是记 API，而是理解任务调度、时间管理、线程通信和资源竞争背后的系统行为。只要调度模型清楚，才能在项目里真正把多任务系统写稳定。

建议学习目标：

  • 理解裸机系统与 RTOS 的边界和适用场景。
  • 掌握任务、优先级、时间片、阻塞与唤醒等核心概念。
  • 能区分队列、信号量、互斥锁、事件组等机制的使用场景。
  • 具备分析死锁、优先级反转、栈溢出和实时性问题的能力。

阅读建议：先建立调度模型，再学习线程通信与资源保护，最后结合实际应用场景理解 RTOS 的工程价值。

RTOS 基础概念 ​

什么是 RTOS？ ​

RTOS（Real-Time Operating System）是面向实时场景设计的操作系统。它的目标不是追求“平均性能最高”，而是追求“关键任务在预期时间内完成”。

RTOS 关心的核心问题包括：

  • 任务什么时候执行
  • 哪个任务优先执行
  • 多个任务如何共享资源
  • 时间触发行为如何保证稳定

很多嵌入式项目不是必须上 RTOS，但一旦系统出现以下特点，就应认真考虑：

  • 有多个独立功能并发运行
  • 存在固定周期任务
  • 存在通信、采集、显示、控制并行需求
  • 需要更清晰的任务边界和资源管理

常见 RTOS ​

常见 RTOS 包括：

  • FreeRTOS：最常见，生态成熟
  • RT-Thread：国内使用广泛，组件丰富
  • CMSIS-RTOS：ARM 提供统一接口标准
  • Zephyr：适合 IoT 和较现代的软件栈

理解不同 RTOS 时，不要先看 API 差异，而要先看它们在以下方面的设计：

  • 调度模型
  • 任务栈管理
  • IPC 机制
  • 内存管理方式
  • 中断与任务协作方式

任务管理 ​

任务创建与内存布局 ​

RTOS 中每个任务通常都有：

  • 独立栈空间
  • 任务控制块（TCB）
  • 优先级
  • 当前状态

示例：

c
void vTaskFunction(void *pvParameters) {
    for (;;) {
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

xTaskCreate(vTaskFunction, "Task1", 256, NULL, 2, NULL);

实际开发中，任务栈大小往往比创建 API 更重要。栈设太小会导致诡异崩溃，设太大又会浪费宝贵 RAM。

任务状态转换 ​

典型任务状态包括：

  • Running：正在运行
  • Ready：已就绪，等待 CPU
  • Blocked：等待事件或超时
  • Suspended：被挂起
  • Deleted：已删除

可以把调度理解成一个状态机：任务不断在就绪、运行、阻塞之间切换。

任务优先级与调度算法 ​

RTOS 常见调度原则：

  • 高优先级任务优先执行
  • 同优先级任务可采用时间片轮转
  • 阻塞任务不会占用 CPU

调度设计的常见误区：

  • 把大量任务都设成高优先级
  • 用高优先级掩盖设计问题
  • 在高优先级任务里放耗时逻辑

实际经验：

  • 实时采样和关键控制任务优先级更高
  • 通信、日志、显示通常可以更低
  • 系统稳定比“所有任务都快”更重要

时间管理 ​

任务延时实现 ​

RTOS 中最常见的时间管理方式是任务延时。

c
vTaskDelay(pdMS_TO_TICKS(100));

这表示当前任务主动让出 CPU，并在指定时间后重新变为就绪态。

对于周期任务，更推荐使用绝对周期方式：

c
TickType_t xLastWakeTime = xTaskGetTickCount();
const TickType_t xFrequency = pdMS_TO_TICKS(100);

for (;;) {
    vTaskDelayUntil(&xLastWakeTime, xFrequency);
}

原因是它能减少累计误差，更适合定周期控制任务。

软件定时器 ​

软件定时器适合做：

  • 周期检测
  • 延时触发
  • 超时回调

不适合做：

  • 高实时性控制
  • 长时间阻塞操作
  • 复杂业务逻辑堆积

示例：

c
TimerHandle_t xTimer = xTimerCreate(
    "Timer",
    pdMS_TO_TICKS(1000),
    pdTRUE,
    (void *)0,
    vTimerCallback
);

理解软件定时器时要意识到：它本质上依赖系统节拍和后台处理任务，不等价于硬件定时器。

线程间通信 ​

队列（Queue） ​

队列适合在任务之间传递有顺序的数据。

典型用途：

  • 按键事件传递
  • 采样值上报
  • 命令和状态消息流转
c
QueueHandle_t xQueue = xQueueCreate(5, sizeof(int));

队列的优势是：

  • 线程安全
  • 可阻塞等待
  • 数据传递语义清晰

信号量（Semaphore） ​

信号量本质上是“同步和计数工具”。

常见两类：

  • 二值信号量：做事件通知
  • 计数信号量：做资源计数

典型场景：

  • 中断通知任务
  • 多个资源实例的访问控制

需要区分一个关键点：

  • 信号量更偏“同步”
  • 互斥锁更偏“资源保护”

消息队列（Message Queue） ​

很多项目会把结构体封装后通过队列传递，本质上就是“消息化”的任务通信。

c
typedef struct {
    uint8_t command;
    uint32_t data;
} Message_t;

这种方式的优势是：

  • 接口清晰
  • 易扩展
  • 适合做事件驱动系统

事件组（Event Group） ​

事件组适合管理多个布尔条件或状态位。

例如：

  • 网络已连上
  • 传感器初始化完成
  • 存储器挂载成功

当多个条件都满足时，再让某个任务继续执行。

这类机制非常适合启动流程和多模块协作。

资源管理 ​

互斥锁与优先级继承 ​

互斥锁用于保护共享资源，例如：

  • 全局结构体
  • 共享总线
  • 文件系统接口
  • 显示缓冲区

它和普通信号量最大的区别之一，是通常带有优先级继承机制，可以缓解优先级反转问题。

优先级反转的典型场景：

  1. 低优先级任务占有锁
  2. 高优先级任务想拿锁被阻塞
  3. 中优先级任务不断抢占 CPU
  4. 高优先级任务反而迟迟得不到运行机会

内存管理 ​

RTOS 中常见几种内存分配策略：

  • 完全静态分配
  • 简单动态分配
  • 固定块内存池

在资源受限项目中，动态内存并非不能用，但必须明确：

  • 谁申请
  • 谁释放
  • 生命周期多长
  • 是否会碎片化

如果系统稳定性要求高，静态分配通常更容易控制风险。

FreeRTOS 配置与移植 ​

常用配置项 ​

FreeRTOS 的很多行为由 FreeRTOSConfig.h 控制。

常见配置项包括：

  • configCPU_CLOCK_HZ
  • configTICK_RATE_HZ
  • configMAX_PRIORITIES
  • configMINIMAL_STACK_SIZE
  • configTOTAL_HEAP_SIZE
  • configCHECK_FOR_STACK_OVERFLOW

理解这些配置时，要关注它们影响的是：

  • 调度频率
  • 栈和堆大小
  • 调试能力
  • 系统资源上限

移植关注点 ​

移植一个 RTOS 到新平台时，重点通常不在应用层，而在以下部分：

  • 时钟节拍来源
  • 中断上下文切换
  • 栈初始化
  • 临界区管理
  • 编译器与架构适配

如果这些基础没对齐，后面再多的任务代码也很难稳定运行。

实践应用场景 ​

RTOS 常见的实践场景包括：

  • 传感器采集任务 + 通信任务 + 显示任务并行
  • 定时控制与外部中断协作
  • 网络接入与业务逻辑分层
  • 低功耗系统中的周期唤醒和事件响应

一个典型思路是：

  1. 把系统拆成若干稳定职责的任务
  2. 明确任务优先级
  3. 用合适的通信机制解耦
  4. 用日志、监控和栈检查保证稳定性

本章小结 ​

RTOS 的本质是帮助你在有限资源下有组织地安排任务执行。真正需要掌握的是调度规则、同步机制和错误模式，而不是单纯背诵某个 RTOS 的函数名。

以 GitHub Pages 发布，使用 VitePress 构建。

Content under CC BY-NC-SA 4.0 where applicable.