第4章 RTOS任务调度

第4章：RTOS任务调度：任务优先级设计、抢占式调度优化、任务间通信性能对比

各位好，我是老张。这一章咱们聊聊RTOS任务调度。说实话，在医疗显微镜项目里，任务调度这块要是没搞好，画面卡顿、数据丢包、响应延迟，这些问题全都会找上门来。我当年第一次做显微镜项目时，就因为在优先级设计上偷了个懒，结果调试了整整两周才找到问题根源。

4.1 任务优先级设计——别让高优先级任务“饿死”低优先级任务

任务优先级，说白了就是给每个任务排个队。谁重要谁先跑。但这里有个坑——优先级反转。

核心原则：实时性要求越高的任务，优先级越高。但要注意，优先级不是越多越好，一般8-16级就够用了。

我在医疗显微镜项目中，把任务分成了三类：

硬实时任务（优先级最高）：图像采集、电机控制、紧急停止。这些任务必须在规定时间内完成，否则后果严重。
软实时任务（中等优先级）：图像处理、数据通信、UI刷新。可以偶尔延迟，但不能频繁丢帧。
后台任务（最低优先级）：日志记录、自检、统计。晚几秒处理完全没问题。

举个例子，我习惯这样分配优先级：

// 任务优先级定义
#define TASK_PRIO_EMERGENCY    5   // 紧急停止
#define TASK_PRIO_MOTOR        4   // 电机控制
#define TASK_PRIO_IMAGE_CAPTURE 3  // 图像采集
#define TASK_PRIO_IMAGE_PROCESS 2  // 图像处理
#define TASK_PRIO_COMM         1   // 通信
#define TASK_PRIO_UI           1   // UI刷新（与通信同级）
#define TASK_PRIO_LOGGING      0   // 日志记录

避坑指南：我曾经把图像采集和电机控制设成同一优先级，结果电机启动时采集任务被卡住，画面直接卡死。后来我把电机控制优先级调高一级，问题就解决了。记住：共享资源的任务，优先级要错开。

4.2 抢占式调度优化——别让上下文切换吃掉你的CPU

抢占式调度，说白了就是高优先级任务随时可以打断低优先级任务。这听起来很美好，但代价是上下文切换。

每次切换，CPU都要保存当前任务的寄存器、堆栈指针，再加载新任务的上下文。这个开销，在低端MCU上可能达到几十微秒。你想想看，如果切换频率太高，CPU时间全浪费在切换上了。

我建议从三个方面优化：

减少不必要的抢占：如果两个任务没有紧迫的时间要求，可以考虑用协作式调度，或者把它们的优先级设成一样，用时间片轮转。
临界区要短：关中断的时间越长，系统响应越差。我一般要求临界区不超过10条指令。
任务不要跑得太频繁：有些任务其实不需要每毫秒都跑。比如UI刷新，30Hz就够了，没必要跑100Hz。

这里有个实际案例。我在优化显微镜的自动对焦功能时，发现电机控制任务每1ms触发一次，但实际电机响应时间在5ms左右。我把触发周期改成5ms，CPU占用率直接降了40%。

注意：抢占式调度下，如果高优先级任务一直不释放CPU，低优先级任务会“饿死”。我曾经遇到过图像处理任务占用了80%的CPU时间，导致通信任务收不到数据，上位机直接报错。解决方案是给高优先级任务加一个“时间片限制”，或者用事件驱动代替轮询。

4.3 任务间通信性能对比——队列 vs 信号量

任务间通信，常用的有两种：队列和信号量。很多人觉得它们差不多，其实性能差异很大。

通信方式	数据传输量	阻塞时间	适用场景
队列	可传输多个数据（消息）	较长（需拷贝数据）	传递数据块、命令、事件
信号量	仅传递“信号”（无数据）	极短（仅增减计数）	同步、互斥、资源计数

我做个性能对比测试，在STM32F407上跑FreeRTOS：

// 队列方式：发送一个32位整数
void task_sender(void *param) {
    int32_t data = 0x12345678;
    while(1) {
        xQueueSend(queue_handle, &data, 0);
        vTaskDelay(10);
    }
}

// 信号量方式：仅通知接收任务
void task_sender(void *param) {
    while(1) {
        xSemaphoreGive(sem_handle);
        vTaskDelay(10);
    }
}

测试结果：

队列发送：平均耗时约 12μs（含数据拷贝）
信号量发送：平均耗时约 3μs（仅计数操作）
队列接收：平均耗时约 15μs（含数据拷贝和队列管理）
信号量接收：平均耗时约 4μs（仅等待计数）

看到了吧？信号量比队列快4-5倍。但信号量不能传数据，只能传“信号”。

我的建议：

如果只是通知任务“有事情做了”，用信号量。比如图像采集完成后通知处理任务。
如果需要传递具体数据（比如图像帧、坐标值），用队列。但数据量大的话，建议用“指针队列”，只传地址，不拷贝数据。
如果既要传数据又要同步，可以用“队列+信号量”组合，但别过度设计。

我记得有一次，一个同事用队列传递一个1KB的图像块，结果CPU占用率飙升。我让他改成用共享内存+信号量的方式，性能直接翻倍。说白了，数据拷贝是性能杀手，能避免就避免。

4.4 实战经验总结

嗯，这一章的内容差不多就这些。最后我总结几条实战经验：

优先级设计要留有余地：别把优先级用满，留1-2级给紧急情况。
抢占式调度不是万能的：高频率切换会浪费CPU，适当用时间片轮转。
通信方式选对很重要：信号量快但功能单一，队列灵活但开销大。
一定要做性能测试：别凭感觉优化，用逻辑分析仪或RTOS的跟踪工具看实际数据。

下一章我会讲内存管理，包括堆栈分配、内存碎片处理，还有DMA的高效使用。到时候见。

📚 课程目录