📚 课程目录第3章任务创建与管理

任务创建与管理：任务句柄、任务函数、任务堆栈的深度理解

任务，是 RTOS 世界里最核心的概念。说白了，任务就是一段独立运行的程序，有自己的生命周期。但很多初学者把任务想得太简单——不就是创建一个函数吗？嗯，没那么简单。

我刚开始用 FreeRTOS 时，也踩过不少坑。有一次产品在现场跑着跑着就死机了，查了三天，最后发现是任务堆栈设小了。从那以后，我对任务创建的每个细节都不敢马虎。

这一章，咱们就把任务句柄、任务函数、任务堆栈这三个东西彻底讲透。

1. 任务句柄——任务的身份证

任务句柄是什么？你可以把它理解成任务的身份证号。系统里每个任务都有一个唯一的句柄，通过这个句柄，你才能操作这个任务——挂起它、恢复它、删除它、改变它的优先级。

在 FreeRTOS 中，任务句柄的类型是 TaskHandle_t。本质上它是一个指针，指向任务控制块（TCB）。

TaskHandle_t myTaskHandle = NULL;

创建任务时，把句柄变量的地址传进去，系统就会把任务的身份证号填进去。

xTaskCreate(
    vTaskFunction,      // 任务函数
    "My Task",          // 任务名称（调试用）
    128,                // 堆栈深度（单位：字）
    NULL,               // 任务参数
    1,                  // 优先级
    &myTaskHandle       // 任务句柄
);

创建成功后，myTaskHandle 就指向了这个任务。以后想操作它，直接拿句柄说话。

关键点：句柄是操作任务的唯一凭证。没有句柄，你就没法控制这个任务。我见过有人创建任务时不保存句柄，结果想删除任务时傻眼了——只能重启系统。

2. 任务函数——任务要干什么

任务函数就是任务要执行的代码。它有一个固定的格式：

void vTaskFunction(void *pvParameters)
{
    // 初始化代码
    for(;;)
    {
        // 任务主体代码
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

注意几个要点：

返回值必须是 void——任务函数永远不能返回
参数是 void * 指针——可以传任何类型的数据
必须有一个无限循环——任务执行完一次后要等待下一次调度

为什么任务函数不能返回？因为返回后，系统就不知道这个任务该干什么了。任务要么在运行，要么在阻塞，要么在就绪，但绝对不能"结束"。

我的习惯：任务函数里，我会把初始化代码放在循环外面，把周期性执行的代码放在循环里面。这样初始化只跑一次，不会浪费 CPU 时间。

3. 任务堆栈——任务的私人空间

每个任务都有自己的堆栈。这个堆栈用来保存：

局部变量
函数调用时的返回地址
中断发生时的寄存器内容
任务切换时的上下文

堆栈大小直接决定了任务能跑多复杂的代码。堆栈设小了，任务跑着跑着就栈溢出；设大了，浪费宝贵的 RAM。

FreeRTOS 中，堆栈大小以"字"为单位。在 STM32 上，一个字是 4 字节。所以：

xTaskCreate(vTask, "Task", 128, NULL, 1, NULL);

这个任务分配了 128 个字 = 512 字节的堆栈。

我曾经踩过的坑：有一次我写了一个任务，里面调用了 sprintf() 格式化一个长字符串。sprintf 本身就需要不小的堆栈空间，再加上局部变量，128 字的堆栈根本不够。结果程序运行几分钟后就崩溃了。后来我用 uxTaskGetStackHighWaterMark() 一查，发现堆栈只剩 4 个字了。

4. 堆栈大小的估算方法

怎么估算堆栈大小？我一般用这几个方法：

方法	说明	适用场景
经验法	简单任务 128 字，中等任务 256 字，复杂任务 512 字	快速原型
静态分析	统计所有嵌套函数调用的局部变量总和	确定性高的系统
运行时监测	用 `uxTaskGetStackHighWaterMark()` 获取剩余堆栈	调试阶段

我个人最推荐第三种方法。在产品开发阶段，把所有任务的堆栈余量都打印出来，看看实际用了多少，再调整堆栈大小。

UBaseType_t uxHighWaterMark;
uxHighWaterMark = uxTaskGetStackHighWaterMark(myTaskHandle);
printf("Task stack remaining: %d words\n", uxHighWaterMark);

这个函数返回的是任务运行以来，堆栈剩余的最小值。如果这个值接近 0，说明堆栈快爆了，赶紧加大。

5. 任务创建的全流程

下面这张图展示了任务从创建到运行的全过程：

你看，任务创建其实分三步走：分配 TCB、分配堆栈、初始化上下文。这三步做完，任务就准备好了，但还没开始跑。只有调度器启动后，任务才会被真正调度执行。

6. 任务创建的两种方式

FreeRTOS 提供了两种创建任务的方式：

方式	函数	堆栈来源	适用场景
动态创建	`xTaskCreate()`	系统自动从堆中分配	大多数情况
静态创建	`xTaskCreateStatic()`	用户预先分配	安全关键系统、无堆环境

动态创建省事，但需要堆管理器支持。静态创建更可控，但需要你自己管理内存。

我的建议：产品开发阶段用动态创建，方便调试。量产阶段如果对实时性要求极高，可以考虑静态创建，避免堆分配带来的不确定性。

7. 任务删除与资源回收

任务不是创建了就永远存在。有时候需要删除任务，释放资源。

// 删除自己
vTaskDelete(NULL);

// 删除其他任务
vTaskDelete(myTaskHandle);

删除任务时，系统会回收 TCB 和堆栈空间。但要注意：

任务删除后，句柄就失效了，不能再使用
如果任务持有互斥量、信号量等资源，删除前要释放
删除自己时，系统会在任务退出后自动回收资源

我曾经犯过的错：有一个任务动态申请了内存，但没有在删除前释放。结果每次创建-删除这个任务，系统就漏掉一块内存。跑了几天后，堆空间耗尽，系统崩溃。从那以后，我养成了习惯：任务退出前，把所有动态资源都清理干净。

8. 实战建议

说了这么多，最后给几个实战中的建议：

堆栈宁大勿小——RAM 够用的情况下，多给 20% 的余量
用高水位标记调试——每个任务都打印堆栈余量，直到稳定
任务函数里别用递归——递归会吃掉大量堆栈，很难预估
句柄要全局保存——不然想操作任务时找不到它
任务名要有意义——调试时一眼能看出是哪个任务

任务创建看起来简单，但细节决定成败。堆栈大小、句柄管理、资源回收，每一个点都可能成为系统的隐患。把这些基础打牢了，后面的任务同步、通信、优先级反转这些问题，才能游刃有余。