4. FreeRTOS 任务管理进阶：任务通知、看门狗与优先级反转

各位同学，咱们今天聊点硬核的。任务管理做到一定深度，你会发现光会用信号量和队列远远不够。任务通知、任务看门狗、栈空间优化，还有那个让人头疼的优先级反转——这些才是真正决定系统稳定性的关键。

我个人习惯把任务通知看作RTOS里的“轻量级信号量”。为什么这么说？因为它快，而且省内存。但用不好，坑也不少。

4.1 任务通知：比信号量更轻量的选择

任务通知，说白了就是每个任务自带一个32位的通知值。你可以用它来发信号、传数据，甚至当二值信号量用。我刚开始用FreeRTOS时，总觉得信号量是万能的，直到有一次在STM32L4上跑一个低功耗项目，发现信号量占用的RAM比我想象的多得多。

任务通知的优势很明显：

• 速度快：不需要创建队列或信号量，直接操作任务控制块（TCB）里的字段
• 省内存：每个任务自带一个通知值，零额外开销
• 灵活：可以发事件标志、传数值、甚至覆盖旧值

但注意，任务通知只能点对点通信。一个任务只能被一个任务通知。如果你需要多对一，还是得用队列。

来看一个实际例子。假设你有一个ADC采集任务，采集完通知主控任务处理数据：

// 发送任务（ADC中断或任务中）
void ADC_ConversionDone(void)
{
    uint32_t adc_value = LL_ADC_Read();  // 读取ADC值
    xTaskNotify(handleMainTask,          // 目标任务句柄
                adc_value,               // 通知值
                eSetValueWithOverwrite); // 覆盖旧值
}

// 接收任务
void MainTask(void *pvParameters)
{
    uint32_t receivedValue;
    while(1)
    {
        // 等待通知，超时设为portMAX_DELAY
        if(xTaskNotifyWait(0x00,          // 进入时不清除位
                           0xFFFFFFFF,    // 退出时清除所有位
                           &receivedValue, // 保存通知值
                           portMAX_DELAY) == pdTRUE)
        {
            // 处理ADC数据
            ProcessADCData(receivedValue);
        }
    }
}

嗯，这里要注意：xTaskNotifyWait的第三个参数是输出，别传NULL。我曾经犯过这个错，调试了半天才发现通知值根本没读出来。

4.2 任务看门狗：别让任务“假死”

硬件看门狗能防止系统死机，但任务级别的“假死”它管不了。比如一个任务因为等待信号量超时，或者陷入了死循环，硬件看门狗可能还在喂，但任务已经不干活了。

任务看门狗的思路很简单：每个任务定期“打卡”，如果某个任务超时未打卡，系统就执行恢复操作。

实现起来也不复杂：

// 任务心跳结构体
typedef struct {
    TaskHandle_t taskHandle;
    uint32_t     lastHeartbeat;
    uint32_t     timeoutMs;
    void       (*onTimeout)(void);
} TaskWatchdog_t;

TaskWatchdog_t g_watchdogs[MAX_WATCHDOG_TASKS];

// 每个任务在循环中调用
void Task_Heartbeat(int index)
{
    g_watchdogs[index].lastHeartbeat = xTaskGetTickCount();
}

// 看门狗检查任务（高优先级）
void WatchdogTask(void *pvParameters)
{
    while(1)
    {
        vTaskDelay(pdMS_TO_TICKS(100)); // 每100ms检查一次
        
        TickType_t now = xTaskGetTickCount();
        for(int i = 0; i < MAX_WATCHDOG_TASKS; i++)
        {
            if((now - g_watchdogs[i].lastHeartbeat) > 
               pdMS_TO_TICKS(g_watchdogs[i].timeoutMs))
            {
                // 超时！执行恢复
                if(g_watchdogs[i].onTimeout)
                    g_watchdogs[i].onTimeout();
                
                // 或者直接重启任务
                vTaskDelete(g_watchdogs[i].taskHandle);
                xTaskCreate(/* 重新创建任务 */);
            }
        }
    }
}

我曾经在一个电机控制项目里，因为一个任务被高优先级任务长时间抢占，导致看门狗误报。后来加了个“任务运行时间统计”，才把问题定位清楚。所以，任务看门狗的阈值一定要留够余量，别太紧。

4.3 任务栈空间优化与溢出检测

栈溢出是RTOS里最隐蔽的bug之一。它不会立刻崩溃，而是慢慢侵蚀相邻的内存，导致各种诡异现象。我见过一个案例：系统运行三天后突然死机，查了两个月，最后发现是栈溢出。

FreeRTOS提供了两种栈溢出检测方法：

• 方法1：在任务切换时检查栈指针是否越界（速度快，但可能漏检）
• 方法2：在任务切换时检查栈顶标记是否被覆盖（更可靠，但稍慢）

配置方法很简单，在FreeRTOSConfig.h中设置：

#define configCHECK_FOR_STACK_OVERFLOW    2  // 使用方法2

然后实现钩子函数：

void vApplicationStackOverflowHook(TaskHandle_t xTask, 
                                    char *pcTaskName)
{
    // 记录错误信息
    Error_Handler();
    // 或者重启任务
}

至于栈空间优化，我的经验是：

• 先给大，再调小：开发阶段给每个任务512字节以上，稳定后用uxTaskGetStackHighWaterMark()查看实际使用量
• 注意局部变量：大的局部数组、结构体尽量用动态分配或静态全局
• 递归函数慎用：递归深度不可控，栈空间很难预估

// 查看任务栈剩余空间
UBaseType_t uxHighWaterMark;
uxHighWaterMark = uxTaskGetStackHighWaterMark(taskHandle);
printf("Task %s 剩余栈空间: %d 字\n", 
       pcTaskGetName(taskHandle), 
       uxHighWaterMark);

你想想看，如果剩余空间只有几个字，那这个任务随时可能溢出。我一般要求剩余空间不低于总栈大小的20%。

4.4 优先级反转问题与解决方案

优先级反转，这是RTOS里最经典的坑。简单说就是：低优先级任务占着资源不放，高优先级任务只能干等。

为什么会这样？假设有三个任务：

• 任务A（高优先级）需要访问共享资源
• 任务B（中优先级）不需要资源，但一直运行
• 任务C（低优先级）占着资源，但被B抢占

结果就是：A等C释放资源，C被B抢占，A被B间接阻塞。优先级反转了。

使用Mutex代替二值信号量：

// 创建互斥量（带优先级继承）
SemaphoreHandle_t xMutex = xSemaphoreCreateMutex();

// 任务中使用
void Task_UseResource(void *pvParameters)
{
    while(1)
    {
        if(xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE)
        {
            // 访问共享资源
            AccessSharedResource();
            xSemaphoreGive(xMutex);
        }
    }
}

但注意，Mutex不能在中断中使用。中断里只能用二值信号量。另外，优先级继承会增加调度开销，但相比系统崩溃，这点代价值得。

我曾经在一个多传感器数据融合项目里，因为没注意优先级反转，导致高优先级的控制任务延迟了200ms，电机直接抖了起来。后来换成Mutex，问题立刻解决。

4.5 本章知识结构图

下面这张图总结了本章的核心知识点和它们之间的关系：