任务创建与生命周期管理：状态机、栈深度估算与优先级设计
各位做嵌入式开发的同行，今天我们来聊聊 ThreadX 里最基础也最容易翻车的一块——任务管理。说白了，就是三个问题：任务怎么生、怎么活、怎么排优先级。我见过不少项目，代码写得挺漂亮，结果一上 RTOS 就各种跑飞、死锁、栈溢出。嗯，问题多半出在这三个环节上。
任务状态机：从生到死的五个阶段
ThreadX 的任务状态机其实不复杂，一共就五个状态。我习惯把它画成一张图贴在工位上，调试时扫一眼就知道任务卡在哪了。
核心要点：任务状态切换是 RTOS 调优的第一道门槛。状态不对，一切白费。
这张图里有个细节我特别想强调——阻塞态和挂起态的区别。很多新手搞混这两个状态。阻塞态是任务自己调用 tx_thread_sleep 或者等信号量、消息队列时主动进去的。挂起态则是被别的任务或中断用 tx_thread_suspend 强行按住的。我在项目中遇到过有人用挂起当阻塞用，结果任务永远醒不过来，排查了两天才发现是挂起后没人调用 resume。
实战建议：任务创建后立即调用 tx_thread_resume 才能进入就绪队列。ThreadX 默认创建后是暂停状态，这个坑我踩过不止一次。
任务栈深度估算：别让栈溢出成为你的噩梦
栈溢出是 MCU 上最隐蔽的 bug 之一。它不会立刻崩溃，而是随机死机、数据错乱、函数返回地址被篡改。我见过一个产品，出厂前测试全过，客户现场跑三天就挂，最后发现是某个任务的栈只给了 128 字节，实际用了 200 多。
怎么估算？我总结了一套三步法：
- 静态分析：数清楚任务函数里所有局部变量、函数调用嵌套深度、中断嵌套深度。
- 动态测量：在任务入口和出口打印栈指针差值，或者用 ThreadX 自带的
tx_thread_stack_error_notify钩子。 - 留余量：实测值乘以 1.5 到 2 倍，别抠门。
| 栈空间占用项 | 典型大小（字节） | 说明 |
|---|---|---|
| 任务上下文保存 | 64-128 | CPU 寄存器、FPU 寄存器等 |
| 局部变量 | 视代码而定 | 数组、结构体是大头 |
| 函数调用链 | 每层 8-32 | 返回地址 + 参数压栈 |
| 中断嵌套 | 64-256 | ISR 上下文 + 嵌套深度 |
| ThreadX 内部开销 | 32-64 | 定时器、阻塞链表等 |
警告：千万不要在 ISR 里分配大数组！我曾经在一个项目中，ISR 里声明了一个 512 字节的局部数组，结果中断嵌套两次直接栈溢出，系统复位。后来改成全局静态缓冲区才解决。
这里给一个我常用的栈深度测量代码片段：
// 在任务入口记录栈底指针
UCHAR *stack_start;
UCHAR *stack_end;
UINT stack_size;
tx_thread_stack_info(tx_thread_identify(),
&stack_start, &stack_end, &stack_size);
// 在任务关键路径上检查剩余栈
UCHAR *current_sp;
// 获取当前栈指针（汇编或内联）
__asm volatile("mov %0, sp" : "=r"(current_sp));
UINT used = (UINT)(stack_end - current_sp);
if (used > (stack_size * 0.8)) {
// 触发告警或记录日志
error_handler("Stack usage exceeds 80%!");
}任务优先级设计原则：别让优先级反转毁了你
优先级设计是 RTOS 调优的灵魂。我见过最典型的错误就是给所有任务都设成同一个优先级，或者把 UI 任务设得比通信任务还高。你想想看，用户按个按钮，结果把关键数据接收给耽误了，这合理吗？
我总结了几条硬性原则：
- 实时性决定优先级：硬实时任务（如电机控制、通信协议栈）放最高，软实时任务（如 UI 刷新、日志输出）放最低。
- 避免优先级反转：共享资源时使用优先级继承协议，ThreadX 的互斥量默认支持这个特性。
- 优先级数量够用就行：ThreadX 支持 32 级优先级，但实际项目中 8-16 级就足够了。太多优先级反而增加调度开销。
- ISR 优先级高于所有任务：中断服务程序的优先级由硬件决定，但 ISR 里尽量少做事，把耗时操作推给高优先级任务。
核心原则：优先级不是越高越好，而是越「紧」越好。一个任务离 deadline 越近，优先级就应该越高。
举个例子，我在一个工业控制项目中这样分配优先级：
| 优先级 | 任务名称 | 实时要求 | 说明 |
|---|---|---|---|
| 0（最高） | 电机控制 | 100μs | 硬实时，直接驱动 PWM |
| 1 | CAN 通信 | 1ms | 接收控制指令 |
| 2 | 传感器采集 | 5ms | ADC 数据读取 |
| 3 | 数据处理 | 10ms | 滤波、算法运算 |
| 4 | UI 刷新 | 50ms | LCD 显示更新 |
| 5（最低） | 日志输出 | 100ms | 串口打印调试信息 |
这个分配方案我用了好几年，基本没出过优先级相关的问题。但要注意一点——同优先级任务之间用时间片轮转，ThreadX 默认时间片是 4 个 tick。如果你的 tick 是 1ms，那每个任务最多跑 4ms 就会被切换。这个值可以根据实际调整，但别设太小，否则上下文切换开销会吃掉 CPU。
避坑指南：我曾经把一个高优先级任务里放了 tx_thread_sleep(100)，结果它占着优先级不放，低优先级任务全饿死了。后来改成用信号量等待，高优先级任务阻塞后低优先级任务才能跑起来。
最后说一句，任务优先级设计没有银弹。每个项目都要根据实际负载、中断频率、外设响应时间来调整。我的习惯是先在纸上画一个优先级-响应时间矩阵，把每个任务的 deadline 标出来，再反推优先级。这样至少不会出现「感觉上应该高」这种拍脑袋的决策。