1、RTOS调试基础：理解任务状态与调度机制，掌握任务栈溢出检测方法

做嵌入式开发这些年，我调试过不少RTOS相关的bug。说实话，很多问题追根溯源，都出在对任务状态和栈空间的理解不够深。这一章，咱们就把这两个基础打牢。

1.1 任务状态机：你的任务到底在干嘛？

RTOS里的任务，不是一直占着CPU跑的。它会在几个状态之间跳来跳去。我刚开始用FreeRTOS时，就吃过这个亏——以为任务创建了就会一直运行，结果发现它卡在某个状态不动了。

典型的任务状态有四种：

• 运行态（Running）：正在使用CPU。单核芯片上，同一时刻只有一个任务处于此状态。
• 就绪态（Ready）：能跑，但CPU被别的任务占着。排队等调度。
• 阻塞态（Blocked）：在等某个事件。比如等信号量、等队列消息、等延时结束。
• 挂起态（Suspended）：被vTaskSuspend()主动挂起。只有调用vTaskResume()才能恢复。

你想想看，如果一个任务既不阻塞也不挂起，优先级又够高，那它就会一直占着CPU。低优先级任务永远没机会跑。这就是所谓的“饿死”现象。

1.2 调度机制：谁来决定下一个跑谁？

RTOS的调度器，说白了就是个“交通警察”。它决定下一个时刻哪个任务上CPU跑。我习惯把调度策略分成两类：

调度策略	特点	典型场景
抢占式调度	高优先级任务就绪后，立即打断低优先级任务	大多数实时系统，如FreeRTOS默认配置
时间片轮转	同优先级任务轮流跑，每人分一个时间片	多个同等重要的任务，如UI刷新+数据采集

这里有个坑：抢占式调度下，如果高优先级任务一直不阻塞，低优先级任务就永远没机会。我曾经在一个项目中，把CAN通信任务优先级设得太高，结果LED闪烁任务直接罢工了。嗯，后来把LED任务优先级提上来，或者让CAN任务适当阻塞一下，问题就解决了。

1.3 任务栈溢出检测：别让栈悄悄爆掉

栈溢出是RTOS里最隐蔽的bug之一。它不会立刻报错，而是慢慢侵蚀相邻的内存区域。我遇到过最诡异的一次：一个任务跑着跑着，另一个任务的全局变量莫名其妙被改了。查了两天，最后发现是栈溢出了。

为什么会这样？每个任务都有自己的栈空间。如果局部变量太多、函数调用嵌套太深，或者用了递归，栈指针就会越界，写到别人的地盘上。

FreeRTOS提供了两种检测方法：

1. 方法一：栈溢出钩子函数

   void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) {
       // 一旦触发，立刻停在这里
       // 打印出是哪个任务出了问题
       printf("Stack overflow in task: %s\n", pcTaskName);
       while(1);
   }

2. 方法二：编译时检查栈使用量

   // 在FreeRTOSConfig.h中开启
   #define configCHECK_FOR_STACK_OVERFLOW 2
   
   // 运行时调用
   UBaseType_t uxHighWaterMark = uxTaskGetStackHighWaterMark(taskHandle);
   printf("Remaining stack: %d words\n", uxHighWaterMark);

1.4 实战：如何估算任务栈大小？

很多新手喜欢拍脑袋定栈大小。比如给个512字节，觉得够用了。结果跑着跑着就崩了。我个人习惯用三步法：

• 第一步：先给一个较大的值，比如1024字节。确保能跑起来。
• 第二步：跑一段时间后，调用uxTaskGetStackHighWaterMark()，看实际用了多少。
• 第三步：根据峰值使用量，加上20%~30%的安全余量，重新设定栈大小。

举个例子：

// 假设任务句柄为 xTaskCreate 时返回的 handle
UBaseType_t highWater = uxTaskGetStackHighWaterMark(xMyTaskHandle);
printf("MyTask 栈剩余: %d 字\n", highWater);
// 如果 highWater 是 200，说明峰值用了 1024 - 200 = 824 字
// 建议栈大小设为 824 * 1.3 ≈ 1072，取整为 1152

1.5 知识体系总览

下面这张图，把这一章的核心逻辑串起来了。你可以把它当成调试时的检查清单。

这张图把三个核心模块串在了一起。你调试的时候，按这个顺序走一遍，基本能定位90%的问题。