第二讲：实时操作系统(RTOS)基础
各位同学，今天我们聊聊RTOS的基础。说实话，很多做ADAS的工程师，一开始都分不清RTOS和GPOS到底差在哪。我当年刚入行时也踩过这个坑——用Linux做实时控制，结果中断响应延迟直接让系统崩溃。嗯，今天咱们就把这事彻底讲明白。
一、RTOS与GPOS：本质区别在哪？
先问大家一个问题：你手机上的Android系统，和ADAS里的RTOS，都是操作系统，为什么不能互换？
答案其实很简单：确定性。
GPOS（通用操作系统）追求的是平均性能。它希望大多数任务都能跑得快，但某个任务偶尔卡顿一下，没关系。你刷抖音时突然卡半秒，顶多骂一句，不会出人命。
RTOS追求的是最差情况下的性能。它必须保证每个关键任务都在规定时间内完成。ADAS里，摄像头数据来了，你必须10毫秒内处理完，否则刹车晚半秒，车就撞上了。
我整理了一个对比表，大家一看就明白：
| 特性 | GPOS（如Linux） | RTOS（如FreeRTOS） |
|---|---|---|
| 调度策略 | 公平调度（CFS） | 优先级抢占 |
| 中断延迟 | 不确定（ms级） | 确定（us级） |
| 任务切换 | 依赖内核态切换 | 轻量级上下文切换 |
| 内存管理 | 虚拟内存、MMU | 静态分配为主 |
| 典型应用 | 手机、服务器 | ADAS、工业控制 |
核心要点：RTOS不是更快，而是更确定。我见过有人把Linux实时补丁（PREEMPT_RT）用在ADAS上，结果还是偶尔抖一下。为什么？因为Linux内核里有些临界区太长，关中断时间不可控。说白了，底子就不一样。
二、任务状态机：就绪、运行、阻塞、挂起
RTOS里的任务，说白了就是一段代码，但它有生命周期。我习惯把任务状态机比作「人的一天」：
- 就绪（Ready）：你起床了，但还没轮到你用厕所。任务已经准备好运行，但CPU正忙着别的任务。
- 运行（Running）：你终于进了厕所，正在办事。任务正在占用CPU执行。
- 阻塞（Blocked）：你在等外卖，啥也干不了。任务在等待某个事件（信号量、消息队列、延时等）。
- 挂起（Suspended）：你被关禁闭了，谁叫都不好使。任务被显式暂停，需要别人唤醒。
这里有个容易混淆的点：阻塞和挂起有什么区别？
我举个例子。你在等红绿灯（阻塞），灯变绿了你就能走。但如果你被警察拦下（挂起），就算灯绿了你也走不了，得等警察放你走。阻塞是被动等待资源，挂起是主动或被动暂停。
避坑指南：我曾经在项目中遇到一个bug——某个传感器任务一直不执行。查了半天，发现是任务在等待一个永远不会来的信号量，进入了阻塞状态。但代码里没有超时处理，任务就永远卡在那了。所以，所有阻塞调用都要加超时，这是ADAS开发的铁律。
状态转换图可以用文字描述：
创建 → 就绪 → 运行 → 阻塞 → 就绪（事件到达）
↓
挂起 → 就绪（显式恢复）
三、上下文切换开销分析
上下文切换，说白了就是CPU从一个任务切到另一个任务时，要保存现场、恢复现场。这个开销有多大？我直接说结论：通常几微秒到几十微秒。
具体开销包括：
- 保存寄存器：通用寄存器、PC、SP、状态寄存器等。ARM Cortex-M系列大概要保存16-32个寄存器。
- 切换栈指针：从当前任务的栈切到新任务的栈。
- 恢复寄存器：把新任务的寄存器值从栈里弹出来。
- 刷新TLB/缓存：如果用了MMU，还得清TLB，这个开销很大。
我给大家一个实际数据。在Cortex-M4上跑FreeRTOS，一次上下文切换大约需要：
| 操作 | 时钟周期 | 时间（@200MHz） |
|---|---|---|
| 保存寄存器 | ~50 | 0.25us |
| 切换栈指针 | ~5 | 0.025us |
| 恢复寄存器 | ~50 | 0.25us |
| 调度器决策 | ~100 | 0.5us |
| 总计 | ~205 | ~1us |
注意：这个数据是理想情况。如果任务数量多、优先级复杂，调度器决策时间会变长。另外，如果用了FPU（浮点单元），保存/恢复FPU寄存器还要额外加几十个周期。我在一个项目中，因为FPU上下文切换没优化，导致中断延迟从5us飙到了30us。嗯，后来我把FPU寄存器改成懒加载（Lazy Stacking），才把性能救回来。
如何降低上下文切换开销？我分享几个实战经验：
- 减少任务数量：不是越多越好。ADAS里我一般控制在10-15个任务以内。
- 合理设置优先级：高优先级任务不要太多，否则频繁抢占，切换开销剧增。
- 使用中断替代任务：对于极短的处理（比如读取传感器数据），用中断服务函数（ISR）比用任务更高效。
- 避免频繁阻塞：任务如果每1ms就阻塞一次，那切换开销就占了CPU的10%以上。
总结一下：RTOS的核心价值在于确定性。任务状态机是理解RTOS的钥匙，上下文切换是性能的命门。你想想看，如果ADAS系统里一个紧急刹车任务因为上下文切换慢了10us，那在高速上可能就是几米的刹车距离。所以，每一微秒都要精打细算。
下一讲，我们会深入中断设计，看看如何让硬件中断和RTOS任务协同工作。到时候我会分享一个我踩过的坑——中断里调了RTOS API导致死锁，差点让项目延期。嗯，到时候细聊。