3. 任务优先级设计：优先级反转问题与RMS分配方法
好，咱们进入第三个实战话题——任务优先级设计。这块内容，说简单也简单，说复杂，它能把整个系统搞崩。我见过太多TCU项目，明明每个任务单独跑都没问题，一合在一起就出乱子。十有八九，问题出在优先级上。
3.1 优先级反转——那个让系统“假死”的幽灵
先说说优先级反转。这名字听着挺学术，其实说白了就是：一个低优先级的任务，把高优先级任务给“堵”住了。
为什么会这样？我给你画个场景。
假设有三个任务：
- Task_H：高优先级，负责牵引电流的紧急切断（必须实时响应）
- Task_M：中优先级，负责通信报文处理
- Task_L：低优先级，负责日志记录
三个任务共享一个互斥锁，保护某段关键数据。
正常情况是这样的：Task_L先拿到锁，正在写日志。突然Task_H就绪了，它想拿锁，但锁被Task_L占着。Task_H只能等。这时候Task_L应该赶紧释放锁对吧？但别忘了，Task_M来了！Task_M优先级比Task_L高，它直接抢占了Task_L的CPU。Task_L被挂起，锁没释放。Task_H呢？还在那傻等。你看，一个中优先级的Task_M，硬是把最高优先级的Task_H给“饿死”了。
核心问题：优先级反转的本质，是共享资源（锁）的持有者被更高优先级的任务抢占，导致等待该资源的更高优先级任务被间接阻塞。
我在项目中遇到过这种情况。有一次在调试TCU的过流保护功能时，明明过流信号已经触发了，但保护动作延迟了将近200毫秒。查到最后，就是优先级反转。一个低优先级的ADC校准任务占着锁，被通信任务抢断，紧急保护任务只能干瞪眼。嗯，那次之后，我对锁的使用就格外小心了。
3.2 解决优先级反转的三种武器
怎么解决？业界有几种成熟做法。我按推荐程度排个序。
3.2.1 优先级继承协议
这是最常用的方法。核心思想：当低优先级任务持有高优先级任务需要的锁时，低优先级任务临时“继承”高优先级的优先级。这样，中优先级的任务就没法抢占它了。等锁释放了，优先级再降回去。
在FreeRTOS中，互斥量（Mutex）默认就支持优先级继承。我建议你在TCU中所有可能引起阻塞的共享资源，都用Mutex而不是二值信号量。
// 推荐：使用互斥量（带优先级继承）
xSemaphoreHandle xMutex = xSemaphoreCreateMutex();
// 不推荐：使用二值信号量（无优先级继承）
// xSemaphoreHandle xBinary = xSemaphoreCreateBinary();我的习惯：只要涉及任务间共享数据，一律用Mutex。哪怕你觉得“这个数据很简单，不会冲突”，也别偷懒。我曾经因为一个全局标志位没用Mutex，导致两个任务同时修改它，最后牵引力输出抖动。排查了两天才找到原因。
3.2.2 优先级天花板协议
这个更激进一点。系统给每个资源设定一个“天花板优先级”——也就是所有可能使用该资源的任务中，最高的那个优先级。当任何任务拿到锁时，它的优先级立刻被提升到天花板级别。这样，所有中优先级的任务都无法抢占它。
这个协议的好处是简单粗暴，坏处是可能导致优先级提升过度，影响系统实时性。我个人不太常用，除非是极其关键的资源。
3.2.3 禁止中断法
最原始的方法。在访问共享资源时，关中断。但这个方法在TCU中要慎用——关中断时间太长，会错过重要的外部事件（比如速度脉冲信号）。我一般只在临界区极短（几个指令周期）的情况下才用。
// 关中断方式（慎用）
taskENTER_CRITICAL();
// 访问共享资源（必须极短）
shared_var = new_value;
taskEXIT_CRITICAL();3.3 基于速率单调调度（RMS）的优先级分配
好，解决了反转问题，咱们聊聊优先级怎么分配。很多新手工程师喜欢拍脑袋：“这个任务重要，给高优先级；那个任务不重要，给低优先级。” 结果系统跑起来，低优先级任务永远得不到CPU时间——这叫“任务饿死”。
RMS（Rate Monotonic Scheduling）是一种数学上证明最优的静态优先级分配方法。它的核心原则就一句话：任务的周期越短，优先级越高。
你想想看，周期短的任务意味着它需要更频繁地执行，如果它的优先级低，很容易被长周期任务堵住，导致错过截止时间。RMS正好解决了这个问题。
3.3.1 RMS的分配步骤
- 列出所有周期性任务，记录它们的周期T和执行时间C
- 按周期从小到大排序（周期最短的排最前面）
- 优先级从高到低分配：周期最短的给最高优先级
举个例子，TCU中的典型任务：
| 任务名称 | 周期T (ms) | 执行时间C (ms) | RMS优先级 |
|---|---|---|---|
| 电流环控制 | 0.1 | 0.02 | 最高（1） |
| 速度检测 | 1 | 0.1 | 高（2） |
| 通信处理 | 10 | 0.5 | 中（3） |
| 日志记录 | 100 | 2 | 低（4） |
你看，电流环控制周期只有0.1ms，必须给最高优先级。日志记录100ms才跑一次，优先级最低完全没问题。
注意：RMS有一个可调度性条件。对于n个任务，如果所有任务的利用率U ≤ n(2^(1/n) - 1)，那么系统是可调度的。当n很大时，这个上限趋近于ln2 ≈ 0.693。也就是说，CPU利用率超过69.3%时，RMS就不能保证所有任务都能按时完成。我在实际项目中，一般把利用率控制在60%以下，留点余量。
3.3.2 RMS的局限性
RMS不是万能的。它假设所有任务都是周期性的，且任务之间没有依赖关系。但在TCU中，有些任务是事件触发的（比如过流保护），不是周期性的。对于这类任务，我通常的做法是：
- 如果是紧急事件（如过流、过温），给最高优先级，甚至用中断处理
- 如果是非紧急事件（如参数配置），给最低优先级，用后台任务处理
3.4 实战中的优先级设计建议
说了这么多理论，最后给几条我在TCU项目中的实际经验。
- 先分层次，再定优先级。我习惯把任务分成三层：实时控制层（电流环、速度环）、实时通信层（CAN、以太网）、非实时管理层（日志、诊断）。每层内部再用RMS分配。
- 给关键任务留“安全垫”。比如电流环理论上需要0.02ms执行时间，我给它分配0.05ms的时间预算。这样即使有抖动，也不会出问题。
- 避免优先级“平级”。同一优先级的任务，如果都就绪了，系统怎么选？靠时间片轮转。但时间片轮转在实时系统中是灾难——你无法预测哪个任务先执行。我建议每个任务优先级都不同，哪怕只差1。
- 用工具验证。别光靠脑子想。我用过Tracealyzer和SystemView来观察任务的实际执行情况。有一次我发现一个任务的实际执行时间比理论值大了3倍，查出来是某个函数里有个死循环。这种问题，光看代码是看不出来的。
避坑指南：我曾经在一个项目中，把所有中断的优先级都设成了相同级别。结果两个中断同时触发时，系统直接卡死。后来才意识到，中断优先级必须唯一，且不能与任务优先级混淆。记住：中断是中断，任务是任务，它们是两套优先级体系。
好，优先级设计这块就聊到这儿。下一章咱们讲任务间通信——怎么让任务之间高效、安全地交换数据。那又是一个容易踩坑的地方。