3、实时操作系统（RTOS）基础：FreeRTOS任务调度、任务优先级设计、信号量与互斥锁在安全场景中的应用
各位好，我是老张。在麻醉机这种性命攸关的设备里，裸机跑轮询？说实话，我是不敢的。你想想看，一个传感器数据采集的延时，可能就会让呼吸参数判断出错。所以，我们得请出RTOS这位“大管家”。今天咱们就聊聊FreeRTOS在麻醉机安全监控里的那些事儿。
3.1 任务调度：谁先跑，谁后跑？
FreeRTOS的任务调度，说白了就是决定“哪个任务现在该干活了”。它用的是抢占式调度，优先级高的任务能随时打断优先级低的。我在项目中遇到过一个问题：一个低优先级的日志打印任务，因为占用了CPU太久，导致高优先级的风机控制任务响应慢了半拍。嗯，这很危险。
FreeRTOS的任务状态有四种：运行态、就绪态、阻塞态、挂起态。任务调度器会从就绪态的任务里，挑优先级最高的那个来跑。如果优先级相同，就轮着来（时间片轮转）。
核心原则：在麻醉机里，安全相关的任务（比如气道压力监测、氧浓度检测）必须设置最高优先级。非安全任务（比如人机界面刷新、日志记录）优先级要低一些。
举个例子，一个典型的任务创建代码：
// 创建气道压力监测任务，优先级最高
xTaskCreate(
vPressureMonitorTask, // 任务函数
"PressureMonitor", // 任务名
configMINIMAL_STACK_SIZE * 2, // 栈大小
NULL, // 参数
5, // 优先级：5（最高）
NULL // 任务句柄
);
// 创建人机界面刷新任务，优先级较低
xTaskCreate(
vDisplayUpdateTask,
"DisplayUpdate",
configMINIMAL_STACK_SIZE,
NULL,
1, // 优先级：1（最低）
NULL
);你看，压力监测任务的优先级是5，显示任务只有1。这样，一旦压力数据有变化，CPU会立刻响应，不会因为显示任务在刷屏而耽误事。
3.2 任务优先级设计：别让“饿死”发生
优先级设计是个技术活。我曾经见过一个新手，把所有的任务优先级都设成一样，结果系统响应一塌糊涂。也见过有人把优先级设得太多，导致调度开销过大。
在麻醉机里，我一般把优先级分成三层：
| 优先级层级 | 典型任务 | 说明 |
|---|---|---|
| 高（4-5） | 气道压力监测、氧浓度检测、紧急报警 | 实时性要求极高，毫秒级响应 |
| 中（2-3） | 呼吸参数计算、数据记录、通信处理 | 允许几十毫秒的延迟 |
| 低（1） | 人机界面刷新、自检、日志 | 可以容忍秒级延迟 |
这里有个坑：优先级反转。什么意思？就是低优先级任务拿着一个资源，高优先级任务等着用，结果中优先级任务插进来把低优先级任务抢占了，高优先级任务反而被“饿死”了。
避坑指南：我曾经在一个项目中，因为没处理好优先级反转，导致麻醉机的报警任务被阻塞了整整200毫秒。200毫秒啊，在呼吸支持里足以造成患者缺氧。后来我用了互斥锁（Mutex）的优先级继承机制，才彻底解决这个问题。
3.3 信号量：任务间的“交通信号灯”
信号量，你可以把它想象成一个交通信号灯。任务A要过路口（访问共享资源），得先看看信号灯是不是绿的（获取信号量）。如果是红的，就等着。任务B用完了，把灯变绿（释放信号量）。
在麻醉机里，信号量最常见的用途是同步。比如，传感器采集任务采集完数据后，通过信号量通知数据处理任务开始工作。
// 创建二值信号量
SemaphoreHandle_t xDataSemaphore = xSemaphoreCreateBinary();
// 传感器采集任务
void vSensorTask(void *pvParameters) {
while(1) {
// 采集气道压力数据
uint32_t pressure = readPressureSensor();
// 将数据存入共享缓冲区
writeToBuffer(pressure);
// 释放信号量，通知数据处理任务
xSemaphoreGive(xDataSemaphore);
// 等待下一次采集
vTaskDelay(pdMS_TO_TICKS(10));
}
}
// 数据处理任务
void vProcessTask(void *pvParameters) {
while(1) {
// 等待信号量
if(xSemaphoreTake(xDataSemaphore, portMAX_DELAY) == pdTRUE) {
// 从共享缓冲区读取数据并处理
uint32_t data = readFromBuffer();
calculateBreathParameters(data);
}
}
}你看，这样数据处理任务就不会空转，只有数据来了才干活。省电，也省CPU。
3.4 互斥锁：保护共享资源的“铁布衫”
互斥锁和信号量有点像，但有个关键区别：互斥锁有优先级继承机制。这个机制能解决我刚才说的优先级反转问题。
举个例子，假设有三个任务：
- 任务A（高优先级）：要访问共享缓冲区
- 任务B（中优先级）：纯计算，不访问共享缓冲区
- 任务C（低优先级）：正在访问共享缓冲区
如果用二值信号量，任务A会等任务C释放信号量。但任务B突然插进来，把任务C抢占了。任务A只能干等着，直到任务B跑完，任务C才能继续。这就是优先级反转。
如果用互斥锁，情况就不同了。当任务A发现任务C拿着锁时，系统会临时把任务C的优先级提升到和任务A一样高。这样任务C就能尽快跑完，释放锁，任务A就能立刻拿到锁。
我的习惯：在麻醉机里，只要涉及共享资源的访问（比如全局变量、硬件寄存器、通信缓冲区），我统一用互斥锁，不用二值信号量。虽然互斥锁的开销稍微大一点，但安全第一，这点代价值得。
互斥锁的使用示例：
// 创建互斥锁
SemaphoreHandle_t xMutex = xSemaphoreCreateMutex();
// 访问共享资源
void vWriteToSharedBuffer(uint32_t data) {
// 获取互斥锁
if(xSemaphoreTake(xMutex, pdMS_TO_TICKS(100)) == pdTRUE) {
// 临界区：写入共享缓冲区
sharedBuffer[writeIndex++] = data;
// 释放互斥锁
xSemaphoreGive(xMutex);
} else {
// 超时处理：记录错误，触发报警
logError("Mutex timeout in vWriteToSharedBuffer");
triggerAlarm(ALARM_SYSTEM_ERROR);
}
}注意那个超时处理。我见过有人用 portMAX_DELAY 一直等，结果死锁了系统就卡死了。在安全系统里，任何等待都要有超时，超时后必须能恢复。
3.5 安全场景中的特殊考量
在麻醉机里，RTOS的使用有几个特殊要求：
- 看门狗与任务监控：每个关键任务都要有“心跳”。如果某个任务超过预定时间没释放信号量或没更新标志位，看门狗就要介入，要么重启任务，要么触发安全状态。
- 栈空间预留：我习惯给每个任务多分配20%的栈空间。为什么？因为中断嵌套、函数调用深度变化都可能让栈溢出。我曾经因为栈溢出导致系统崩溃，查了三天才找到原因。
- 中断与任务的交互：在中断服务函数里，尽量只做“标记”工作，不要调用可能导致阻塞的API。比如，用
xSemaphoreGiveFromISR()而不是xSemaphoreGive()。
总结一下：FreeRTOS在麻醉机里的应用，核心就是“安全优先”。任务优先级要分层设计，共享资源用互斥锁保护，信号量用于任务同步。记住，任何阻塞操作都要有超时机制，任何任务都要有监控手段。这样，你的系统才能经得起考验。
好了，这一章就聊到这儿。下一章咱们讲讲中断管理，看看怎么在中断里安全地跟任务打交道。