第二章：RTOS内核基础——任务调度、中断管理与内存管理
各位同学，咱们今天聊聊RTOS内核最核心的三个模块：任务调度、中断管理和内存管理。说实话，这三个东西搞明白了，RTOS就算入门了。我在车载项目里踩过的坑，十有八九都跟它们有关。
2.1 任务调度机制——谁先跑，谁后跑？
任务调度，说白了就是决定“下一个该谁上CPU跑”。RTOS不是真的让多个任务同时跑，而是通过快速切换，让你感觉它们在同时跑。嗯，这里有个关键点：切换的时机和策略。
2.1.1 调度策略：优先级抢占 vs 时间片轮转
车载系统里，我几乎只用优先级抢占式调度。为什么？因为安全相关的任务必须立刻响应。比如刹车信号来了，你总不能等一个音乐播放任务跑完再去处理吧？
- 优先级抢占：高优先级任务就绪，立刻抢走CPU。我习惯把安全任务（如CAN报文处理）设成最高优先级。
- 时间片轮转：同等优先级的任务轮流跑，每人分一个时间片。适合那些“谁先跑都行”的后台任务。
避坑指南：我曾经在一个项目中，把所有任务都设成了相同优先级，结果系统响应慢得像蜗牛。后来才发现，时间片轮转下，高频率的中断任务根本抢不到CPU。记住：优先级不是摆设，得按实时性需求来分。
2.1.2 任务状态机：就绪、运行、阻塞、挂起
每个任务在RTOS里都有生命周期。我画过一张状态图，贴在工位上，每次调试都看一眼：
| 状态 | 说明 | 触发条件 |
|---|---|---|
| 就绪 | 任务准备好了，等CPU | 创建完成、阻塞解除 |
| 运行 | 正在占用CPU | 调度器选中它 |
| 阻塞 | 在等某个事件（信号量、队列等） | 调用阻塞API |
| 挂起 | 被强制暂停 | 调用挂起API |
你想想看，如果一个任务永远在“就绪”状态却跑不上CPU，那多半是优先级设置出了问题。我遇到过最离谱的一次，是某个任务因为等待的信号量永远没人释放，直接“饿死”了。
2.1.3 上下文切换——代价有多大？
每次任务切换，RTOS都要保存当前任务的寄存器、堆栈指针，再恢复下一个任务的。这个操作叫上下文切换。切换一次大概要几微秒到几十微秒，取决于硬件和RTOS实现。
我的经验：在车载项目中，我一般把任务切换频率控制在1ms以上。太频繁了，CPU全花在切换上了，实际干活的时间反而少。你可以用示波器量一下GPIO翻转的波形，看看切换开销到底多大。
2.2 中断管理——别让中断“打架”
中断是RTOS的“心脏起搏器”。没有中断，任务调度就失去了驱动力。但中断管理不好，系统就会崩溃。我见过最惨的一次，是中断嵌套太深，直接把堆栈撑爆了。
2.2.1 中断优先级与嵌套
大多数RTOS支持中断优先级。高优先级中断可以打断低优先级中断，这叫中断嵌套。但嵌套层数不能太多，否则堆栈会溢出。
- 中断优先级：一般0最高，数值越大优先级越低。车载里，我通常把定时器中断设成最高，因为它负责系统心跳。
- 中断嵌套：允许高优先级中断打断低优先级。但嵌套超过3层，我就开始警惕了。
警告：我曾经在一个项目中，中断嵌套达到了5层。结果系统偶尔死机，查了三天才发现是堆栈溢出。后来我强制限制嵌套层数不超过2层，问题就解决了。记住：中断服务函数（ISR）里别干太多活，尽量只做标记，把实际处理交给任务。
2.2.2 中断与任务的同步——信号量与消息队列
中断来了，数据到了，怎么告诉任务？我常用的方法是：
- 信号量：中断里释放信号量，任务等待信号量。适合“事件通知”场景。
- 消息队列：中断里把数据塞进队列，任务从队列里取。适合“数据传递”场景。
举个例子，CAN中断来了，我把报文塞进消息队列，然后唤醒处理任务。这样ISR里只花几微秒，剩下的交给任务慢慢处理。
// 伪代码示例：中断中释放信号量
void CAN_ISR(void) {
uint32_t data = CAN->DR; // 读数据
xQueueSendFromISR(can_queue, &data, NULL); // 从ISR发送到队列
xSemaphoreGiveFromISR(can_sem, NULL); // 释放信号量
}小技巧：从ISR里调用RTOS API时，一定要用带“FromISR”后缀的函数。普通API可能会引起任务切换，在中断里调用会出大问题。我刚开始学RTOS时，就因为这个原因导致系统死锁过。
2.3 内存管理基础——别让内存“碎片化”
车载系统内存有限，动不动就几MB甚至几百KB。怎么高效管理？RTOS提供了几种方案，但各有坑。
2.3.1 静态分配 vs 动态分配
| 分配方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 静态分配 | 确定性强，无碎片 | 浪费内存，灵活性差 | 安全关键任务（如刹车控制） |
| 动态分配 | 灵活，节省内存 | 可能产生碎片，速度慢 | 非安全任务（如日志记录） |
我个人习惯：安全任务用静态分配，非安全任务用动态分配。这样既保证了确定性，又节省了内存。
2.3.2 内存碎片——RTOS的“慢性病”
动态分配用久了，内存会碎成一块一块的。比如你分配了10字节、20字节、30字节，然后释放了中间的20字节，剩下的10字节和30字节之间就空了一块。下次想分配25字节，可能就找不到连续空间了。
避坑指南：我曾经在一个车载项目中，系统跑了72小时后突然报内存分配失败。查了半天，发现是内存碎片太多。后来我改用固定大小内存块（比如所有消息都分配64字节），碎片问题就解决了。你想想看，固定大小块之间不会产生碎片，因为释放后可以重新利用。
2.3.3 堆栈管理——每个任务都有自己的“小仓库”
每个任务都有自己的堆栈，用来保存局部变量、函数调用信息。堆栈大小设置很关键：
- 太小：堆栈溢出，系统崩溃。
- 太大：浪费内存，可能不够用。
我一般这样估算：任务里最深层的函数调用链，加上局部变量大小，再乘以1.5的安全系数。比如一个任务最深调用5层函数，每层用100字节，局部变量200字节，那堆栈至少设成(5*100+200)*1.5=1050字节。
我的经验：调试阶段，我会把堆栈设大一点（比如2KB），然后通过RTOS提供的堆栈使用统计API，看看实际用了多少。等稳定了再调小。FreeRTOS里可以用uxTaskGetStackHighWaterMark()来查看剩余堆栈空间。
小结
好了，这一章的内容就这些。任务调度、中断管理、内存管理，这三个东西是RTOS的“三驾马车”。你只要把优先级设置合理、中断处理简洁、内存分配谨慎，车载系统基本就稳了。下一章咱们聊聊故障注入的具体方法，到时候我会拿实际案例来演示。
记住：RTOS不是万能的，但用好了，它能帮你写出稳定可靠的车载软件。嗯，今天就到这里，有问题随时问我。