2. RISC-V工具链概览
任务管理，说白了就是RTOS的"大脑"。你想想看，一个系统里同时跑着十几个任务，谁先执行、谁暂停、谁等着，总得有个规矩。这个规矩，就是任务状态机和优先级抢占机制。
我记得刚接触RTOS那会儿，总觉得任务状态切换挺玄乎的。后来自己动手移植内核，才明白这东西其实就四个状态来回倒腾。咱们今天就把这事彻底讲透。
任务状态机：四个状态的流转逻辑
RTOS里的任务，一辈子就在四个状态里打转：就绪、运行、阻塞、挂起。有些教材还细分出"休眠态"和"中断态"，但核心就这四个。
核心要点：任何时刻，一个任务只能处于一个状态。状态切换由内核调度器统一管理，应用层代码不能直接修改任务状态。
咱们先看一张状态流转图，把整体脉络理清楚：
四个状态，逐个拆解
就绪态（Ready）
任务已经准备好运行，只等调度器给它CPU时间。就绪队列里排着队的，全是这个状态的任务。我习惯把就绪队列想象成"候诊室"——大家都在等，但谁先看诊，得看优先级和调度策略。
运行态（Running）
任务正在占用CPU执行代码。单核系统里，同一时刻只有一个任务能处于运行态。说白了，CPU一次只能伺候一个人。
阻塞态（Blocked）
任务在等某个事件：等信号量、等消息队列、等延时结束。这时候任务不消耗CPU，内核把它从就绪队列移到阻塞队列。我曾经在项目里遇到过一个bug，任务莫名其妙不跑了，查了半天发现是信号量永远等不到——典型的"死等"问题。
挂起态（Suspended）
任务被应用层主动暂停，不参与调度。挂起态和阻塞态的区别在于：阻塞是"被动等资源"，挂起是"主动不干活"。恢复挂起任务需要调用专门的API。
我的经验：调试阶段，我经常用挂起态来"冻结"某个任务，方便单步分析其他任务的行为。但产品代码里慎用挂起，容易引入隐藏的时序问题。
任务优先级：谁更重要
优先级就是个数字，数字越小优先级越高（有些RTOS反过来，看具体实现）。优先级决定了调度器在就绪队列里先选谁。
| 优先级范围 | 典型用途 | 注意事项 |
|---|---|---|
| 0-3（最高） | 中断处理、时间关键型任务 | 占用CPU时间要极短 |
| 4-7（高） | 实时控制、传感器采集 | 确保周期性能满足 |
| 8-15（中） | 协议栈、数据处理 | 可容忍少量延迟 |
| 16-31（低） | 后台任务、日志输出 | CPU空闲时才跑 |
优先级分配有个基本原则：紧急且短的任务给高优先级，不紧急或长的任务给低优先级。我见过有人把所有任务都设成同一个优先级，那跟裸机轮询有什么区别？
抢占机制：高优先级任务"插队"
抢占，就是高优先级任务来了，低优先级任务得立刻让出CPU。这是RTOS实时性的核心保障。
抢占发生的典型场景：
- 高优先级任务就绪：比如中断里释放了一个信号量，唤醒了高优先级任务
- 时间片用完：同优先级任务轮转，当前任务被换下
- 任务主动阻塞：当前任务调用延时或等待资源，调度器选下一个就绪任务
注意：抢占不是无条件的。临界区里关中断或拿锁时，抢占会被暂时禁止。我曾经在一个项目中，因为临界区太大，导致高优先级任务被阻塞了200微秒——这在音频处理里就是灾难。
抢占机制的代码实现
咱们看一段简化版的调度器核心代码，理解抢占是怎么实现的：
/* 调度器核心 - 任务切换 */
void Scheduler_Switch(void)
{
uint32_t highest_prio;
TCB_t *next_task;
/* 关中断，保护就绪队列 */
EnterCritical();
/* 找到当前最高优先级的就绪任务 */
highest_prio = GetHighestReadyPriority();
next_task = ReadyQueue[highest_prio].head;
if (next_task != NULL && next_task != CurrentTask)
{
/* 保存当前任务上下文 */
SaveContext(&CurrentTask->stack_ptr);
/* 切换任务 */
CurrentTask = next_task;
/* 恢复新任务上下文 */
RestoreContext(CurrentTask->stack_ptr);
}
/* 开中断 */
ExitCritical();
}这段代码里，GetHighestReadyPriority() 是关键。我习惯用位图法来实现优先级查找，32位优先级的话，一条指令就能找到最高优先级，O(1)复杂度。
优先级反转与解决方案
优先级反转是个经典问题。简单说：低优先级任务拿着高优先级任务需要的资源，导致高优先级任务被"反向阻塞"。
举个例子：
- 任务A（优先级5）拿了互斥锁
- 任务B（优先级3）抢占了A，但B不需要那个锁
- 任务C（优先级1）需要锁，但锁在A手里，A又被B抢占了
- 结果：最高优先级的C，反而被两个低优先级任务拖住了
解决方案有两种：
| 方案 | 原理 | 优缺点 |
|---|---|---|
| 优先级继承 | 低优先级任务持有锁时，临时继承等待者的高优先级 | 实现简单，但可能引入多次优先级变更 |
| 优先级天花板 | 锁的优先级设为所有可能使用者的最高值 | 实现更复杂，但能避免链式阻塞 |
我建议：小系统用优先级继承就够了。我在一个传感器节点项目里用过优先级天花板，结果因为锁的优先级设得太高，把几个中等优先级的任务饿死了。后来换成继承，问题解决。
任务状态切换的典型场景
咱们看一个实际例子，把状态流转串起来：
/* 任务A：高优先级，周期性采集数据 */
void TaskA(void *arg)
{
while (1)
{
/* 状态：运行态 */
sensor_data = ReadSensor();
/* 发送数据到队列，然后等待下一个周期 */
/* 调用延时 → 状态变为阻塞态 */
vTaskDelay(10); /* 延时10个tick */
/* 延时结束 → 状态变为就绪态 */
/* 调度器选中 → 状态变为运行态 */
}
}
/* 任务B：低优先级，处理数据 */
void TaskB(void *arg)
{
while (1)
{
/* 等待队列消息 → 状态变为阻塞态 */
xQueueReceive(data_queue, &data, portMAX_DELAY);
/* 收到消息 → 状态变为就绪态 */
/* 如果TaskA不在运行 → 变为运行态 */
ProcessData(data);
}
}这个例子里，TaskA每10个tick醒来一次，采集数据后继续睡。TaskB一直等队列消息，没消息就阻塞着。两个任务的状态切换，完全由内核自动管理。
避坑指南
我曾经踩过的坑：
- 优先级设得太接近：两个任务优先级只差1，结果高优先级任务频繁抢占，低优先级任务几乎拿不到CPU。后来我把关键任务优先级拉开3级以上，问题解决。
- 忘记在阻塞态释放CPU：有人写了个while(flag)空转等标志位，直接把CPU占死了。记住：等资源一定要用内核提供的阻塞API，别自己写死循环。
- 挂起任务后忘了恢复：调试时挂起了一个任务，产品发布时忘了取消挂起。那个功能模块从此"消失"了。后来我养成了习惯：挂起操作必须配对，并在代码里加注释。
小结
任务状态机和抢占机制，是RTOS的基石。四个状态（就绪、运行、阻塞、挂起）的流转逻辑，加上优先级驱动的抢占调度，构成了多任务并发执行的基本框架。理解这些，你就能看懂调度器在干什么，也就能写出更可靠的多任务程序。
嗯，这部分内容就到这里。记住：状态切换是内核的事，应用层只管"我要等什么"和"我准备好了"。别越俎代庖，别自己管理任务状态——那是内核的活。