RTOS任务调度器核心原理：就绪表与上下文切换深度解析

把时间轴拉回到上一篇文章：我们已经能在单片机上创建好几个任务了，点灯代码不再是一段裸机里的死循环，而是被分成了一个个函数，各自带着栈、各自有状态。但你心里大概率还压着一个问题：这些任务到底是怎么被切换的？为什么RTOS里看起来像好几个任务在同时跑？答案就藏在这篇文章要聊的核心，也是整个操作系统的灵魂——任务调度器。

我要聊的就是RTOS里最关键的这一环：任务是怎么被“选中”上台的。你可以把调度器理解成一个后台导演，手里拿着一张排班表，CPU只有一个核，同一瞬间只能有一个任务在跑，但导演可以决定下一秒该让谁上台、该把谁拉下来。这里的核心不是“同时跑”，而是“快速换人”。如果你正打算自己从零写一个迷你RTOS，或者已经在用FreeRTOS/Zephyr这类现成内核想弄明白底层原理，这篇会帮你把调度、就绪表、上下文切换这几块全部串起来。

1. 调度器在天平上的位置：先搞懂它到底在管什么

在动手写代码之前，我建议你先建立一个整体图景。调度器不是一个孤立的函数，它是整个内核的中枢神经。前面几篇我们做了任务的栈初始化、任务控制块（TCB）、延时函数，这些属于“零件”。而调度器是第一个把所有零件组装起来、让系统真正“活”起来的部分。少了它，前面的代码都只会静止不动。

1.1 调度的本质：一个CPU怎么“照顾”一堆任务

生活里其实到处都是调度：快递员一天要送几十个包裹，他不可能同时出现在两个小区，只能排一个顺序；你同时开了好几个聊天窗口，但同一时间只能敲一个字，靠的是在窗口间来回切换。RTOS里的调度也是这个逻辑。

每次调度发生，内核至少要回答三个问题：

• 现在有哪些任务是可以运行的？它们都在“就绪”状态；
• 在这些就绪任务里，谁最应该上CPU？这是调度策略要解决的问题；
• 切换后现场怎么保存？下次切回来时，寄存器、栈指针这些数据不能丢。

这三个问题对应着三块核心代码：就绪表/就绪队列、调度算法、上下文切换。很多初学者第一次看内核源码时被绕晕，就是没把这三个问题分开。其实你只要抓住“找任务、换现场、交CPU”这个主线，所有调度器的代码都能看懂。

1.2 任务状态：从“排队”到“上台”的各个阶段

要理解“选中”这个词，先得知道任务平时都在干嘛。裸机程序里没有状态一说，代码要么在跑要么没跑。但RTOS里的任务至少有四种状态：

• 运行态（Running）：CPU正在执行这个任务；
• 就绪态（Ready）：任务已经准备好，随时可以上CPU，但没轮到他；
• 阻塞态 / 延时态（Blocked / Delayed）：任务在等延时、等信号量、等消息，暂时不需要CPU；
• 挂起态（Suspended）：任务被暂时冻结，需要别人唤醒。

调度器只会从就绪态的任务里挑一个来运行。如果任务因为等待某个资源而阻塞，调度器就先把它从“候选人”名单里划掉，让别的任务先跑。等延时时间到了、资源释放了，再由某个机制把它重新加回就绪名单。

这里最容易踩的认知误区是：很多人以为调度的重点是“切换”，其实是“选择”。选择错了，切换再快也没用。这也是面试里的高频考点：面试官问“RTOS的调度器什么时候触发”，其实就是在考察你对几种调度触发方式的理解。

1.3 调度发生的三种时机

调度器不会像闹钟一样总在响，它只在特定时机被触发。总结下来就三类：

• 任务主动让出CPU：比如调用延时函数、等待事件。这种叫“主动调度”或“合作式调度入口”；
• 时间片到期：系统的时钟节拍（Tick）中断来了，发现当前任务已经跑满一个时间片，于是触发调度。这是“抢占式调度”的关键；
• 中断处理结束后：一个外部中断服务函数跑完了，退出中断前发现有个更高优先级的任务被唤醒，那就没必要回到刚才被打断的低优先级任务，直接切换过去更好。

我在自己手搓的迷你内核里，这三种时机分别对应：os_task_delay()函数入口、SysTick_Handler中断服务函数和中断退出时的延迟调度。你把这三个地方找出来，调度器其实就已经覆盖了大半个骨架。

