1. RTOS 概述：从裸机到实时内核
各位同学，咱们今天聊聊 RTOS。说实话，我最早接触嵌入式开发时，也觉得“不就一个循环加中断嘛，要啥操作系统？”后来被现实狠狠教育了一顿——项目越做越复杂，裸机代码像一团乱麻，改一个功能得排查半天。嗯，从那以后，我才真正理解了 RTOS 的价值。
1.1 什么是 RTOS？
RTOS，全称 Real-Time Operating System，实时操作系统。它和我们电脑上的 Windows、Linux 不一样。Windows 追求的是“平均响应快”，但偶尔卡一下没关系。RTOS 追求的是“确定性”——必须在规定时间内完成任务。
核心指标： RTOS 的实时性不是“快”，而是“可预测”。任务 A 的响应时间，在 1000 次运行中，最大值和最小值之间的抖动必须可控。
我做过一个工业控制项目，要求从传感器触发到执行器动作，延迟不能超过 500 微秒。裸机用中断能勉强做到，但一旦加入网络协议栈、LCD 刷新、按键扫描……中断嵌套一多，时序就崩了。换成 RTOS 后，把关键控制任务优先级拉高，其他任务靠后站，问题迎刃而解。
1.2 RTOS 与裸机系统的区别
裸机系统，说白了就是一个超级循环（Super Loop）加中断。你想想看，代码长这样：
void main(void)
{
while(1)
{
key_scan(); // 扫描按键
lcd_refresh(); // 刷新屏幕
sensor_read(); // 读取传感器
uart_send(); // 发送数据
}
}有什么问题？每个函数执行时间不确定。如果 sensor_read() 卡住了，按键响应就延迟了。中断虽然能抢断，但中断里不能做复杂处理，否则会影响其他中断。
RTOS 的做法是：把每个功能拆成独立的任务，调度器决定谁先跑、跑多久。
| 对比项 | 裸机系统 | RTOS |
|---|---|---|
| 任务管理 | 手动轮询 + 中断 | 任务独立，调度器管理 |
| 实时性 | 依赖中断优先级，不可预测 | 基于优先级抢占，确定性高 |
| 代码复杂度 | 低，但耦合度高 | 高，但模块化好 |
| 资源开销 | 几乎为零 | 需要 RAM/ROM 用于任务栈和内核 |
| 调试难度 | 逻辑简单，但改功能容易引入 bug | 需要理解调度、同步机制 |
| 适用场景 | 简单控制、超低功耗 | 多任务、复杂协议、人机交互 |
我的建议： 如果项目只有 2-3 个并发任务，且实时性要求不高，裸机完全够用。别为了用 RTOS 而用 RTOS，那叫过度设计。
1.3 主流 RTOS 介绍
市面上 RTOS 很多，我挑三个最常用的聊聊。我个人习惯是：小项目用 FreeRTOS，商业产品看客户要求，国产化项目用 RT-Thread。
FreeRTOS
- 开源免费，资料最多，社区活跃
- 内核极小，最小配置只需 4KB ROM、1KB RAM
- 支持任务、队列、信号量、互斥量、软件定时器
- 缺点：官方只提供内核，外设驱动、文件系统、网络协议栈需要自己移植
uC/OS-II / uC/OS-III
- 商业授权，代码严谨，文档齐全
- uC/OS-II 已停更，uC/OS-III 是主流
- 支持时间片轮转、任务级调试、内核对象丰富
- 缺点：商用需要付费，社区资源不如 FreeRTOS
RT-Thread
- 国产开源，中文文档友好
- 不仅提供内核，还有完整的组件生态：文件系统、网络、GUI、传感器框架
- 支持标准版和 Nano 版（极简内核）
- 缺点：大版本迭代快，API 偶有变动
避坑提醒： 我曾经在一个项目里选了某冷门 RTOS，结果芯片换了型号，官方不支持，社区没人回答，最后只能自己重写移植层。选 RTOS 时，生态比功能更重要。
1.4 RTOS 核心概念
这部分是基础，但也是面试常考题。我把它拆成四个维度：任务、调度、同步、内存。
任务（Task）
任务是 RTOS 的基本执行单元。每个任务有自己的栈空间、优先级、状态。任务状态包括：
- 就绪（Ready）： 等待 CPU
- 运行（Running）： 正在使用 CPU
- 阻塞（Blocked）： 等待某个事件（信号量、队列、延时）
- 挂起（Suspended）： 人为暂停
调度（Scheduling）
调度器决定哪个就绪任务获得 CPU。主流方式有两种：
- 抢占式调度： 高优先级任务就绪时，立即抢断低优先级任务。这是 RTOS 实现实时性的关键。
- 时间片轮转： 同优先级任务轮流执行，每个任务跑一个时间片（通常 1-10ms）。
注意： 抢占式调度不是万能的。如果高优先级任务一直不阻塞，低优先级任务永远得不到 CPU——这叫“优先级饥饿”。解决办法是让高优先级任务适当阻塞或降低优先级。
同步与通信（Synchronization & Communication）
任务之间需要协作。RTOS 提供了几种机制：
- 信号量（Semaphore）： 用于资源管理或事件通知。二值信号量像一把钥匙，计数信号量像停车场空位。
- 互斥量（Mutex）： 带优先级继承的信号量，防止优先级反转。
- 队列（Queue）： 任务间传递数据，先进先出。
- 事件标志组（Event Group）： 等待多个事件同时或任意发生。
内存管理（Memory Management）
RTOS 的内存管理比裸机复杂。常见方式：
- 静态分配： 编译时分配好任务栈、队列缓冲区。优点是确定性强，无碎片；缺点是灵活性差。
- 动态分配： 运行时用 malloc/free。优点是灵活；缺点是可能产生碎片，且分配时间不确定。
- 内存池（Memory Pool）： 预分配固定大小的块，分配和释放时间固定，无碎片。我比较推荐这种方式。
个人经验： 在安全关键系统中（如医疗、汽车），我从来不用动态内存分配。所有任务栈、队列、信号量都在初始化时静态创建。虽然代码写起来麻烦点，但运行时不会出现“内存不足”这种致命问题。
1.5 RTOS 核心知识体系
下面这张图，是我自己总结的 RTOS 学习路线。你把它存下来，后面每一章都会用到。
1.6 本章小结
这一章我们聊了 RTOS 是什么、和裸机有什么区别、主流 RTOS 有哪些、核心概念怎么理解。说白了，RTOS 就是一套帮你管理多任务的“调度框架”。你不需要自己写轮询、不用操心任务切换的现场保护，这些内核都帮你做了。
但记住，RTOS 不是银弹。它引入的额外开销（任务切换、中断延迟、内存占用）在某些场景下反而是负担。选不选 RTOS，选哪个 RTOS，取决于你的项目需求，而不是跟风。