4、任务管理机制：任务状态机、优先级配置、任务创建与删除、任务栈深度估算
任务管理，说白了就是操作系统怎么管好你那些并发跑着的代码。我见过不少工程师，上来就写任务，结果跑起来各种诡异——有的任务不跑了，有的栈溢出了，有的优先级搞反了。嗯，这节课咱们就把这些坑一个个填上。
4.1 任务状态机：任务到底在干嘛？
每个实时任务，在它的生命周期里会经历几个状态。我习惯把这几个状态画成一张图贴在工位上，调试时扫一眼就知道问题出在哪。
| 状态 | 说明 | 典型场景 |
|---|---|---|
| 就绪（Ready） | 任务已就绪，等待CPU | 刚创建完，或者从阻塞中恢复 |
| 运行（Running） | 正在占用CPU执行 | 当前被调度器选中的任务 |
| 阻塞（Blocked） | 等待某个事件或资源 | 等待信号量、消息队列、延时 |
| 挂起（Suspended） | 被主动暂停，不参与调度 | 调试时手动挂起，或低功耗模式 |
状态切换的规则其实不复杂。任务从创建出来就进入就绪态，调度器一选它就变运行态。运行中如果等资源，就进阻塞态；资源到了，又回到就绪态。挂起态比较特殊，得手动调用API才能进去或出来。
核心要点：阻塞态和挂起态的区别——阻塞是任务自己主动等的，挂起是外部强制暂停的。调试时别搞混了。
我在项目中遇到过一个问题：一个任务明明在等消息队列，但就是不进阻塞态。查了半天，原来是消息队列创建时用了非阻塞模式。你想想看，队列都不阻塞，任务当然一直轮询，CPU全浪费了。
4.2 优先级配置：谁先跑谁后跑？
优先级是实时系统的命根子。配置错了，轻则任务饿死，重则系统崩溃。
大多数RTOS支持两种调度策略：
- 抢占式调度：高优先级任务就绪，立刻抢走CPU。这是实时系统的标配。
- 时间片轮转：同优先级任务轮流跑，每个跑一个时间片。适合非实时任务。
我个人习惯把优先级分成三档：
- 高优先级（0-5）：留给中断处理、紧急控制、安全相关任务。比如刹车控制、气囊触发。
- 中优先级（6-10）：留给周期性任务。比如传感器采集、CAN报文收发。
- 低优先级（11-15）：留给后台任务。比如日志记录、诊断服务、自检。
警告：优先级不要超过15级。级数太多，调度器开销会变大，而且你根本管不过来。我曾经见过一个项目用了32级优先级，最后调试时自己都搞不清谁比谁高。
还有一个常见问题：优先级反转。低优先级任务占着资源，高优先级任务等它释放，结果中优先级任务插进来把低优先级任务抢走了。高优先级任务反而被中优先级任务间接阻塞了。解决办法是优先级继承协议——RTOS会自动把低优先级任务的优先级临时提升到高优先级任务的级别。
4.3 任务创建与删除：生与死的管理
任务创建，每个RTOS都有自己的API。以FreeRTOS为例：
TaskHandle_t xTaskHandle = NULL;
void vTaskFunction(void *pvParameters) {
while(1) {
// 任务主体
vTaskDelay(pdMS_TO_TICKS(100));
}
}
// 创建任务
xTaskCreate(
vTaskFunction, // 任务函数
"MyTask", // 任务名（调试用）
256, // 栈深度（单位：字）
NULL, // 参数
5, // 优先级
&xTaskHandle // 任务句柄
);创建时要注意几点：
- 任务名不要超过配置的最大长度，否则会被截断。调试时看到乱码名，你根本不知道哪个任务出了问题。
- 栈深度单位是字（word），不是字节。32位系统上一个字是4字节。很多人在这里算错。
- 优先级参数一定要在有效范围内。超出范围，有些RTOS会静默截断，有些直接返回错误。
任务删除相对简单：
vTaskDelete(xTaskHandle); // 删除指定任务
vTaskDelete(NULL); // 删除当前任务提示：删除任务前，确保它已经释放了所有占用的资源。否则内存泄漏等着你。我习惯在任务退出前加一个清理函数，把信号量、队列、动态内存都释放掉。
我曾经犯过一个低级错误：在中断服务函数里调用了任务删除API。结果系统直接挂掉。记住，大多数RTOS不允许在中断上下文里操作任务管理API。得发一个信号量给一个高优先级任务，让它去执行删除操作。
4.4 任务栈深度估算：给任务留多少空间？
栈深度估算，是新手最容易翻车的地方。给少了，栈溢出；给多了，内存浪费。嵌入式系统的RAM就那么点，每一字节都得精打细算。
栈里都放了什么？
- 函数调用时的返回地址
- 局部变量（特别是大数组和结构体）
- 中断嵌套时的上下文保存
- RTOS内部使用的控制块
我常用的估算方法分三步：
- 静态分析：看任务函数里最大的局部变量。比如一个512字节的数组，加上几个指针和结构体，大概算600字节。
- 调用链分析：任务函数里调用了哪些子函数？每个子函数又调用了什么？把最深调用链的栈需求加起来。注意递归调用——我建议嵌入式系统里别用递归，栈深度不可控。
- 实测验证：RTOS通常提供栈使用统计API。比如FreeRTOS的
uxTaskGetStackHighWaterMark()，能告诉你任务运行以来栈最多用了多少。跑一段时间，看峰值。
经验公式：静态分析结果 × 1.5 = 初始栈深度。然后实测，根据峰值再调整。我一般留20%的余量，防止极端情况。
举个例子：一个传感器采集任务，函数里有一个256字节的缓冲区，加上几个局部变量，静态分析大概300字节。乘以1.5，初始给450字节。实测后发现峰值到了380字节，我就把栈深度设为512字节。嗯，留了30%余量，心里踏实。
注意：中断嵌套会额外消耗栈空间。如果你的系统有三级中断嵌套，每级中断的上下文保存大概几十字节，加起来可能上百字节。这部分也要算进任务栈里。我习惯在任务栈基础上再加一个中断嵌套的最大开销。
最后说一个调试技巧：大多数RTOS支持栈溢出检测。开启后，如果任务写到了栈边界，系统会触发一个钩子函数。我在项目里都会把这个钩子函数指向一个GPIO翻转，这样栈溢出时示波器上就能看到脉冲，定位问题快很多。
好了，任务管理这块就讲这么多。下一节咱们聊任务间通信——信号量、消息队列、事件标志组，这些才是真正让任务协同工作的核心机制。