2. 调度策略怎么选：从“轮流跑”到“优先插队”

下一个绕不开的问题，是我该用什么规则决定“谁上台”。裸机程序不需要策略，顺序就是代码顺序。RTOS可以很复杂，但对一个学习型内核来说，我建议你至少把下面三档都亲手做一遍。先说结论：做RTOS，最终你肯定得落到“优先级抢占”，但不要直接跳过去，前面的简单版本能帮你理解“为什么需要复杂”。

2.1 合作式调度：最老老实实的“轮流”

最早期的做法是合作式调度。规则很简单：每个任务主动说“我暂时不跑了，下一个上”。你在任务代码里调用task_yield()，它才会切走。任务自己不主动让权，别人就只能干瞪眼。

好处是逻辑极简，几乎不会出现竞争问题，因为任务之间是“商量好”的。坏处也很明显：某个任务写了死循环或者长期占着CPU不放手，整个系统就“吊死”在这个任务里，其它任务全部饿死。现实中这种调度器一般只用于非常简单的前后台系统或者一些合作式RTOS里。你学习的时候可以写一个20行的合作式调度器练手，但别指望它能当真正的RTOS内核。

2.2 时间片轮转：CPU时间像披萨一样切开

为了解决“某个人赖在台上不走”的问题，引入了时钟节拍。系统定时器每隔固定时间（比如1ms）产生一次中断，中断里内核把当前任务“请下台”，换下一个就绪任务上台。这样即使某一个任务想一直占用CPU，到了时间也必须下来，让别的任务也能跑一段时间。

这就是时间片轮转。它带来的最大变化是：调度不再完全依赖任务自觉，外部有一个“监督者”。坏处是它不考虑任务重要程度。一个紧急的报警任务和一个无聊的闪烁LED任务可能获得一样多的CPU时间，这在实际项目里是不可接受的。

2.3 优先级抢占：RTOS的“正式选手”

所以真正的RTOS会引入优先级。每个任务在创建时分配一个优先级，数字越小、优先级越高。调度器每次挑选“当前就绪的所有任务里优先级最高的那一个”去运行。高优先级的任务一旦准备好，可以立刻打断低优先级任务，这叫“抢占”。

实际上，绝大多数商业RTOS（FreeRTOS、RT-Thread、Zephyr等）在默认配置下都支持优先级抢占，并且允许在同一个优先级上再做时间片轮转。也就是说，不同优先级之间按“谁急谁先跑”，相同优先级之间按时间片轮流跑。这个组合基本覆盖了大多数嵌入式场景。

我把三种策略放在一起对比过，你一看就明白：

如果你在做的是航空、机器人、电机控制这类对响应时间有硬要求的项目，优先级抢占是必须的。如果只是很简单的状态机流转，合作式调度也许够用。

2.4 一个绕不开的坑：优先级反转

说到优先级抢占，我必须提前给你打个预防针。只按“谁优先级高谁先跑”的规则，会引发一个经典问题——优先级反转。举个很常见的例子：任务A是高优先级，在等一个互斥锁；任务C是低优先级，正拿着这把锁慢吞吞地执行。这时来了个中等优先级任务B，它不碰锁，但因为它的优先级比任务C高，调度器会把CPU从低优先级任务C手里抢走给B。任务A还在继续等锁，而且等的是一个“被更没资格的任务抢了CPU”的任务C，A的优先级反而变成了最低的。

有效的解法之一是“优先级继承”：低优先级任务C在持有锁时，临时被提升到和任务A一样的优先级，等它释放锁之后再降回来。FreeRTOS的互斥量正是这么干的。这个知识点先记着，后面你写信号量和互斥量那篇会用到。

3. 从“一堆任务”里找“一个任务”：就绪表的数据结构设计

现在确定了大方向：优先级抢占。但这里还有个细节问题：任务多的时候，你怎么知道当前谁最高优先级？最朴素的想法是：遍历所有任务的TCB数组，一个个检查状态和优先级，挑一个最合适的。这个方案在任务只有两三个时没问题，但任务一多、调度频繁时，查找耗时就成了性能瓶颈。

所以内核界发展出了另外一个经典做法：位图就绪表。这是我自己当年手搓内核时觉得最精妙的部分，比调度状态机本身更值得琢磨。

3.1 数组扫描的朴素方案：为什么不够用

