第2章实时操作系统基础

第2章：实时操作系统基础：RTOS任务调度、中断管理、时钟节拍、任务优先级设计

各位好，我是老陈。做制动控制这些年，我最大的体会就是——实时操作系统不是选不选的问题，而是怎么用好它的问题。今天咱们聊聊RTOS的几个核心模块：任务调度、中断管理、时钟节拍，还有优先级设计。这些概念听起来基础，但实际项目中踩的坑，往往就出在这些“基础”上。

2.1 任务调度：谁先跑，谁后跑？

任务调度，说白了就是操作系统决定“下一个该谁执行”。制动控制里，任务调度直接决定了你的刹车指令能不能在1ms内响应。

我习惯把调度策略分成三类：

抢占式调度：高优先级任务来了，低优先级的立马让路。制动控制里，紧急制动任务必须抢占常规控制任务。
时间片轮转：同等优先级的任务轮流跑。适合那些“不急但别饿死”的任务，比如状态监控。
协作式调度：任务自己决定什么时候让出CPU。嗯，这个在制动系统里我基本不用——你想想看，万一哪个任务忘了让出CPU，刹车就没了。

关键点：制动控制必须用抢占式调度。这是底线。

我在项目中遇到过一个问题：一个低优先级的诊断任务占用了某个共享资源，高优先级的制动任务被阻塞了。结果就是——刹车指令延迟了2ms。2ms在制动里是什么概念？车速60km/h时，刹车距离多了3厘米。嗯，这3厘米可能就是事故和安全的区别。

2.2 中断管理：别让中断“喧宾夺主”

中断是RTOS的“快车道”。制动控制里，轮速传感器、制动踏板位置传感器这些信号，都是通过中断进来的。

我个人习惯把中断处理分成两部分：

中断服务程序（ISR）：只做最紧急的事，比如读取传感器数据、清除中断标志。时间控制在10微秒以内。
中断下半部（Bottom Half）：把数据交给任务去处理。比如计算滑移率、判断是否触发ABS。

我的经验：ISR里千万别做复杂运算。我曾经见过一个同事在ISR里做浮点PID计算，结果中断嵌套导致系统崩溃。记住：ISR里只做“搬砖”的活，计算交给任务。

中断优先级怎么设？我有个原则：时间越紧急，优先级越高。比如：

中断源	优先级	说明
制动踏板中断	最高	驾驶员意图，必须立即响应
轮速传感器中断	高	实时性要求高，但可以容忍几微秒延迟
CAN通信中断	中	数据帧接收，可以稍微排队
系统定时器中断	低	时钟节拍，延迟一点问题不大

注意：中断优先级不要超过RTOS内核的临界区保护级别。否则，你可能会在中断里调用一个需要获取互斥锁的函数——死锁就来了。

2.3 时钟节拍：系统的“心跳”

时钟节拍（Tick）是RTOS的“心跳”。它决定了任务调度的粒度。制动控制里，我一般把Tick设为1ms。为什么？

制动控制周期通常是1ms-5ms。Tick太粗（比如10ms），任务调度就不够精细。
Tick太细（比如0.1ms），系统开销太大。CPU都在处理Tick中断了，哪还有时间算控制算法？

我记得有一次，为了追求“极致实时性”，我把Tick设成了0.5ms。结果呢？系统负载从30%飙升到80%，控制周期反而变长了。嗯，这就是过犹不及。

建议：Tick设为控制周期的一半或三分之一。比如控制周期是2ms，Tick设1ms。这样既能保证调度精度，又不会浪费CPU。

2.4 任务优先级设计：别让“饿死”发生

任务优先级设计，是制动控制里最容易出问题的地方。我见过太多“优先级反转”导致的故障了。

先说说优先级反转是什么：

假设有三个任务：A（高优先级，制动控制）、B（中优先级，状态显示）、C（低优先级，数据记录）。C拿到了一个共享资源的锁，A来了想用这个资源，被阻塞。这时候B来了，它不需要这个资源，所以B抢占了C。结果就是——A被B间接阻塞了。这就是优先级反转。

怎么解决？我习惯用优先级继承：当高优先级任务被低优先级任务阻塞时，低优先级任务临时“继承”高优先级的优先级。这样B就不能抢占C了，A就能尽快拿到资源。

避坑指南：我曾经在一个项目中，因为没启用优先级继承，导致制动任务被显示任务阻塞了5ms。那一次测试，车辆在湿滑路面上差点失控。从那以后，我所有制动控制项目都强制启用优先级继承。

任务优先级怎么分配？我有个“三区法”：

紧急区（优先级最高）：制动控制、安全监控。这些任务必须“说一不二”。
实时区（优先级中等）：状态采集、控制输出。可以容忍少量延迟。
后台区（优先级最低）：日志记录、诊断通信。跑慢点没关系。

你想想看，如果日志记录任务和制动控制任务抢CPU，那还得了？

2.5 实战建议：从理论到代码

说了这么多，咱们看看实际代码怎么写。以FreeRTOS为例：

// 任务优先级定义
#define PRIO_BRAKE_CONTROL    5   // 制动控制，最高
#define PRIO_SENSOR_READ      4   // 传感器读取
#define PRIO_CAN_COMM         3   // CAN通信
#define PRIO_DIAGNOSTIC       1   // 诊断，最低

// 创建任务
xTaskCreate(brake_control_task, "BrakeCtrl", 256, NULL, PRIO_BRAKE_CONTROL, NULL);
xTaskCreate(sensor_read_task,   "SensorRd",  128, NULL, PRIO_SENSOR_READ,   NULL);
xTaskCreate(can_comm_task,      "CANComm",   128, NULL, PRIO_CAN_COMM,      NULL);
xTaskCreate(diagnostic_task,    "Diag",      256, NULL, PRIO_DIAGNOSTIC,    NULL);

// 中断服务程序 - 只做最紧急的事
void brake_pedal_ISR(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    // 读取踏板位置
    pedal_position = read_adc(BRAKE_PEDAL_CH);
    // 通知制动任务
    vTaskNotifyGiveFromISR(brake_control_handle, &xHigherPriorityTaskWoken);
    // 如果制动任务优先级更高，立即切换
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

核心原则：中断里只做“通知”，不做“处理”。处理逻辑交给任务。

最后说一句：RTOS不是万能的。它只是工具，关键还是你怎么设计。我见过太多人把RTOS当成“万能药”，结果系统反而更不稳定。记住：好的设计，比好的RTOS更重要。

下一章，咱们聊聊任务间通信——怎么让任务之间高效、安全地交换数据。制动控制里，这步走错了，后果很严重。

📚 课程目录