任务创建与栈深度优化：任务控制块(TCB)精简、栈空间静态分配技巧、最小栈深度计算
好，咱们直接进入正题。任务创建，说白了就是给每个任务发一张「身份证」和一块「私人地盘」。身份证就是任务控制块（TCB），地盘就是栈空间。很多初学者觉得这俩东西随便配配就行，结果跑起来要么栈溢出，要么内存浪费得心疼。我当年第一次做多任务系统时，就吃过栈空间没算好的亏——任务跑着跑着就飞了，查了三天才发现是栈不够用。
任务控制块（TCB）精简：能省则省
TCB 是 FreeRTOS 管理任务的核心数据结构。每个任务都有一个 TCB，里面存了任务状态、栈指针、优先级这些信息。默认的 TCB 其实挺「胖」的，里面有些字段你可能根本用不上。
我个人习惯，在项目初期就会打开 FreeRTOSConfig.h，把不需要的功能对应的宏关掉。比如：
- 不用任务通知？关掉
configUSE_TASK_NOTIFICATIONS - 不用互斥量？关掉
configUSE_MUTEXES - 不用递归互斥量？关掉
configUSE_RECURSIVE_MUTEXES - 不用软件定时器？关掉
configUSE_TIMERS
每关掉一个宏，TCB 里对应的字段就会被条件编译去掉。你想想看，一个 TCB 省 4 字节，系统里跑 10 个任务，就省了 40 字节。在 Cortex-M0 这种只有 8KB RAM 的芯片上，这 40 字节可能就是救命稻草。
核心思路：TCB 精简不是靠手动改源码，而是靠配置宏。FreeRTOS 的源码里到处都是 #ifdef，你只需要在配置头文件里做减法。
我记得有一次帮客户优化一个智能家居项目，他们用了 20 个任务，RAM 只剩 200 字节。我进去一看，好家伙，configUSE_TASK_NOTIFICATIONS 和 configUSE_TIMERS 都开着，但代码里根本没用到。关掉之后，TCB 直接瘦身 15%，系统稳稳地跑起来了。
栈空间静态分配技巧：别让 malloc 背锅
FreeRTOS 支持两种栈分配方式：动态分配（用 pvPortMalloc）和静态分配（你提前准备好数组）。在嵌入式领域，我强烈建议你用静态分配。为什么？
- 确定性：栈空间在编译时就定死了，不会出现运行时 malloc 失败的情况。
- 调试方便：栈溢出时，你能直接看到数组的边界被踩了。
- 性能：没有堆管理开销，任务创建速度更快。
静态分配的写法很简单：
// 定义栈空间
#define TASK1_STACK_SIZE 128
StackType_t task1Stack[TASK1_STACK_SIZE];
// 定义 TCB 空间
StaticTask_t task1TCB;
// 创建任务
TaskHandle_t task1Handle = xTaskCreateStatic(
task1Function, // 任务函数
"Task1", // 任务名
TASK1_STACK_SIZE, // 栈深度（单位：字，不是字节）
NULL, // 参数
1, // 优先级
task1Stack, // 栈指针
&task1TCB // TCB 指针
);嗯，这里要注意：TASK1_STACK_SIZE 的单位是「字」，在 Cortex-M 上就是 4 字节。所以 128 字 = 512 字节。我见过有人把单位搞混，直接传了 128 字节，结果栈空间只有 32 个字，任务一跑就崩。
技巧：把栈数组和 TCB 数组定义成全局变量，或者放在一个专门的内存段里。这样你可以在链接脚本里控制它们的地址，比如放在 SRAM 的特定区域，方便调试时观察。
最小栈深度计算：别靠猜，靠算
栈深度怎么定？很多人拍脑袋给个 256 或 512，跑起来没问题就不管了。但你要知道，栈给多了浪费，给少了崩溃。我见过最离谱的项目，一个任务栈给了 2048 字，结果实际只用 100 字——白白浪费了 7KB 多。
计算最小栈深度，核心是搞清楚任务运行时栈里会压入什么：
- 任务上下文：当任务被切换时，CPU 自动压入的寄存器。Cortex-M3/M4 会压入 8 个寄存器（32 字节），M0/M0+ 会压入 16 个寄存器（64 字节）。
- 函数调用链：任务函数里调用了其他函数，每个函数调用都会压入返回地址、局部变量等。
- 中断嵌套：如果任务执行中被中断打断，中断服务函数也会用栈。这个最容易被忽略。
- FreeRTOS 内部调用：比如你调用了
vTaskDelay、xQueueSend等 API，它们内部也会用栈。
我一般用「经验公式 + 实测」的方法：
最小栈深度 = 任务上下文 + 最大函数调用链 + 最大中断嵌套 + 安全余量举个例子，一个简单的 LED 闪烁任务：
void vTaskLED(void *pvParameters) {
for(;;) {
GPIO_Toggle(LED_PIN);
vTaskDelay(pdMS_TO_TICKS(500));
}
}这个任务里，函数调用链是 vTaskLED -> GPIO_Toggle -> vTaskDelay。在 Cortex-M3 上，我估算：
- 任务上下文：32 字节
- 函数调用链：约 40 字节（每个函数平均 10-20 字节）
- 中断嵌套：假设最大嵌套 2 级，每级 64 字节，共 128 字节
- 安全余量：50 字节
加起来约 250 字节，折合 63 个字。所以我一般给 80 个字，留点余量。
警告：千万不要用 uxTaskGetStackHighWaterMark() 来「反向推算」最小栈深度。这个函数返回的是历史最低水位，不是理论最小值。我曾经在一个项目中，用这个函数测出来栈只用了一半，结果换了个中断更频繁的场景，直接栈溢出。为什么？因为测试时中断没来，水位自然低。
正确的做法是：先用一个较大的栈（比如 256 字）跑所有功能，然后用 uxTaskGetStackHighWaterMark() 看实际用了多少，再根据这个值加上 20%-30% 的安全余量，作为最终栈深度。注意，这个安全余量是给未来功能扩展用的，不是给中断用的——中断的栈需求必须单独算清楚。
好了，任务创建和栈优化这块，核心就是三件事：TCB 能减就减、栈空间静态分配、栈深度算清楚再给。下一章我会讲任务优先级和调度策略的深度调优，到时候咱们再聊。