我们先用最简单的思路设计一下。假设最多有32个任务，每个任务一个TCB，TCB里保存优先级和状态。调度器每次扫描TCB数组，先过滤出状态为就绪的任务，再比较优先级，找到优先级最高（数值最小）的那个。伪代码大概是这样的：

while (1) { uint8_t next = 0xFF; uint8_t best_prio = 0xFF; for (int i = 0; i < MAX_TASKS; i++) { if (tcb[i].state == STATE_READY && tcb[i].priority < best_prio) { best_prio = tcb[i].priority; next = i; } } // 切换到 next 任务 }

这段代码看着挺好，但有两个痛点。第一个痛点是执行时间不确定：最好情况第一次就找到目标，最坏情况要把整个数组扫完。第二个痛点是“O(n)”的复杂度，任务越多，每次选任务的时间就越长。实时系统里我们要求调度器的行为尽可能可预测，最好能在固定几个周期内完成。数组扫描显然做不到。

3.2 位图就绪表：一个比特位代表一个任务

位图就绪表的思路非常巧妙：给每一个任务分配一个二进制位，如果这个位是1，代表该任务就绪；如果是0，代表未就绪。所有任务的就绪状态拼在一起，就是一个“位图”。

比如我设计一个最多支持16个任务的学习型内核，就可以用uint16_t类型的变量保存所有就绪状态。假设当前ready_mask = 0b0000000001000010，那么含义就是第1号任务和第6号任务都处于就绪状态。

选“谁上台”，就成了在二进制串里找出“为1的多个位中，哪一个代表优先级最高”，对应到二进制就是“哪个1所在的位置数最小”。在很多处理器上，这可以靠一条指令搞定。Cortex-M内核有CLZ指令（Count Leading Zeros），可以返回最高位之前有多少个0；编译器通常也提供了内建函数__builtin_ctz，直接数出最低位连续0的个数。

static uint16_t ready_mask; /* 每一位代表一个任务是否就绪 */ uint8_t os_highest_ready_task(void) { if (ready_mask == 0) { return 0xFF; /* 没有任何就绪任务 */ } return (uint8_t)__builtin_ctz(ready_mask); }

ctz返回的是最低位1后面0的个数。比如ready_mask = 0x44，二进制是0000 0000 0100 0100，最低位的1在bit2，所以ctz返回2，正好就是第2号任务。假如任务ID编号按优先级顺序排，数字越小优先级越高，那这个ctz的结果就是“目前该上台的任务”。整个过程只需要一条汇编指令，稳定、快速、无循环。这就是位图法最大的价值。

3.3 任务多怎么办：分两级查找

有人可能会说，如果系统里有上百个任务，一个32位变量就放不下了。做法是再加一层“分组位图”。拿FreeRTOS设计举例：就绪列表用一个数组保存多个优先级对应的任务链表，同时用一个uxTopReadyPriority变量记录当前最高就绪优先级。本质上就变成了两阶段查找：先找最高优先级的“组”，再在组里找具体的任务。

我建议你学习的时候先不要搞这么复杂。从16个任务的单层位图做起，把原理吃透，后面再看FreeRTOS源码会非常顺。单层位图已经能让调度器在固定几个周期内完成“选人”，足以证明RTOS的响应能力来源。

4. 舞台灯光切换：上下文切换到底在做什么

选好了下一个要上台的任务，接下来才是现场切换。这一步最容易翻车，我头几次跑飞代码也基本都是在这里出问题。在Cortex-M上，任务切换的核心是“换栈”。每个任务都有一块独立的栈空间，CPU的寄存器现场就保存在栈里。切换的实质就是：把当前任务的寄存器保存回它自己的栈，再把目标任务栈里保存的寄存器现场加载到CPU，然后继续执行。

4.1 为什么要保存“现场”

现场指的是CPU在某个时刻的寄存器值，包括通用寄存器R0-R12、栈指针SP、链接寄存器LR、程序计数器PC，以及xPSR状态寄存器。如果一个任务正算到一半就被切换走，下次切回来时必须从算到一半的地方继续，而不是从头开始。所以现场必须保存。

拿Cortex-M3/M4（GD32F103、STM32F103这类都属于Cortex-M3）举例，硬件在进入异常时会自动把一部分寄存器压栈：xPSR、PC、LR、R12、R3、R2、R1、R0，一共8个字，按固定顺序压入当前栈。剩下的R4-R11这几个寄存器，则需要软件在汇编代码里手动压栈。所以你在做任务切换时，看到的汇编通常是“先手动压R4-R11，再等异常返回机制自动恢复剩下的部分”。

如果你用的是GCC，伪汇编会像这样：

; 保存当前任务现场 MRS R0, MSP ; 得到当前栈指针 STMDB R0!, {R4-R11} ; 手动压栈 R4-R11 STR R0, [R1] ; 把新栈指针写回当前任务TCB ; 加载目标任务现场 LDR R0, [R2] ; 从目标任务TCB取出栈指针 LDMIA R0!, {R4-R11} ; 弹出 R4-R11 MSR MSP, R0 ; 恢复栈指针 BX LR ; 异常返回，硬件自动弹出剩余寄存器

实际工程里这十几行汇编往往会放到PendSV异常里。原因：如果切换代码在中断服务里直接执行，嵌套中断会破坏现场。PendSV是一种可挂起的系统异常，它的优先级可以设成最低，等所有中断处理完再执行，这样切换过程不会被打断。这也是Cortex-M上最安全的切换方式。

4.2 为什么需要PendSV，而不直接在SysTick里切换

看到这里你可能会想：我就在SysTick中断里直接切换不就行了，干嘛绕一道PendSV？这是很多初学内核的人问过的问题。

假设你在SysTick里执行切换，弹出了高优先级任务A，然后异常返回。但这时如果来了一个外部中断，中断优先级比SysTick高，它会在A开始运行之前插进来。处理完外部中断后，CPU又会回到SysTick退出点，等于切换被“撕裂”了。更严重的情况是，如果中断里调用了延时函数，又触发了调度器，可能有机制上的死锁风险。

PendSV的作用就是把切换动作推迟到“所有更高优先级中断都处理完”之后。由于PendSV优先级通常配置为最低，它能保证切换操作在一个安静的环境里一次完成。这也是为什么FreeRTOS在Cortex-M上会把PendSV作为上下文切换的入口，而未使用直接函数调用。

4.3 第一次切换：任务是怎么“无中生有”被运行起来的

新任务创建时，它的栈里其实早就被“预埋”好了一份虚假的现场：栈顶存放着任务函数的地址（作为PC）、各种寄存器初值，以及一个可选的“任务退出后跳到哪里”的地址。这块工作通常叫“栈初始化”，对应函数就是TaskCreate里的prvTaskInitStack。

第一次调度到新任务时，调度器并不会真的去保存一个不存在的旧现场。它会把当前上下文切换到新任务的“预埋现场”，而当作“从一场中断中恢复返回到任务”来处理。新任务函数地址通过PC寄存器加载，一执行就停不下来，看起来就像它一直活着。

这里有句口诀：**任务创建的时候，内核已经给它写好了一份“开场剧本”，切换只是照着剧本上演。**当初我理解不了这一段，直到自己手动构造了一次伪栈，写一个假xPSR、假PC、假LR，烧进板子看到LED按预期闪烁，才彻底明白。

4.4 临界区：切换中不能被打断的那段代码

为了保证现场保存和恢复的原子性，调度器中还有一道例行工序——关闭中断，也就是进入临界区。在操作TCB、修改就绪表时，如果突然被中断打断，或者发生任务切换，数据一致性立刻崩溃。

我常用的做法是：

static inline void os_enter_critical(void) { __disable_irq(); } static inline void os_exit_critical(void) { __enable_irq(); }

但要注意，简单的关中断虽然粗暴有效，如果嵌套调用会出错（第一次关了，第二次又开，导致中断提前打开）。专业内核会用“保存BASEPRI寄存器”的方法实现可嵌套临界区，具体代码我建议你在学习阶段先不用管，等后面做信号量、队列的时候再升级。

5. 手把手实现一个Mini内核调度器

理论说了这么多，我们来点实际的。我前几篇手搓的内核到今天已经攒够了零件，接下来我会把它们接起来，形成完整的调度循环。板子是GD32F103，也就是Cortex-M3核心，但代码思路对STM32同样适用。

5.1 数据结构：TCB与就绪表怎么定义

我已经在前一篇文章里定义过os_tcb_t，这里稍微扩充一下：

#define MAX_TASKS 16 #define STATE_READY 0 #define STATE_RUNNING 1 #define STATE_DELAYED 2 typedef struct { uint32_t *sp; /* 栈指针，指向任务当前现场 */ uint8_t state; /* 任务状态 */ uint8_t priority; /* 优先级，数值越小优先级越高 */ uint32_t delay_ticks; /* 延时剩余节拍数 */ void (*entry)(void *arg); /* 任务入口函数 */ void *arg; /* 任务参数 */ } os_tcb_t; static os_tcb_t os_tcb[MAX_TASKS]; static uint8_t os_task_count = 0; static uint8_t os_current_task = 0xFF; /* 当前运行的任务ID */ static uint16_t os_ready_mask = 0; /* 就绪位图 */

sp是每个任务自己的栈指针，切换时它最重要。priority用来区分任务重要性。delay_ticks用于延时恢复，每来一次Tick就减1，减到0就重新变成就绪态。

5.2 核心函数：把任务“选出来”并“换上去”

第一步是选择任务，用到的是前面的位图查找：

uint8_t os_sched_get_highest_ready(void) { if (os_ready_mask == 0) { return 0xFF; } return (uint8_t)__builtin_ctz(os_ready_mask); }

第二步是真正切换。这里我做一个简化：在Cortex-M上利用PendSV来切换。调度入口负责选人，如果选中的不是当前任务，就更新TCB状态并触发PendSV。

void os_schedule(void) { uint8_t next = os_sched_get_highest_ready(); if (next == 0xFF) { return; /* 没有就绪任务，继续跑当前任务 */ } if (next != os_current_task) { os_tcb[os_current_task].state = STATE_READY; os_tcb[next].state = STATE_RUNNING; os_current_task = next; /* 触发PendSV，在PendSV里完成真正的现场切换 */ SCB->ICSR = SCB_ICSR_PENDSVSET_Msk; } }

SCB->ICSR里的PENDSVSET位置1，就会挂起PendSV异常。因为PendSV优先级被配成最低，它会等当前中断或任务环境“安静”下来后再执行。

第三步是PendSV处理函数，负责换栈：

__asm void os_pendsv_handler(void) { MRS R0, MSP ; 拿到当前栈指针 STMDB R0!, {R4-R11} ; 保存 R4-R11 LDR R1, =os_current_task LDRB R1, [R1] ; 当前任务ID LDR R2, =os_tcb MOVS R3, #16 ; os_tcb_t.sp 偏移量按实际也算16字节左右 MULS R1, R3, R1 ADDS R2, R1, R2 STR R0, [R2] ; 把当前栈指针写入当前TCB.sp ; 换到下一个任务 LDR R1, =os_current_task LDRB R1, [R1] LDR R2, =os_tcb ... ; 重新计算下一个任务的TCB地址 LDR R0, [R2] ; 取出目标任务栈指针 LDMIA R0!, {R4-R11} ; 恢复 R4-R11 MSR MSP, R0 ; 恢复栈指针 BX LR ; 异常返回，弹出剩余现场 }

真实代码中，偏移量计算我会用offsetof宏或者直接在C里定义访问函数，避免汇编和结构体布局绑死。这里展示的是核心思路——换栈就是换SP。你不需要记死汇编，只要理解“先保存当前任务现场，再装载目标任务现场”就行。

5.3 如何把调度器“喂”起来：SysTick与延时恢复

调度器总得有“心跳”，这个心跳就是SysTick。我这里配置1ms触发一次中断，每次中断做两件事：给所有处于延时状态的任务的delay_ticks减1，减到0后把任务状态改成就绪，并把os_ready_mask对应位置1；然后调用os_schedule()，看看有没有更合适的任务要上位。

void SysTick_Handler(void) { for (int i = 0; i < os_task_count; i++) { if (os_tcb[i].state == STATE_DELAYED) { if (os_tcb[i].delay_ticks > 0) { os_tcb[i].delay_ticks--; } if (os_tcb[i].delay_ticks == 0) { os_tcb[i].state = STATE_READY; os_ready_mask |= (1U << i); } } } os_schedule(); }

这套逻辑和FreeRTOS的vTaskDelay内部处理基本一个路数。任务调用延时函数后，把自己状态改成延时态，把自己在就绪位图里的位清零，然后立刻触发调度，让出CPU：

void os_task_delay(uint32_t ms) { uint32_t ticks = ms / 1; /* 假设系统时基1ms */ os_enter_critical(); os_tcb[os_current_task].delay_ticks = ticks; os_tcb[os_current_task].state = STATE_DELAYED; os_ready_mask &= ~(1U << os_current_task); os_exit_critical(); os_schedule(); }

这里有一个细节：在临界区里修改ready_mask和任务状态，防止SysTick中断正好插进来，把状态改乱。缺了临界区，你很容易看到“任务凭空消失了”或“两个任务同时运行”的诡异现象。

5.4 点灯实验验证：两个任务交替闪烁

代码写完要验证。我搭了一个简单实验：两个LED任务，一个闪烁快（200ms切换），一个闪烁慢（500ms切换）。

void led1_task(void *arg) { while (1) { GPIO_WriteBit(GPIOA, GPIO_Pin_0, Bit_RESET); os_task_delay(200); GPIO_WriteBit(GPIOA, GPIO_Pin_0, Bit_SET); os_task_delay(200); } } void led2_task(void *arg) { while (1) { GPIO_WriteBit(GPIOC, GPIO_Pin_2, Bit_RESET); os_task_delay(500); GPIO_WriteBit(GPIOC, GPIO_Pin_2, Bit_SET); os_task_delay(500); } }

烧录后，两个LED各自按自己的节奏闪。逻辑分析仪抓两个GPIO的电平，可以看到：在200ms边界，LED1动作；在500ms边界，LED2动作；两个任务交替占用CPU，谁也不耽误谁。这就是调度器在工作，不再是裸机顺序执行。

6. 代码跑飞之后的排查心得：调度器调试经验

代码写通是一回事，跑出来是另一回事。调度器一旦出问题，现象经常是HardFault、任务不执行、LED闪了几下就死掉。这里我挑几个我记忆最深的坑，给你一份速查表，直接抄答案。

6.1 一开机就HardFault

常见原因有两个。第一个是任务的栈空间没对齐或者太小，压栈一多就溢出，把TCB区域冲掉了。解决办法是检查启动文件里栈大小配置，任务栈建议至少给256字节以上，学习阶段宁可多给别吝啬。

第二个是PendSV配置错误，比如PendSV优先级没有配置成最低，或者中断服务函数名字写错。写错函数名的话，链接器不会报错，但中断向量表指向了空函数，一触发PendSV就飞了。用GD32时特别注意启动文件里的中断函数名是否和你的os_pendsv_handler一致，不一致就会HardFault。

6.2 任务只是闪了两下，然后卡死不动

大概率是延时恢复逻辑出了问题。我犯过的错有两种：一种是在SystemInit配置SysTick之前就启动了调度器，导致SysTick一直没有触发；另一种是在临界区里调用了os_schedule()，调度器一旦触发PendSV，PendSV又在等当前临界区退出，两边互相等，直接卡死。

排查方法很简单：在SysTick_Handler和os_schedule入口各放一个GPIO翻转，用示波器或逻辑分析仪看这些点有没有脉冲。没有脉冲说明中断没进来；有脉冲但任务还是不动，就去查任务状态和ready_mask的值。

6.3 低优先级任务抢了高优先级任务的时间

这是优先级设置或就绪位图更新时机的问题。如果你在改变任务状态时忘了更新ready_mask，调度器就看不到高优先级任务已经就绪。我建议把“状态置位”和“就绪位图置位”放在同一个函数里，不要散落在多处，否则很容易漏掉一处。

6.4 常见问题速查表

6.5 调试工具：让调度器“看得见”

最后送一个实用技巧。做RTOS开发，不要只在IDE里打断点。调度器天生就是“异步”的，你打断点会干扰时序。我习惯在每个任务的入口放一个全局变量来标记当前任务ID，再配合一个DMA或者定时器，把任务切换序列记录到环形缓冲区里，需要时一帧一帧回放。这样比肉眼盯着LED猜问题高效得多。

如果你不想搞这么复杂，一个简单的做法是：在os_schedule里根据next任务ID往一个GPIO端口写不同数值，然后接个逻辑分析仪看波形。哪个任务长时间占用CPU、哪个任务一直没轮到，一眼就看出来了。

我个人在这些年的实践里，最深的体会是：调度器本质上并不复杂，真正复杂的是“时机”和“边界”。什么时候该关中断、什么时候该触发切换、状态和位图怎么保持一致，这些细节决定了你的内核能不能稳定跑下去。如果你能亲手把上面这套Mini调度器在自己的板子上跑通，再回头去看FreeRTOS的源码，会觉得那些数据结构突然变得亲切起来——因为它们解决的正是我们刚踩过的这些问题。接下来如果你有兴趣，我们可以继续往下拆信号量、队列、内存管理，那又是一个新的世界。