第1章：任务调度基础——任务状态机与上下文切换开销分析
各位同学，大家好。我是老张，在医疗设备嵌入式这行摸爬滚打了十几年。今天咱们开始聊麻醉机、呼吸机这类生命支持设备的实时性保障问题。说实话，这话题我每次讲都觉得责任重大——毕竟代码跑在机器上，另一端连着的是病人的生命。
第一章，咱们先打地基。任务调度，说白了就是操作系统怎么管这些任务。你想想看，麻醉机里同时要跑气体监测、报警处理、用户界面刷新、数据记录……这么多活儿，谁先干谁后干？这就得靠调度器来安排。
1.1 任务状态机：就绪、运行、阻塞、挂起
每个任务在它的生命周期里，会经历几种状态。我习惯用状态机来理解，这样逻辑特别清晰。常见的状态有四种：就绪、运行、阻塞、挂起。
核心概念：任务在任何时刻，只能处于其中一种状态。状态之间的转换由调度器和任务自身的行为触发。
- 就绪（Ready）：任务已经准备好运行，只等CPU空闲。说白了就是“万事俱备，只欠东风”。
- 运行（Running）：任务正在占用CPU，执行它的代码。同一时刻，单核CPU上只能有一个任务在运行。
- 阻塞（Blocked）：任务在等待某个事件，比如等待一个信号量、等待I/O完成、等待延时到期。这时候任务不参与CPU竞争。
- 挂起（Suspended）：任务被显式暂停，通常由其他任务或中断服务程序触发。挂起的任务需要被显式恢复才能回到就绪态。
我在项目中遇到过一个问题：有个同事把阻塞和挂起搞混了。他在等待串口数据时用了挂起操作，结果数据到了之后任务醒不过来，整个系统卡死。嗯，这里要注意——阻塞是任务主动等待资源，挂起是被动暂停，两者有本质区别。
1.2 状态转换图
咱们用文字描述一下状态转换的路径：
- 就绪 → 运行：调度器选中该任务，分配CPU。这叫“任务被调度”。
- 运行 → 就绪：时间片用完，或者被更高优先级的任务抢占。任务“被踢出”CPU。
- 运行 → 阻塞：任务主动调用阻塞API，比如等待队列、等待信号量。
- 阻塞 → 就绪：等待的事件发生，任务被唤醒，回到就绪队列排队。
- 运行 → 挂起：其他任务或中断调用了任务挂起函数。
- 挂起 → 就绪：任务被恢复，重新进入就绪队列。
个人经验：我建议你在设计任务时，画一张状态转换图贴在工位上。尤其是阻塞和挂起的路径，画出来之后很多逻辑漏洞一眼就能看出来。我曾经靠这张图，在评审时发现了一个死锁隐患——一个任务在等待信号量，而释放信号量的任务自己也被挂起了，典型的“自己等自己”。
1.3 上下文切换开销分析
上下文切换，就是CPU从一个任务切换到另一个任务时，要保存当前任务的“现场”，再恢复下一个任务的“现场”。这个“现场”包括：CPU寄存器、程序计数器、栈指针、浮点寄存器（如果有）、MMU配置（如果有）等等。
你想想看，每次切换都要做这些操作，肯定要花时间。这个时间就是上下文切换开销。
| 切换类型 | 典型开销（ARM Cortex-M4 @ 168MHz） | 说明 |
|---|---|---|
| 任务→任务（同优先级） | 约 3-5 µs | 需要保存/恢复全部通用寄存器 |
| 任务→任务（不同优先级） | 约 5-8 µs | 额外需要处理优先级相关的调度逻辑 |
| 中断→任务 | 约 2-3 µs | 硬件自动压栈，软件开销较小 |
| 任务→中断 | 约 1-2 µs | 硬件自动完成大部分工作 |
这些数字是我在FreeRTOS上实测的，不同RTOS和硬件平台会有差异。但你可以看到，一次切换大概在微秒级别。听起来不多，对吧？但别忘了——麻醉机的控制周期可能是1ms甚至500µs。如果切换太频繁，有效计算时间就被压缩了。
避坑指南：我曾经在一个项目中，为了追求“响应快”，把任务切得很细，结果上下文切换占了CPU时间的30%以上。控制周期内的有效计算时间严重不足，导致PID调节跟不上。后来我合并了几个任务，切换开销降到了5%以下，系统才稳定下来。所以——不是任务越多越好，切换开销必须算进去。
1.4 如何测量上下文切换开销
光知道理论值不够，你得会自己测。我常用的方法有两种：
- GPIO翻转法：在任务切换的入口和出口各翻转一次GPIO，用示波器测量脉冲宽度。简单粗暴，但很有效。
- 系统计数器法：在切换前后读取系统滴答计数器，计算差值。精度取决于计数器频率。
下面是一个简单的测量代码示例（基于FreeRTOS）：
// 在任务切换钩子函数中测量
void vApplicationTickHook(void)
{
static uint32_t last_tick = 0;
uint32_t current_tick = xTaskGetTickCount();
if (current_tick != last_tick) {
// 发生了任务切换
uint32_t overhead = current_tick - last_tick;
// 记录到全局变量，供调试查看
g_max_switch_overhead = MAX(g_max_switch_overhead, overhead);
last_tick = current_tick;
}
}注意，这个代码只是示意。实际测量时，钩子函数本身也会引入开销，需要做校准。我个人习惯用GPIO翻转法，因为直观——示波器上一看，脉冲宽度清清楚楚。
1.5 降低上下文切换开销的技巧
既然切换有成本，那怎么优化？我总结了几个实战技巧：
- 合并短任务：如果两个任务执行时间都很短，且优先级相同，不如合并成一个。减少切换次数。
- 使用信号量代替任务切换：有时候可以用信号量+中断的方式，避免显式的任务切换。
- 调整时间片大小：时间片太短会导致频繁切换，太长又影响响应。需要根据实际负载调优。
- 关中断要谨慎：关中断期间不会发生任务切换，但会影响实时性。我建议关中断时间控制在10µs以内。
小技巧：在麻醉机的呼吸控制任务中，我通常把时间片设为5ms。这样既能保证控制周期的精度，又不会因为切换太频繁而浪费CPU。你可以根据你的系统时钟和任务数量，算一个合理的值。
1.6 本章小结
好，咱们捋一捋今天的内容：
- 任务有四种状态：就绪、运行、阻塞、挂起。状态转换要搞清楚，尤其是阻塞和挂起的区别。
- 上下文切换是有开销的，一般在微秒级别。别小看这几微秒，累积起来可能吃掉你30%的CPU。
- 测量切换开销用GPIO翻转法最直观，建议你在项目初期就测一下。
- 优化方向：合并任务、用信号量、调时间片、控制关中断时长。
下一章，咱们聊优先级反转与死锁——这两个问题在麻醉机里一旦出现，后果很严重。我当年就差点被一个优先级反转坑惨了，到时候给你们讲讲那个故事。
今天就到这儿。有问题随时交流。
公众号:蓝海资料掘金营，微信deep3321