📚 课程目录第1章任务调度基础

1. 任务调度基础：RTOS核心概念、任务状态机与调度器工作原理

各位同学，咱们今天正式开讲。做嵌入式开发，尤其是跑RTOS的项目，任务调度就是整个系统的“心脏”。你想想看，一个单片机要同时处理按键扫描、屏幕刷新、传感器读取、通信协议栈……如果没有一个靠谱的调度器，代码很快就会乱成一锅粥。

我个人习惯，在讲任何RTOS细节之前，先把最核心的几个概念掰扯清楚。这些概念就像房子的地基，地基不稳，后面盖多高的楼都得塌。

1.1 RTOS核心概念：任务、内核与临界区

先说说什么是“任务”。在裸机编程里，我们写一个while(1)大循环，里面轮流调用各个函数。但在RTOS里，每个独立的功能模块都被封装成一个“任务”（Task），也叫“线程”。每个任务都有自己的栈空间、优先级和状态。

任务 vs 裸机函数：

裸机函数是被动调用的，调用完就返回。
RTOS任务是主动的，它有自己的生命周期，可以“休眠”再“醒来”。

内核（Kernel）是RTOS的大脑。它负责管理所有任务，决定哪个任务该运行、哪个任务该等待。我刚开始用RTOS时，总觉得内核是个很玄乎的东西。后来调试一个多任务死锁问题，跟踪到内核的调度队列，才真正明白——内核说白了就是一套数据结构和调度算法的集合。

还有一个绕不开的概念：临界区。临界区就是那些不能被中断打断的代码段，比如操作一个全局变量、修改链表节点。在RTOS里，进入临界区通常要关中断，或者获取一个互斥锁。

我曾经踩过的坑：在一个电机控制项目里，我在中断服务函数里直接修改了一个任务的挂起标志。结果调度器刚好在判断这个标志，导致任务状态错乱，电机直接飞车。后来我学乖了——中断里和任务间共享数据，要么用临界区保护，要么用原子操作。

1.2 任务状态机：就绪、运行、阻塞与挂起

每个任务在任意时刻都处于某个状态。RTOS的任务状态机，是理解调度行为的关键。我见过不少工程师，代码写了一大堆，问他们任务当前在哪个状态，一脸懵。这不行。

标准的RTOS任务状态有四种：

状态	含义	典型触发条件
就绪（Ready）	任务具备运行条件，等待CPU	创建任务、阻塞超时、获取到资源
运行（Running）	任务正在占用CPU执行	调度器选中该任务
阻塞（Blocked）	任务等待某个事件或资源	调用延时、等待信号量、等待队列消息
挂起（Suspended）	任务被强制暂停，不参与调度	调用挂起API、调试暂停

状态之间的转换是有严格规则的。一个任务只能从“就绪”变成“运行”，不能从“阻塞”直接跳到“运行”。调度器每次只会从“就绪”列表里挑一个任务来执行。

为什么会这样设计？你想想看，如果一个任务还在等串口数据（阻塞态），调度器却强行让它运行，那它跑起来也没事干，白白浪费CPU。RTOS的哲学就是：不让CPU做无用功。

下面这张图，是我每次培训必画的。它把任务状态流转讲得清清楚楚：

调试小技巧：在FreeRTOS里，用uxTaskGetTaskState()可以查看任务当前状态。我习惯在系统异常时，把每个任务的状态打印出来，一眼就能看出哪个任务卡在阻塞态没出来。

1.3 调度器工作原理：谁来决定下一个运行谁？

调度器（Scheduler）是内核里最核心的模块。它的工作很简单：从就绪任务列表里，挑一个任务出来运行。但“怎么挑”这个策略，决定了整个系统的实时性。

主流RTOS的调度策略主要有三种：

优先级抢占式调度（Priority-Based Preemptive）：高优先级任务就绪时，立即抢占低优先级任务的CPU。这是最常用的方式。
时间片轮转调度（Round-Robin）：同优先级任务轮流运行，每个任务分到一个时间片。适合对实时性要求不高的场景。
协作式调度（Cooperative）：任务主动让出CPU，否则一直运行。现在用得少了，但在一些超低功耗场景还有应用。

我给大家看一段伪代码，模拟调度器最核心的决策逻辑：

// 调度器核心逻辑（简化版）
void Scheduler_Schedule(void) {
    TaskControlBlock *nextTask = NULL;
    
    // 1. 从就绪队列中查找最高优先级的任务
    nextTask = GetHighestPriorityReadyTask();
    
    if (nextTask == NULL) {
        // 没有就绪任务，运行空闲任务
        nextTask = &IdleTask;
    }
    
    // 2. 如果找到的任务不是当前运行的任务
    if (nextTask != CurrentRunningTask) {
        // 3. 保存当前任务的上下文（寄存器、栈指针等）
        SaveContext(CurrentRunningTask);
        
        // 4. 切换当前任务指针
        CurrentRunningTask = nextTask;
        
        // 5. 恢复新任务的上下文
        RestoreContext(nextTask);
    }
    
    // 6. 如果相同，什么都不做，继续运行当前任务
}

这段代码看着简单，但实际工程里，上下文切换（Context Switch）是开销最大的操作。保存和恢复寄存器、切换栈指针、处理FPU状态……每一步都消耗CPU周期。

性能调优第一课：上下文切换不是免费的。一个10kHz的调度频率，如果每次切换消耗5μs，那CPU就有5%的时间花在“切换”这件事上，而不是干正事。后面我们会专门讲怎么测量和优化这个开销。

1.4 调度延迟：从事件发生到任务响应的“隐形时间”

调度延迟（Scheduling Latency）是实时系统的核心指标。它指的是：从某个事件触发（比如外部中断），到对应的处理任务开始运行，这中间隔了多长时间。

调度延迟由三部分组成：

延迟阶段	说明	典型耗时
中断延迟	从硬件中断触发到CPU开始执行ISR	几十ns ~ 几μs
ISR处理时间	ISR中执行的操作，包括释放信号量	几μs ~ 几十μs
调度决策时间	从退出ISR到调度器选中新任务	几μs ~ 几十μs

我记得有一次做工业控制项目，要求从传感器中断到电机控制任务响应，总延迟不能超过50μs。结果实测总是超标。排查到最后发现，是一个低优先级任务里有个大循环，关中断时间太长，导致调度器无法及时响应。嗯，这就是典型的“优先级反转”前兆。

避坑指南：千万不要在临界区里做耗时操作。我曾经见过有人在临界区里调用printf打印调试信息，结果串口输出占了几毫秒，整个系统的实时性直接崩了。临界区里只做“原子操作”，比如置个标志位、发个信号量，其他事情出来再做。

1.5 本章小结：地基打牢，后面才稳

这一章我们讲了三个核心东西：

任务是RTOS的基本执行单元，有自己的栈和状态。
状态机决定了任务什么时候能跑、什么时候得等。
调度器负责从就绪队列里挑任务，挑的策略决定了系统的实时性。

这些概念看着简单，但我在实际项目中见过太多因为状态理解错误导致的bug。比如任务明明在阻塞态等信号量，工程师却以为它在运行，查了半天代码逻辑没问题，最后发现是信号量没释放。所以，学会看任务状态，是RTOS调试的第一步。