4、任务创建与删除：任务控制块TCB、任务函数、任务创建API（xTaskCreate、xTaskCreateStatic），任务删除与自删除，任务参数传递

FreeRTOS 作为一款轻量级实时操作系统，其核心调度单元是任务（Task）。任务在系统中并非凭空存在，而是由内核分配并管理的一组资源集合。理解任务的创建与删除机制，是掌握 FreeRTOS 内核原理的第一步，也是后续学习队列、信号量、事件组等 IPC 机制的基础。本章将深入剖析任务控制块（TCB）的内存布局与作用，详细对比动态创建与静态创建的差异，并通过实战案例演示任务参数传递的多种方式，最后总结任务删除与自删除的注意事项。

上图展示了任务从创建到删除的完整生命周期。左侧为创建路径，右侧为删除路径，中间为 TCB 的核心字段。可以看到，无论是动态还是静态创建，最终都会生成一个 TCB 和对应的栈空间；而删除操作则负责回收这些资源。参数传递机制贯穿于创建过程，通过 pvParameters 将用户数据传入任务函数。下面我们将逐一深入这些环节。

4.1 任务控制块 TCB：任务的内核身份证

核心原理：任务控制块（Task Control Block，TCB）是 FreeRTOS 内核用于管理任务的核心数据结构。每个任务在创建时都会分配一个 TCB，它记录了任务的全部上下文信息，包括栈指针、任务状态、优先级、事件等待列表项等。内核调度器正是通过遍历就绪列表中的 TCB 来决定哪个任务获得 CPU 使用权。TCB 本质上是一个结构体，其定义位于 task.h 中，关键字段如下表所示：

TCB 的内存来源取决于创建方式。使用 xTaskCreate() 时，TCB 和栈空间由内核从 FreeRTOS 堆中动态分配；使用 xTaskCreateStatic() 时，则完全由用户提供静态内存缓冲区。理解 TCB 的布局有助于诊断栈溢出、优先级反转等问题。

4.2 任务函数与创建 API 详解

任务函数原型：所有任务函数必须遵循固定格式，接受一个 void* 参数并返回 void。任务函数内部通常是一个无限循环，因为任务一旦返回，即被内核视为“任务结束”，若未调用删除函数，则会产生断言错误。

void vTaskFunction(void *pvParameters) {
    // 参数解析
    int32_t param = *(int32_t*)pvParameters;
    for(;;) {
        // 任务主体逻辑
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
    // 若跳出循环，必须调用 vTaskDelete(NULL) 自杀
}

动态创建 API：xTaskCreate() 是使用频率最高的创建接口，其原型如下：

BaseType_t xTaskCreate(
    TaskFunction_t pxTaskCode,      // 任务函数指针
    const char *pcName,             // 任务名（仅用于调试）
    configSTACK_DEPTH_TYPE usStackDepth, // 栈深度（单位：字，不是字节）
    void *pvParameters,             // 传给任务函数的参数
    UBaseType_t uxPriority,         // 优先级（0~configMAX_PRIORITIES-1）
    TaskHandle_t *pxCreatedTask     // 返回任务句柄（可为 NULL）
);

返回值 pdPASS 表示创建成功，errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY 表示堆内存不足。注意 usStackDepth 的单位是“字”（4 字节在 32 位 MCU 上），例如设置 128 表示分配 512 字节栈空间。

静态创建 API：当系统对实时性要求极高或需要避免动态内存碎片时，使用 xTaskCreateStatic()。用户必须预先定义 StackType_t 数组和 StaticTask_t 结构体：

StackType_t taskStack[128];
StaticTask_t taskTCB;
TaskHandle_t xTaskCreateStatic(
    TaskFunction_t pxTaskCode,
    const char *pcName,
    uint32_t ulStackDepth,          // 栈深度（字）
    void *pvParameters,
    UBaseType_t uxPriority,
    StackType_t *puxStackBuffer,    // 用户提供的栈缓冲区
    StaticTask_t *pxTaskBuffer      // 用户提供的 TCB 缓冲区
);

静态创建不会失败（只要缓冲区有效），但需要用户自行管理内存生命周期。在 RAM 受限的 MCU 上，静态创建是更安全的选择。

4.3 任务删除与自删除机制

删除 API：vTaskDelete(TaskHandle_t xTask) 用于删除任务。传入 NULL 表示删除当前运行的任务（自删除）。删除操作会：

1. 将任务从就绪列表、阻塞列表或挂起列表中移除。
2. 若任务是当前运行任务，则内核自动切换到下一个就绪任务。
3. 释放 TCB 和栈内存（仅限动态创建的任务）。

自删除的陷阱：当任务调用 vTaskDelete(NULL) 后，任务并未立即释放内存，而是进入“僵尸状态”。内存回收由空闲任务（Idle Task）完成。因此，若应用创建了任务又删除，必须确保空闲任务有机会获得 CPU 时间，否则内存泄漏。在低功耗场景中，若所有任务都阻塞，空闲任务会运行并回收资源。

4.4 任务参数传递实战：多实例 LED 控制

案例背景：某 IoT 网关设备需要控制 3 个 LED 灯，分别以 500ms、1000ms、2000ms 的周期闪烁。若为每个 LED 编写独立任务函数，代码冗余且难以维护。更优雅的方案是编写一个通用任务函数，通过参数传递 LED 引脚编号和闪烁周期。

初始方案与问题：最初开发者尝试将周期值直接作为 pvParameters 传入，但发现任务函数中读取到的值不正确。原因是 pvParameters 是一个指针，直接传入整数值（如 500）会被解释为地址，导致访问非法内存。

正确实现：定义结构体封装参数，并确保参数内存的生命周期覆盖任务运行期间。

typedef struct {
    uint8_t led_pin;
    uint16_t period_ms;
} led_config_t;

// 静态分配参数结构体（全局或 static）
static led_config_t led1_cfg = {GPIO_PIN_0, 500};
static led_config_t led2_cfg = {GPIO_PIN_1, 1000};
static led_config_t led3_cfg = {GPIO_PIN_2, 2000};

void vLEDTask(void *pvParameters) {
    led_config_t *cfg = (led_config_t*)pvParameters;
    for(;;) {
        GPIO_Toggle(cfg->led_pin);
        vTaskDelay(pdMS_TO_TICKS(cfg->period_ms));
    }
}

void app_main(void) {
    xTaskCreate(vLEDTask, "LED1", 128, &led1_cfg, 2, NULL);
    xTaskCreate(vLEDTask, "LED2", 128, &led2_cfg, 2, NULL);
    xTaskCreate(vLEDTask, "LED3", 128, &led3_cfg, 2, NULL);
}

结果与复盘：三个任务共享同一函数体，通过参数区分行为。代码量减少 60%，且新增 LED 只需增加配置结构体。关键经验：

• 参数指针必须指向生命周期足够长的内存（全局、静态或堆分配），不能指向栈上的局部变量。
• 若参数是只读的，可声明为 const 以增强安全性。
• 对于简单整型参数，可强制转换为 void* 传递，但需确保数值在指针宽度内（32 位 MCU 上可传 32 位整数）。

4.5 常见误区与总结复盘

总结：任务创建与删除是 FreeRTOS 应用的基础。动态创建灵活但需关注堆大小，静态创建安全但需用户管理内存。TCB 是内核调度的核心依据，理解其结构有助于排查复杂问题。参数传递必须注意指针生命周期，删除操作必须考虑空闲任务的调度机会。在实际项目中，建议优先使用静态创建以增强确定性，并通过 uxTaskGetStackHighWaterMark() 监控栈余量，避免运行时栈溢出。