第2章 FreeRTOS内核架构

2. FreeRTOS内核架构：任务控制块、就绪列表、延时列表、内存管理方案

好，咱们直接切入正题。这一章要聊的，是FreeRTOS内核最核心的四个东西：任务控制块、就绪列表、延时列表，还有内存管理。说白了，你把这四个东西搞明白了，整个FreeRTOS的调度机制你也就通了八成。

我刚开始接触RTOS那会儿，总觉得任务调度是个玄学。后来发现，其实内核就是个「状态机+链表」的组合。嗯，咱们一层层剥开看。

2.1 任务控制块（TCB）—— 任务的身份证

每个任务在FreeRTOS里都有一个对应的结构体，叫TaskControlBlock_t。你可以把它理解成任务的「身份证」加「档案袋」。里面存了什么？任务栈指针、优先级、状态、任务名、事件等待信息……几乎所有的调度决策，都依赖TCB里的字段。

我个人习惯，在调试复杂系统时，第一件事就是打印TCB的关键字段。比如栈顶指针有没有溢出，优先级是不是被意外修改了。有一次我在项目中遇到一个任务莫名其妙不跑了，查了半天，发现是某个中断服务函数里不小心把TCB的uxPriority改成了0。嗯，这种坑，你踩过一次就记住了。

// FreeRTOS TCB 核心字段（简化版）
typedef struct tskTaskControlBlock {
    volatile StackType_t    *pxTopOfStack;      // 当前栈顶指针
    ListItem_t              xStateListItem;     // 状态链表节点（就绪/阻塞/挂起）
    ListItem_t              xEventListItem;     // 事件链表节点（用于同步）
    UBaseType_t             uxPriority;         // 任务优先级
    StackType_t             *pxStack;           // 栈起始地址
    char                    pcTaskName[configMAX_TASK_NAME_LEN]; // 任务名
    // ... 还有其他字段，比如栈大小、临界区嵌套计数等
} tskTCB;

你想想看，每个任务在创建时，内核会分配一个TCB。这个TCB一旦创建，就跟着任务一辈子，直到任务被删除。所以TCB的内存管理，直接决定了系统的稳定性。

核心要点：TCB是FreeRTOS调度的心脏。所有调度算法（优先级抢占、时间片轮转、事件等待）最终操作的都是TCB中的链表节点。

2.2 就绪列表 —— 谁准备好了？

就绪列表，说白了就是一个数组，数组的每个元素是一个双向链表。数组下标对应任务优先级。比如优先级0的任务挂在pxReadyTasksLists[0]上，优先级5的任务挂在pxReadyTasksLists[5]上。

为什么会这样设计？因为调度器每次选任务时，只需要从最高优先级的非空链表里取出第一个任务就行了。时间复杂度是O(1)，非常快。我记得在飞控项目中，任务数量最多的时候有30多个，但调度开销几乎可以忽略不计。

// 就绪列表定义（简化）
PRIVILEGED_DATA static List_t pxReadyTasksLists[ configMAX_PRIORITIES ];

这里有个细节要注意：同优先级的任务采用时间片轮转调度。每个任务运行一个时间片（通常是1ms），然后切换到同优先级的下一个任务。如果你在项目中遇到某个任务一直抢不到CPU，多半是优先级设置不合理，或者就绪列表里出现了优先级反转。

避坑指南：我曾经在一个多传感器采集项目中，把三个采集任务设成了相同优先级。结果发现其中一个任务总是被饿死。后来查出来，是因为那个任务的执行时间刚好是其他任务的整数倍，导致时间片轮转时它永远排最后。解决办法是给关键任务提一级优先级，或者用任务通知做同步。

2.3 延时列表 —— 谁在睡觉？

延时列表，就是用来管理那些调用了vTaskDelay()或者等待事件超时的任务。FreeRTOS用了两个延时列表：pxDelayedTaskList和pxOverflowDelayedTaskList。为什么是两个？因为系统节拍计数器（xTickCount）可能会溢出，用两个列表做交替切换，可以避免溢出带来的混乱。

嗯，这里要稍微绕一下。你想想看，xTickCount是一个32位无符号整数，最大值是2^32-1。如果系统一直运行，它迟早会溢出。FreeRTOS的做法是：当xTickCount溢出时，把当前延时列表和溢出延时列表互换。这样，那些「超时时间在溢出后」的任务，就自动迁移到了新的列表中。

// 延时列表定义
PRIVILEGED_DATA static List_t pxDelayedTaskList[ 2 ];  // 两个列表交替使用
PRIVILEGED_DATA static List_t * volatile pxCurrentDelayedTaskList;
PRIVILEGED_DATA static List_t * volatile pxOverflowDelayedTaskList;

我在实际项目中，很少直接操作延时列表。但理解它的机制很重要。比如，你调用vTaskDelayUntil()实现周期性任务时，如果系统节拍频率设置不当，可能会导致任务唤醒时间漂移。我曾经在无人机姿态控制任务中，把节拍频率设成了1000Hz，结果发现任务每次唤醒都有微小的抖动。后来改成用vTaskDelayUntil()配合绝对时间，才解决了问题。

注意：延时列表中的任务，是按唤醒时间排序的。调度器每次节拍中断时，只会检查链表头部的任务。如果头部任务还没到唤醒时间，后面的任务就不用看了。这种设计保证了效率。

2.4 内存管理方案 —— 堆怎么分？

FreeRTOS提供了5种内存管理方案，从heap_1到heap_5。我重点讲最常用的两个：heap_4和heap_5。

方案	特点	适用场景
heap_1	只能分配，不能释放。简单、确定性强	任务创建后永不删除的静态系统
heap_2	支持释放，但可能产生碎片	已废弃，不推荐使用
heap_3	包装了标准malloc/free，线程安全	需要标准库支持的环境
heap_4	首次适应算法，支持合并相邻空闲块	最常用，适合大多数嵌入式项目
heap_5	支持多个不连续的内存区域	内存分布在多个物理区域（如内部SRAM+外部SDRAM）

我个人强烈推荐heap_4。它用了一个空闲块链表，每次分配时从头遍历，找到第一个足够大的块。释放时，会检查相邻块是否空闲，如果是就合并。这种机制在长时间运行的系统中，碎片控制得相当不错。

我曾经在一个需要连续运行数月的工业控制器项目中，用了heap_4。期间任务频繁创建和删除，但内存碎片始终没有导致分配失败。当然，前提是你得合理估算最大任务数量，给堆预留足够的空间。

// 在FreeRTOSConfig.h中配置堆大小
#define configTOTAL_HEAP_SIZE                    ( ( size_t ) ( 30 * 1024 ) )  // 30KB堆空间

经验之谈：如果你用heap_5，记得调用vPortDefineHeapRegions()来注册内存区域。我见过有人忘了这步，结果任务创建直接返回NULL。另外，heap_5的初始化顺序很重要——先注册的区域，分配时会优先使用。

2.5 小结一下

这一章的内容，说白了就是FreeRTOS内核的「骨架」：

TCB：每个任务的唯一标识，调度器操作的核心对象。
就绪列表：按优先级组织的双向链表，决定了「下一个该谁跑」。
延时列表：管理所有等待中的任务，双列表设计解决了节拍溢出问题。
内存管理：heap_4是首选，heap_5用于多区域内存。

你把这些搞清楚了，后面讲任务切换、中断管理、临界区保护时，就会觉得顺理成章。嗯，下一章咱们聊聊任务创建和删除背后的那些细节——你会发现，其实内核就是在不停地操作这些链表和TCB。

📚 课程目录

2. FreeRTOS内核架构：任务控制块、就绪列表、延时列表、内存管理方案

2.1 任务控制块（TCB）—— 任务的身份证

2.2 就绪列表 —— 谁准备好了？

2.3 延时列表 —— 谁在睡觉？

2.4 内存管理方案 —— 堆怎么分？

2.5 小结一下