上一篇文章我把任务管理和内存管理讲完之后好几个读者私信问我你天天说uC/OS-II 只有6736行代码可为什么我一打开os_core.c就头晕这很正常uC/OS-II 的代码风格是“数据结构宏定义决定一切”。你越往后读越会发现那些绕来绕去的数组、掩码、宏最后串起来的调度逻辑简单到让人拍桌子。这一篇我们专门啃整个内核里最硬核的三块任务调度、时间管理还有那堆到处 Pend/Post 的内核对象。我始终觉得uC/OS-II 是所有 RTOS 里最适合拿来“精读”的一个。它不像 Linux 内核那样浩如烟海一套核心源码去掉注释和空行满打满算几千行却能完整实现抢占式多任务、信号量、互斥量、消息队列、事件标志组、内存分区管理这些 RTOS 标配功能。你看懂这6736行再回头看 FreeRTOS、RT-Thread、Zephyr很多概念都是相通的只是实现方式各有取舍。甚至你去面嵌入式岗位面试官问的“优先级反转如何解决”“任务切换谁在做”“tick 中断里发生了什么”答案全在这几千行里面。1. 这一篇我们啃 uC/OS-II 最硬核的部分1.1 先交代一下这个系列走到哪了这个系列的前两篇逻辑是这样的第一篇从main函数出发讲了 uC/OS-II 是怎么从裸机跑起来的包括OSInit、OSTaskCreate、OSStart的启动流程以及第一次任务切换OSStartHighRdy背后做了什么第二篇完整分析了任务控制块 TCB、任务栈、空闲任务、统计任务还有内存分区管理OSMem的实现。如果你前面两篇都看完了现在脑中应该有一个基本画面每个任务有一个 TCB里面保存着任务栈指针、任务状态、优先级、事件等待信息等系统通过一个双向链表把这些 TCB 串起来同时通过就绪表Ready Table标记当前“谁可以跑”。这一篇要干嘛说白了就是把“谁可以跑”这个判断逻辑彻底讲透再把任务之间的通信同步机制全部过一遍。这是 RTOS 的核心价值所在也是面试题最爱出题的区域。读完这一篇你至少应该能回答这几个问题优先级就绪表为什么用“分组查表”的方式找最高优先级任务这比遍历链表快多少OS_Sched和OSIntExit哪个是 ISR 里触发的两者切换路径有何不同信号量 Pend 下去之后任务究竟被塞到了哪里优先级继承是怎么用几行代码实现的tick 中断到底多久触发一次、怎么让延时的任务准点醒来1.2 从整体看6736行代码里藏着什么先说明一下“6736行”这个数字。以 uC/OS-II V2.86 为参考核心源码文件包括os_core.c、os_task.c、os_time.c、os_sem.c、os_mutex.c、os_mbox.c、os_q.c、os_flag.c、os_mem.c以及对应的头文件和可选配置。我把这些文件里的有效代码加起来大约就是 6736 行含注释和空行不同版本数字会有差异。但真正决定系统行为的核心算法可能不到2000行。其余的是各种 API 的封装、参数检查、以及为了兼容不同编译器的宏处理。你把这 6736 行拆开看会发现它其实就干了几件事任务管理创建、删除、挂起、恢复任务初始化任务栈任务切换调度核心维护就绪表找出最高优先级任务完成上下文切换时间管理tick 中断处理任务延时按时唤醒内核对象事件控制块ECB作为一个“统一基类”然后在这之上派生信号量、互斥量、消息邮箱、消息队列、事件标志组内存管理固定大小内存块的分配与释放。所以读源码的正确姿势不是一行行从头啃到尾而是先抓住“调度”这条主脑再看“内核对象”这棵从主脑分出去的枝干。这篇就按这个顺序来。2. 任务调度那两张位图表是如何用空间换时间的2.1 就绪表的数据结构与映射逻辑uC/OS-II 查找最高优先级任务不是遍历任务链表而是靠两张表OSRdyGrp和OSRdyTbl[]。很多新手第一次看到这两张表会被吓到其实它的设计思路特别朴素。假设最大支持64个任务优先级0最高63最低把优先级 0~63 拆成“组号”和“组内序号”两部分#define OS_RDY_TBL_SIZE ( ( OS_LOWEST_PRIO ) / 8 1 ) // 默认 8 OS_PRIO OSRdyGrp; // 就绪组1字节每一位对应一组 OS_PRIO OSRdyTbl[OS_RDY_TBL_SIZE]; // 就绪表8字节映射关系是这样的// 优先级 prio 对应的组号和组内位 prio 3 // 等价于 prio / 8得到 y也就是组号 prio 0x07 // 等价于 prio % 8得到 x也就是组内第几位 // 把某优先级置为就绪 OSRdyGrp | OSMapTbl[prio 3]; OSRdyTbl[prio 3] | OSMapTbl[prio 0x07]; // 把某优先级清除就绪 if ((OSRdyTbl[prio 3] ~OSMapTbl[prio 0x07]) 0) { OSRdyGrp ~OSMapTbl[prio 3]; }OSMapTbl是一个查表用的常量数组OSMapTbl[0]0x01, OSMapTbl[1]0x02, ..., OSMapTbl[7]0x80。它的作用就是把“逻辑上的第几位”翻译成“二进制里的 bit 位置”。为什么要这么设计呢你想如果不用分组查表要找到当前最高优先级任务常规思路是写一个循环从优先级0扫到63看到哪个位是1就选谁。最坏情况要循环64次平均也要32次。这在中断里做一次还行但调度器随时可能被调用时间是不确定的。RTOS 要求的是“确定性”最好每条路径的执行时间都固定。uC/OS-II 的做法是再加一张表OSUnMapTbl[256]这张表有256个元素记录“一个字节里最低的置1位是第几位”。怎么用呢y OSUnMapTbl[OSRdyGrp]; // 找到组号 y也就是最高优先级所在组 x OSUnMapTbl[OSRdyTbl[y]]; // 在这个组里找到最低置1位 x prio (y 3) x; // 合成最终的优先级整个查找过程就是三次数组下标访问加一次移位没有任何循环时间完全确定。这就是典型的“用空间换时间”。如果你以后看到别的 RTOS 用__clzCount Leading Zeros或者硬件指令做类似事情本质上都是在干同一件事——把“找最高位”这个操作加速到 O(1)。我建议你把OSUnMapTbl的生成逻辑自己写一遍比如遍历每个字节值看最低置1位在哪然后对照源码里那张表验证。亲自推导过之后你会彻底忘不掉这个算法。2.2 调度器 OS_Sched一次完整调度的源码级走读调度器有两个入口任务级调度OS_Sched和中断级调度OSIntExit。先看任务级调度。void OS_Sched (void) { OS_ENTER_CRITICAL(); if (OSIntNesting 0) { // 不在中断里才允许任务调度 if (OSLockNesting 0) { // 调度器没被锁 OSPrioHighRdy OSUnMapTbl[OSRdyGrp]; // 找组号 if (OSPrioHighRdy ! OSPrioCur) { // 最高优先级不是当前任务 OSTCBHighRdy OSTCBPrioTbl[OSPrioHighRdy]; OSCtxSwCtr; OS_TASK_SW(); // 触发 PendSV/软中断做上下文切换 } } } OS_EXIT_CRITICAL(); }这段代码短到让人怀疑这是不是“内核核心”。注意它做了三件关键的事第一判断是否在中断里。如果OSIntNesting大于0说明当前是在 ISR 里调用调度的这时不能直接做任务切换要等中断退出时统一处理。为什么因为中断现场的寄存器还没有保存完整如果你在这里切换走回来后 ISR 怎么继续跑所以在中断里只标记不切换。第二判断调度器有没有被锁。OSLockNesting是调度锁计数器谁调用了OSLockSched它加1暂时禁止任务调度OSUnlockSched再减回来。这跟关中断OS_ENTER_CRITICAL是两码事。关中断是连 ISR 都不让执行调度锁只是不让任务切换中断照常响应。有经验的开发者会在OSLockSched之后尽量减少临界区时间因为它会拖慢实时性。第三调用宏OS_TASK_SW()。这个宏通常在os_cpu.h里被定义为一个软中断或者 PendSV 异常。在 Cortex-M3 上就是触发 PendSV然后由OSCtxSw汇编代码完成真正的寄存器压栈、任务栈切换、出栈恢复。你可能要问了OS_TASK_SW只是触发了个异常真正的切换在异常处理函数里做为什么不直接写个 C 函数切因为上下文切换必须要操作 CPU 寄存器还要保证在切换瞬间不被打断C 语言表达不了“把当前 CPU 寄存器全部压到任务的栈上”这个动作必须用汇编。这就是每个 RTOS 都要有os_cpu_a.asm这类文件的原因。2.3 中断级调度 OSIntExit 与切换细节中断里的调度逻辑长这样void OSIntExit (void) { OS_ENTER_CRITICAL(); if (OSIntNesting 0) { // 中断嵌套计数减1 OSIntNesting--; } if (OSIntNesting 0) { // 退到最外层中断才处理 if (OSLockNesting 0) { OSPrioHighRdy OSUnMapTbl[OSRdyGrp]; if (OSPrioHighRdy ! OSPrioCur) { OSTCBHighRdy OSTCBPrioTbl[OSPrioHighRdy]; OSCtxSwCtr; OSIntCtxSw(); // 中断级上下文切换 } } } OS_EXIT_CRITICAL(); }这段代码和OS_Sched长得非常像但它不是直接调用OS_TASK_SW()而是调用OSIntCtxSw()。为什么因为中断退出时栈上的现场和普通任务切换时的现场不一样。普通任务切换时任务的上下文完整保存在自己的栈里但中断退出时CPU 已经自动压了一部分寄存器ISR 里可能还手动压了一部分栈指针的位置是乱的。OSIntCtxSw的汇编代码会先做栈指针修正跳过那些不属于“任务上下文”的部分然后再模拟一次任务切换丢掉不用的中断帧。在 Cortex-M 上OSIntCtxSw的做法通常是先把OSTCBCur指向的新任务栈指针装载到 PSP然后返回紧接着PendSV_Handler被触发或直接使用PendSV但技巧在于不要让 PendSV 压栈因为中断返回时使用的本来就是新任务的“中断帧”。这一块细节特别多也是移植时最容易出 bug 的地方。我给一个实际排查的经验如果任务切换后跑飞优先检查两个地方。一个是OSIntCtxSw处的栈指针调整是否正确另一个是中断发生时是否用了错误的工作模式比如在 MSP 和 PSP 之间切换时没有正确设置。这两个坑我当时移植到一款国产 M0 核 MCU 上时整整调了一周最后加了调试打印才定位到是 MSP/PSP 切换时机不对。3. 时间管理tick 是如何让任务“睡到点就醒”的3.1 OSTimeTick 与延时链表的闭环先问一个问题任务调用OSTimeDly(50)之后它是怎么知道自己睡了50个 tick 的答案不是它自己定闹钟而是系统有一个周期性中断——tick 中断——每个 tick 都去检查所有正在睡眠的任务看谁的延时时间到了。这个周期性中断对应的入口是OSTimeTickvoid OSTimeTick (void) { OS_TCB *ptcb; OS_ENTER_CRITICAL(); ptcb OSTCBList; // 从任务链表头开始 while (ptcb ! (OS_TCB *)0) { // 遍历所有任务 if (ptcb-OSTCBDly ! 0) { // 这个任务有延时或超时等待 ptcb-OSTCBDly--; if (ptcb-OSTCBDly 0) { // 延时结束 if ((ptcb-OSTCBStat OS_STAT_SUSPEND) OS_STAT_RDY) { OSRdyGrp | OSMapTbl[ptcb-OSTCBPrio 3]; OSRdyTbl[ptcb-OSTCBPrio 3] | OSMapTbl[ptcb-OSTCBPrio 0x07]; } else { ptcb-OSTCBDly 1; // 任务被挂起不能立即就绪 } } } ptcb ptcb-OSTCBNext; } OS_EXIT_CRITICAL(); }看到了吧核心逻辑就是遍历任务链表把所有OSTCBDly大于0的任务减1减到0了就把任务恢复到就绪表。这里有个非常重要的细节如果任务不是因为延时到点而是因为挂起OS_STAT_SUSPEND而不在就绪态那即使OSTCBDly减到0也不能让它就绪所以代码里做了一个状态判断并且把OSTCBDly强制设为1防止它反复进入这个分支。这是我当初读源码时最容易忽略的一行却直接决定挂起任务的正确性。OSTimeTick是在中断里调用的。所以哪怕任务正在跑tick 中断也会“挤”进来。这其实体现了抢占式内核的基本特征时间由中断驱动任务被打断是常态切换由调度器保证现场完整。你如果把OSTimeTick里的打印打开会发现它在高优先级任务运行期间也会触发完全是“无感”的。3.2 OSTimeDly 与 OSTimeDlyHMSM 的底层实现任务延时 API 有好几个OSTimeDly、OSTimeDlyHMSM、还有带超时的 Pend 函数它们都会最终操作OSTCBDly。看OSTimeDly的实现void OSTimeDly (INT16U ticks) { if (ticks 0) { OS_ENTER_CRITICAL(); if (OSIntNesting 0) { // 不允许在中断里延时 return; } if (OSLockNesting 0) { // 调度被锁也不允许延时 return; } y OSTCBCur-OSTCBPrio 3; OSRdyTbl[y] ~OSMapTbl[OSTCBCur-OSTCBPrio 0x07]; if (OSRdyTbl[y] 0) { OSRdyGrp ~OSMapTbl[y]; } OSTCBCur-OSTCBDly ticks; // 设定延时 OS_EXIT_CRITICAL(); OS_Sched(); // 让出 CPU } }注意三点第一延时前要把自己从就绪表里摘掉否则调度器还是会选中你第二设置OSTCBDly后立刻调用OS_Sched让系统去选择新的最高优先级任务第三如果ticks是0干脆什么都不做。所以OSTimeDly(0)不会让出 CPU它只是浪费一点时间。你想“让出 CPU 但不延时”可以用OSSchedLock配合其他方式或者调用OS_TASK_SW之类但 uC/OS-II 默认没有把这个需求直接做成 API。OSTimeDlyHMSM其实是个“换算函数”把小时、分钟、秒、毫秒换算成 tick 数再调用OSTimeDly。它的计算公式不复杂但有一个坑如果换算出来的 tick 数是0调用OSTimeDly(0)就立刻返回了任务没有延时很多人在这里“觉得 API 不生效”。所以实际使用时要留意OS_TICKS_PER_SEC的配置和你传入的时间是否匹配。比如OS_TICKS_PER_SEC 1000 时OSTimeDlyHMSM(0, 0, 0, 500)换算成 500 tick是有效的如果OS_TICKS_PER_SEC 100同样参数换算成 50 tick也没问题但如果你传一个比一个 tick 周期还短的时间比如10ms 配OS_TICKS_PER_SEC 50每 tick 20ms就会得到0 tick直接返回任务没睡。4. 内核对象信号量、互斥量、消息与事件标志的源码剖析4.1 事件控制块 ECB所有内核对象的“统一基类”uC/OS-II 的内核对象设计可以说是一种极简版的“面向对象”。它定义了一个事件控制块结构体typedef struct os_event { INT8U OSEventType; // 对象类型信号量、互斥量、邮箱、队列 void *OSEventPtr; // 消息指针或队列控制块指针 INT16U OSEventCnt; // 信号量计数值或事件标志组的标志复用 OS_PRIO OSEventGrp; // 等待事件的任务组位图 OS_PRIO OSEventTbl[OS_MAX_EVENTS 1]; // 等待事件的任务就绪表 } OS_EVENT;每个内核对象除了事件标志组用的是OS_FLAG_GRP都共享这个结构。创建信号量、互斥量、邮箱本质都是分配一个OS_EVENT节点然后设置其中的字段调用 Pend 时把当前任务从 CPU 就绪表里摘掉并加入这个OS_EVENT的等待表OSEventTbl[]、OSEventGrp调用 Post 时从等待表里找出最高优先级任务把它恢复到 CPU 就绪表。等待表的操作和就绪表几乎一模一样都是“组位”的位图结构。你如果在读代码时发现OS_EventTaskRdy和OS_Sched里的位操作很相似没看错这就是同一套算法的复用。区别只在于CPU 就绪表是全局唯一的而每个事件控制块都有自己的“局部就绪表”表示谁在等这个事件。这里我建议你用调试器实际看一下OSEventTbl的变化。比如创建两个任务同时 Pend 同一个信号量当两个任务都阻塞后查看这个信号量控制块的OSEventGrp和OSEventTbl你会发现它们记录了这两个任务对应的两个 bit。这时候哪怕你不看任何文档也能猜出 Post 的时候要从这里捞人。4.2 信号量 OSSem计数值与等待表的前后逻辑信号量的核心 API 是OSSemCreate、OSSemPend、OSSemPost、OSSemAccept。前两个很容易理解重点看 Pend/Post 的对称逻辑void OSSemPend (OS_EVENT *pevent, INT16U timeout, INT8U *perr) { OS_ENTER_CRITICAL(); if (pevent-OSEventCnt 0) { pevent-OSEventCnt--; // 有资源直接拿走 OS_EXIT_CRITICAL(); *perr OS_ERR_NONE; return; } // 没资源阻塞当前任务 OSTCBCur-OSTCBStat | OS_STAT_SEM; OSTCBCur-OSTCBDly timeout; // 超时时间可为0表示无限等 OS_EventTaskWait(pevent); // 加入事件等待表 OS_EXIT_CRITICAL(); OS_Sched(); // 让出 CPU // 被唤醒后回来 OS_ENTER_CRITICAL(); if (OSTCBCur-OSTCBStat OS_STAT_SEM) { // 如果标志还在说明是超时唤醒 OS_EventTO(pevent); *perr OS_ERR_TIMEOUT; } else { OSTCBCur-OSTCBEventPtr NULL; *perr OS_ERR_NONE; } OS_EXIT_CRITICAL(); }注意这段代码里“唤醒后”的检查逻辑任务被 Post 唤醒时OS_STAT_SEM位会被清掉所以可以通过这个标志位判断自己到底是拿到了信号量还是超时了。这在实际项目里非常重要——如果只调用 Pend 而不检查perr一旦因为超时醒来你可能会把一个没有实际意义的共享资源当成有效信号导致后面逻辑错乱。再看 PostINT8U OSSemPost (OS_EVENT *pevent) { OS_ENTER_CRITICAL(); if (pevent-OSEventGrp ! 0) { // 有人等着 OS_EventTaskRdy(pevent, (void *)0, OS_STAT_SEM); // 唤醒最高优先级等待任务 OS_EXIT_CRITICAL(); OS_Sched(); return OS_ERR_NONE; } if (pevent-OSEventCnt 65535) { pevent-OSEventCnt; // 没人等计数值加1 OS_EXIT_CRITICAL(); return OS_ERR_NONE; } OS_EXIT_CRITICAL(); return OS_ERR_SEM_OVF; }这个逻辑非常直观有人等就唤醒一个没人等就计数加1。信号量的计数上限是65535因为OSEventCnt是INT16U。你自己实现信号量时也可以学这个套路但要注意计数溢出保护很多简化版信号量在这里偷懒上线后偶发崩溃追查起来特别费劲。OSSemAccept是不阻塞版本的 Pend如果有计数就减1返回“成功”没有计数直接返回“失败”绝不阻塞。它适合在中断里使用或者用在“轮询但不希望任务被挂起”的场景。我在状态机里经常用它来检测某个事件是否发生如果发生就立刻处理没有发生就继续跑状态机不浪费调度周期。4.3 互斥信号量 OSMutex优先级继承怎么用代码实现互斥量和普通信号量最大的区别是它解决了“优先级反转”问题。什么叫优先级反转举一个教科书级的例子任务A优先级高正在等一个互斥量任务C优先级低持有这个互斥量正在执行任务B优先级中等不需要这个互斥量但它就绪了把 CPU 抢走了于是高优先级的 A 反而在等低优先级的 C而 C 还要等中优先级的 B 让出 CPU算下来 A 被 B 间接阻塞了。uC/OS-II 的解法是优先级继承Priority Inheritance当高优先级任务 A 去 Pend 一个已经被低优先级任务 C 持有的互斥量时系统临时把 C 的优先级提升到 A 的优先级。这样 B 再就绪时调度器选中 C 而不是 BC 能赶紧跑完并释放互斥量然后再恢复原来的优先级。用代码看会更清楚。OSMutexPend做了一件事ptcb (OS_TCB *)pevent-OSEventPtr; // 谁持有这个互斥量 if (ptcb-OSTCBPrio prio) { // 持有者优先级更低数值更大 // 保存原始优先级然后提升 ptcb-OSTCBBasePrio ptcb-OSTCBPrio; // 把持有者从原来的就绪位移除 OSRdyTbl[ptcb-OSTCBPrio 3] ~OSMapTbl[ptcb-OSTCBPrio 0x07]; if (OSRdyTbl[ptcb-OSTCBPrio 3] 0) { OSRdyGrp ~OSMapTbl[ptcb-OSTCBPrio 3]; } // 用新的优先级重新放回就绪表 ptcb-OSTCBPrio prio; OSRdyGrp | OSMapTbl[ptcb-OSTCBPrio 3]; OSRdyTbl[ptcb-OSTCBPrio 3] | OSMapTbl[ptcb-OSTCBPrio 0x07]; }释放互斥量时OSMutexPost再把持有者的优先级恢复ptcb-OSTCBPrio ptcb-OSTCBBasePrio; // 把提升后的优先级清掉把原始优先级放到就绪表 OSRdyTbl[ptcb-OSTCBBasePrio 3] | OSMapTbl[ptcb-OSTCBBasePrio 0x07]; OSRdyGrp | OSMapTbl[ptcb-OSTCBBasePrio 3]; OSRdyTbl[prio 3] ~OSMapTbl[prio 0x07];注意恢复优先级时要同时处理“提升后的优先级”在就绪表里的残留。很多移植者在裁剪代码时容易漏掉这两步导致任务醒来之后以错误的优先级运行或者就绪表出现一个“幽灵位”调度器永远选一个不存在的任务。遇到这种情况建议直接查OSRdyTbl和任务的OSTCBPrio是否一致。优先级继承不是万能的。它只能缓解反转不能完全消除。比如持有资源的任务 C 可能因为其他原因阻塞导致继承的优先级被“冻结”。所以业界还有优先级天花板方案但 uC/OS-II 默认用继承因为开销小、实现简单、代码只有几十行。面试时能把这几十行讲清楚已经超过大多数应聘者了。4.4 消息与队列数据的传递靠一个指针消息邮箱OSMbox本质上就是一个“能装一个指针的盒子”。OSMboxPost会把指针存到pevent-OSEventPtr然后把等待在这个邮箱上的最高优先级任务唤醒OSMboxPend则反过来如果邮箱里有消息直接取走指针并清空OSEventPtr没有消息则阻塞直到别的任务 Post 或者超时。核心实现其实不长void *OSMboxPend (OS_EVENT *pevent, INT16U timeout, INT8U *perr) { void *msg; OS_ENTER_CRITICAL(); msg pevent-OSEventPtr; // 尝试直接取消息 if (msg ! (void *)0) { pevent-OSEventPtr (void *)0; // 取走后清空 OS_EXIT_CRITICAL(); *perr OS_ERR_NONE; return (msg); } // 没有消息阻塞任务 OSTCBCur-OSTCBStat | OS_STAT_MBOX; OSTCBCur-OSTCBDly timeout; OS_EventTaskWait(pevent); OS_EXIT_CRITICAL(); OS_Sched(); // 唤醒后取消息 OS_ENTER_CRITICAL(); msg OSTCBCur-OSTCBMsg; if (msg ! (void *)0) { *perr OS_ERR_NONE; } else if (OSTCBCur-OSTCBStat OS_STAT_MBOX) { OS_EventTO(pevent); *perr OS_ERR_TIMEOUT; } else { *perr OS_ERR_NONE; } OS_EXIT_CRITICAL(); return (msg); }消息队列OSQ的实现稍微复杂一点它把OSEventPtr指向一个队列控制块OS_Q里面维护一个环形缓冲区支持先进先出也可以选择后进先出。但无论邮箱还是队列传递的“内容”都是指针不是数据拷贝。这是很多新手容易踩坑的地方你 Post 一个局部变量的地址出去等任务切回来局部变量已经失效了收消息的任务拿到一个悬空指针。正确的做法是传递静态分配的缓冲区地址或者从内存分区OSMemGet申请一块内存用完再释放。4.5 事件标志组位操作带给你的同步自由事件标志组是另一类对象它用独立的OS_FLAG_GRP结构管理。每个 bit 表示一个事件“是否发生”任务可以等“任意一个事件发生”OS_FLAG_CONSUME或 AND/OR 的组合或者“全部事件发生”也可以选择消费掉这些标志置0。OSFlagPend的入参里有wait_type比如OS_FLAG_WAIT_SET_ALL表示等待的所有位都置1才返回OS_FLAG_WAIT_SET_ANY表示其中有任一位置1就返回。它内部维护一个等待链表OSFlagWaitList每个等待节点记录了等待的位掩码和等待类型。事件标志组在某些场景下比信号量更灵活比如“等待多个传感器全部就绪”这种需求用信号量要写很多判断逻辑用事件标志组一行搞定。但要注意事件标志组不能像信号量那样保证互斥访问它只负责事件状态的同步。你把它当成“多条件一次性等待”的开关来用不要拿它当共享资源的锁使。5. 从理论到板子一个三任务协同的完整示例5.1 场景设计与代码结构光看源码容易飘我写一个实际示例把调度和内核对象串起来。假设有三件事任务A优先级5周期性采集温湿度传感器数据放到共享缓冲区任务B优先级10从消息队列接收“传感器数据已更新”的通知然后处理数据任务C优先级15用互斥量保护一个显示屏资源刷屏显示结果。任务之间传递数据用的是一块全局静态缓冲区通过互斥量和消息队列协调。伪代码如下static OS_MUTEX MutexLcd; static OS_MBOX MboxData; void TaskA (void *p_arg) { static INT8U buf[32]; while (1) { // 采集数据填入 buf snprintf((char *)buf, sizeof(buf), T%.1f H%.1f, temp, humi); OSMboxPost(MboxData, (void *)buf); // 通知任务B OSTimeDlyHMSM(0, 0, 0, 200); // 200ms 采集一次 } } void TaskB (void *p_arg) { INT8U *pmsg; INT8U err; while (1) { pmsg (INT8U *)OSMboxPend(MboxData, 0, err); // 等待数据通知 if (err OS_ERR_NONE) { // 处理 pmsg 指向的数据 } } } void TaskC (void *p_arg) { while (1) { OSMutexPend(MutexLcd, 0, err); // 刷新LCD独占屏资源 OSMutexPost(MutexLcd); OSTimeDly(10); } }这个例子里消息队列传递的是TaskA内部的静态缓冲区地址所以TaskA在下一次循环往这个缓冲区写数据之前必须确保TaskB已经读取完。实际操作中我用的是内存分区方案从OSMemGet申请一块内存填数据后把指针传给TaskBTaskB用完后OSMemPut归还。这样更安全也顺便把内存管理模块用起来了。5.2 运行流程与调度顺序推演从OSStart开始假设三个任务都被创建TaskA优先级最高5先运行。采集缓冲区数据Post 消息然后OSTimeDlyHMSM自我阻塞200ms。调度器发现TaskB优先级10就绪切入TaskB。OSMboxPend立刻返回因为有消息。处理数据循环回来继续 Pend此时消息已空TaskB阻塞。调度器选择TaskC优先级15运行。加锁刷屏释放锁OSTimeDly(10)睡10个 tick。没有其他就绪任务系统运行空闲任务。等 tick 中断把TaskA唤醒重复循环。这里面值得琢磨的是如果TaskA采集数据的速度比TaskB处理数据快邮箱会不会爆答案是消息邮箱只有一个指针位TaskB还没取走时TaskA再次 Post 不会产生堆积要么覆盖要么返回错误取决于配置。所以生产环境里如果没有接收方消费Post 函数会失败或直接覆盖。这也是为什么你在设计时要评估“生产速率”和“消费速率”否则要么丢消息要么消息过期。我还建议你在每个任务里加一个执行计数器或者 GPIO 翻转引脚用示波器看每个任务的执行间隔。实测下来你会发现高优先级任务频繁抢占时低优先级任务的周期会变得很不稳定。这正是抢占式调度的代价低优先级任务的执行时间方差变大。如果你的低优先级任务必须稳还是要考虑把它的逻辑拆到高优先级里或者用消息驱动而不是纯周期驱动。6. 常见问题与排查技巧实录6.1 源码级排查实录实际调 RTOS 项目最常见的故障有三类第一类是“任务跑飞或硬件异常”。优先查任务栈大小是否够用OSTaskCreate分配的栈空间不足任务栈溢出会覆盖相邻内存轻则变量被改重则直接进 HardFault。uC/OS-II 自带OS_TaskStkChk可以检测任务栈的高水位我在项目 check 位里每5秒调用一次发现某个任务栈使用率超过85%就打印告警。查过几次后我发现大多是snprintf这类格式化输出用了大栈。解决办法是减少格式化字符串长度或者把大数组移到静态区。第二类是“任务不运行但系统没死”。优先查是不是任务被 Pend 在某个事件上没人 Post或者OSEventTbl里的等待任务没有按期唤醒。我调试时喜欢在OS_Sched里临时加一个OSPrioHighRdy的断点条件表达式当它等于某个值并且持续很久不变化时基本能锁定是谁占着 CPU 不放手。如果是OSLockNesting被某人锁死了调度器永远不会切走重点查谁调了OSLockSched忘记配对。第三类是“偶发数据被踩”。优先级高的任务和优先级低的任务共享一个全局变量但一个写一个读没有用互斥量或关中断保护。裸机时代可能很久才露馅上了 RTOS 之后切换时机变多踩数据概率大增。这一类问题的排查最好的工具是内存断点在共享变量地址上设置硬件数据断点触发时看调用栈是谁在访问。6.2 面试官最爱的几个 RTOS 问题如果你是用这篇内容去准备面试我帮你把几个高频问题串一下。“uC/OS-II 是怎么查找最高优先级任务的”答通过OSRdyGrp和OSRdyTbl两张位图表加上OSUnMapTbl查表O(1) 时间。“任务切换的本质是什么”答保存当前任务上下文寄存器、栈指针、状态到自己的任务栈从OSTCBHighRdy取出最高优先级任务的栈指针恢复它的上下文跳到新任务继续执行。“在中断里能调用OSSemPost吗”答可以。OSSemPost内部会调用OS_Sched但OS_Sched在OSIntNesting 0时不会执行任务切换而是等中断退出时由OSIntExit统一处理。所以你在 ISR 里 Post 信号量是安全的但要意识到实际的任务切换不会立刻发生而是在中断完全退出后才发生。“信号量和互斥量的区别”答语义上信号量侧重“资源数量”或“事件通知”互斥量强调“独占访问”并且互斥量支持优先级继承用来防止优先级反转。“uC/OS-II 支持时间片轮转调度吗”答经典版本本身不支持同优先级分时轮转。它要求每个优先级最多一个任务默认最多64个优先级。如果你需要同优先级多任务轮转就得自己改造调度器或者换别的 RTOS。这个问题经常出现在面试里面试官想考察你是否清楚抢占式调度和分时调度的本质区别。还有一个高频考点是“临界区怎么保护”。uC/OS-II 提供OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()对应OS_CRITICAL_METHOD三种实现方法1是直接开关中断方法2是保存中断状态再关中断退出时恢复方法3是利用 Cortex-M 的PRIMASK读取/写回。在 Cortex-M 上推荐方法3因为它不会因为嵌套关中断导致状态丢失。你写驱动时如果临界区内执行时间太长会影响中断响应所以要尽量短。6.3 读 uC/OS-II 源码的一点体会这6736行代码我读了三遍。第一遍走马观花知道个大概第二遍一行行画图把所有结构体字段和调用关系写满了一张 A3 纸第三遍是自己动手把OS_Sched、OSIntExit、OS_EventTaskRdy这几个关键函数抄到工程里改成打印日志的版本跑在开发板上看实际输出。说实话最痛苦的阶段是第二遍但收获最大的也是第二遍。如果让我给一个“源码阅读路径”建议会是这样先读os_core.c里的OSInit、OSStart、OS_Sched再去读os_task.c里的OSTaskCreate和OSTaskDel然后回头读os_time.c里的OSTimeTick最后再攻内核对象。内核对象里我建议先读信号量因为它最简单其他对象都是在它基础上加字段、加分支。把信号量读透互斥量和邮箱都能顺下来。我见过很多工程师用 RTOS 用了两三年问起来全是 API 怎么调一旦系统出诡异问题就只会加大延时、加vTaskDelay硬扛。其实很多问题只要你对源码里的内核对象原理有概念光看挂起任务列表就能定位。uC/OS-II 虽然老代码风格也不花哨但它把 RTOS 最核心的思想用最小系统完整表达了一遍。读明白这6736行你收获的不只是一个内核的知识而是一整套“并发系统怎么设计”的底层直觉。后面这个系列我打算继续写两篇一篇把 uC/OS-II 在 Cortex-M 上的移植文件和启动汇编完整过一遍另一篇拿一个实际的小项目比如带几个传感器和一个屏幕的采集器把前面所有机制串起来。你有兴趣的话可以先把这篇里的示例代码在自己板子上跑一遍特别是把OSRdyGrp和OSRdyTbl的值在中断里抓出来看看眼见为实。
上一篇文章我把任务管理和内存管理讲完之后好几个读者私信问我你天天说uC/OS-II 只有6736行代码可为什么我一打开os_core.c就头晕这很正常uC/OS-II 的代码风格是“数据结构宏定义决定一切”。你越往后读越会发现那些绕来绕去的数组、掩码、宏最后串起来的调度逻辑简单到让人拍桌子。这一篇我们专门啃整个内核里最硬核的三块任务调度、时间管理还有那堆到处 Pend/Post 的内核对象。我始终觉得uC/OS-II 是所有 RTOS 里最适合拿来“精读”的一个。它不像 Linux 内核那样浩如烟海一套核心源码去掉注释和空行满打满算几千行却能完整实现抢占式多任务、信号量、互斥量、消息队列、事件标志组、内存分区管理这些 RTOS 标配功能。你看懂这6736行再回头看 FreeRTOS、RT-Thread、Zephyr很多概念都是相通的只是实现方式各有取舍。甚至你去面嵌入式岗位面试官问的“优先级反转如何解决”“任务切换谁在做”“tick 中断里发生了什么”答案全在这几千行里面。1. 这一篇我们啃 uC/OS-II 最硬核的部分1.1 先交代一下这个系列走到哪了这个系列的前两篇逻辑是这样的第一篇从main函数出发讲了 uC/OS-II 是怎么从裸机跑起来的包括OSInit、OSTaskCreate、OSStart的启动流程以及第一次任务切换OSStartHighRdy背后做了什么第二篇完整分析了任务控制块 TCB、任务栈、空闲任务、统计任务还有内存分区管理OSMem的实现。如果你前面两篇都看完了现在脑中应该有一个基本画面每个任务有一个 TCB里面保存着任务栈指针、任务状态、优先级、事件等待信息等系统通过一个双向链表把这些 TCB 串起来同时通过就绪表Ready Table标记当前“谁可以跑”。这一篇要干嘛说白了就是把“谁可以跑”这个判断逻辑彻底讲透再把任务之间的通信同步机制全部过一遍。这是 RTOS 的核心价值所在也是面试题最爱出题的区域。读完这一篇你至少应该能回答这几个问题优先级就绪表为什么用“分组查表”的方式找最高优先级任务这比遍历链表快多少OS_Sched和OSIntExit哪个是 ISR 里触发的两者切换路径有何不同信号量 Pend 下去之后任务究竟被塞到了哪里优先级继承是怎么用几行代码实现的tick 中断到底多久触发一次、怎么让延时的任务准点醒来1.2 从整体看6736行代码里藏着什么先说明一下“6736行”这个数字。以 uC/OS-II V2.86 为参考核心源码文件包括os_core.c、os_task.c、os_time.c、os_sem.c、os_mutex.c、os_mbox.c、os_q.c、os_flag.c、os_mem.c以及对应的头文件和可选配置。我把这些文件里的有效代码加起来大约就是 6736 行含注释和空行不同版本数字会有差异。但真正决定系统行为的核心算法可能不到2000行。其余的是各种 API 的封装、参数检查、以及为了兼容不同编译器的宏处理。你把这 6736 行拆开看会发现它其实就干了几件事任务管理创建、删除、挂起、恢复任务初始化任务栈任务切换调度核心维护就绪表找出最高优先级任务完成上下文切换时间管理tick 中断处理任务延时按时唤醒内核对象事件控制块ECB作为一个“统一基类”然后在这之上派生信号量、互斥量、消息邮箱、消息队列、事件标志组内存管理固定大小内存块的分配与释放。所以读源码的正确姿势不是一行行从头啃到尾而是先抓住“调度”这条主脑再看“内核对象”这棵从主脑分出去的枝干。这篇就按这个顺序来。2. 任务调度那两张位图表是如何用空间换时间的2.1 就绪表的数据结构与映射逻辑uC/OS-II 查找最高优先级任务不是遍历任务链表而是靠两张表OSRdyGrp和OSRdyTbl[]。很多新手第一次看到这两张表会被吓到其实它的设计思路特别朴素。假设最大支持64个任务优先级0最高63最低把优先级 0~63 拆成“组号”和“组内序号”两部分#define OS_RDY_TBL_SIZE ( ( OS_LOWEST_PRIO ) / 8 1 ) // 默认 8 OS_PRIO OSRdyGrp; // 就绪组1字节每一位对应一组 OS_PRIO OSRdyTbl[OS_RDY_TBL_SIZE]; // 就绪表8字节映射关系是这样的// 优先级 prio 对应的组号和组内位 prio 3 // 等价于 prio / 8得到 y也就是组号 prio 0x07 // 等价于 prio % 8得到 x也就是组内第几位 // 把某优先级置为就绪 OSRdyGrp | OSMapTbl[prio 3]; OSRdyTbl[prio 3] | OSMapTbl[prio 0x07]; // 把某优先级清除就绪 if ((OSRdyTbl[prio 3] ~OSMapTbl[prio 0x07]) 0) { OSRdyGrp ~OSMapTbl[prio 3]; }OSMapTbl是一个查表用的常量数组OSMapTbl[0]0x01, OSMapTbl[1]0x02, ..., OSMapTbl[7]0x80。它的作用就是把“逻辑上的第几位”翻译成“二进制里的 bit 位置”。为什么要这么设计呢你想如果不用分组查表要找到当前最高优先级任务常规思路是写一个循环从优先级0扫到63看到哪个位是1就选谁。最坏情况要循环64次平均也要32次。这在中断里做一次还行但调度器随时可能被调用时间是不确定的。RTOS 要求的是“确定性”最好每条路径的执行时间都固定。uC/OS-II 的做法是再加一张表OSUnMapTbl[256]这张表有256个元素记录“一个字节里最低的置1位是第几位”。怎么用呢y OSUnMapTbl[OSRdyGrp]; // 找到组号 y也就是最高优先级所在组 x OSUnMapTbl[OSRdyTbl[y]]; // 在这个组里找到最低置1位 x prio (y 3) x; // 合成最终的优先级整个查找过程就是三次数组下标访问加一次移位没有任何循环时间完全确定。这就是典型的“用空间换时间”。如果你以后看到别的 RTOS 用__clzCount Leading Zeros或者硬件指令做类似事情本质上都是在干同一件事——把“找最高位”这个操作加速到 O(1)。我建议你把OSUnMapTbl的生成逻辑自己写一遍比如遍历每个字节值看最低置1位在哪然后对照源码里那张表验证。亲自推导过之后你会彻底忘不掉这个算法。2.2 调度器 OS_Sched一次完整调度的源码级走读调度器有两个入口任务级调度OS_Sched和中断级调度OSIntExit。先看任务级调度。void OS_Sched (void) { OS_ENTER_CRITICAL(); if (OSIntNesting 0) { // 不在中断里才允许任务调度 if (OSLockNesting 0) { // 调度器没被锁 OSPrioHighRdy OSUnMapTbl[OSRdyGrp]; // 找组号 if (OSPrioHighRdy ! OSPrioCur) { // 最高优先级不是当前任务 OSTCBHighRdy OSTCBPrioTbl[OSPrioHighRdy]; OSCtxSwCtr; OS_TASK_SW(); // 触发 PendSV/软中断做上下文切换 } } } OS_EXIT_CRITICAL(); }这段代码短到让人怀疑这是不是“内核核心”。注意它做了三件关键的事第一判断是否在中断里。如果OSIntNesting大于0说明当前是在 ISR 里调用调度的这时不能直接做任务切换要等中断退出时统一处理。为什么因为中断现场的寄存器还没有保存完整如果你在这里切换走回来后 ISR 怎么继续跑所以在中断里只标记不切换。第二判断调度器有没有被锁。OSLockNesting是调度锁计数器谁调用了OSLockSched它加1暂时禁止任务调度OSUnlockSched再减回来。这跟关中断OS_ENTER_CRITICAL是两码事。关中断是连 ISR 都不让执行调度锁只是不让任务切换中断照常响应。有经验的开发者会在OSLockSched之后尽量减少临界区时间因为它会拖慢实时性。第三调用宏OS_TASK_SW()。这个宏通常在os_cpu.h里被定义为一个软中断或者 PendSV 异常。在 Cortex-M3 上就是触发 PendSV然后由OSCtxSw汇编代码完成真正的寄存器压栈、任务栈切换、出栈恢复。你可能要问了OS_TASK_SW只是触发了个异常真正的切换在异常处理函数里做为什么不直接写个 C 函数切因为上下文切换必须要操作 CPU 寄存器还要保证在切换瞬间不被打断C 语言表达不了“把当前 CPU 寄存器全部压到任务的栈上”这个动作必须用汇编。这就是每个 RTOS 都要有os_cpu_a.asm这类文件的原因。2.3 中断级调度 OSIntExit 与切换细节中断里的调度逻辑长这样void OSIntExit (void) { OS_ENTER_CRITICAL(); if (OSIntNesting 0) { // 中断嵌套计数减1 OSIntNesting--; } if (OSIntNesting 0) { // 退到最外层中断才处理 if (OSLockNesting 0) { OSPrioHighRdy OSUnMapTbl[OSRdyGrp]; if (OSPrioHighRdy ! OSPrioCur) { OSTCBHighRdy OSTCBPrioTbl[OSPrioHighRdy]; OSCtxSwCtr; OSIntCtxSw(); // 中断级上下文切换 } } } OS_EXIT_CRITICAL(); }这段代码和OS_Sched长得非常像但它不是直接调用OS_TASK_SW()而是调用OSIntCtxSw()。为什么因为中断退出时栈上的现场和普通任务切换时的现场不一样。普通任务切换时任务的上下文完整保存在自己的栈里但中断退出时CPU 已经自动压了一部分寄存器ISR 里可能还手动压了一部分栈指针的位置是乱的。OSIntCtxSw的汇编代码会先做栈指针修正跳过那些不属于“任务上下文”的部分然后再模拟一次任务切换丢掉不用的中断帧。在 Cortex-M 上OSIntCtxSw的做法通常是先把OSTCBCur指向的新任务栈指针装载到 PSP然后返回紧接着PendSV_Handler被触发或直接使用PendSV但技巧在于不要让 PendSV 压栈因为中断返回时使用的本来就是新任务的“中断帧”。这一块细节特别多也是移植时最容易出 bug 的地方。我给一个实际排查的经验如果任务切换后跑飞优先检查两个地方。一个是OSIntCtxSw处的栈指针调整是否正确另一个是中断发生时是否用了错误的工作模式比如在 MSP 和 PSP 之间切换时没有正确设置。这两个坑我当时移植到一款国产 M0 核 MCU 上时整整调了一周最后加了调试打印才定位到是 MSP/PSP 切换时机不对。3. 时间管理tick 是如何让任务“睡到点就醒”的3.1 OSTimeTick 与延时链表的闭环先问一个问题任务调用OSTimeDly(50)之后它是怎么知道自己睡了50个 tick 的答案不是它自己定闹钟而是系统有一个周期性中断——tick 中断——每个 tick 都去检查所有正在睡眠的任务看谁的延时时间到了。这个周期性中断对应的入口是OSTimeTickvoid OSTimeTick (void) { OS_TCB *ptcb; OS_ENTER_CRITICAL(); ptcb OSTCBList; // 从任务链表头开始 while (ptcb ! (OS_TCB *)0) { // 遍历所有任务 if (ptcb-OSTCBDly ! 0) { // 这个任务有延时或超时等待 ptcb-OSTCBDly--; if (ptcb-OSTCBDly 0) { // 延时结束 if ((ptcb-OSTCBStat OS_STAT_SUSPEND) OS_STAT_RDY) { OSRdyGrp | OSMapTbl[ptcb-OSTCBPrio 3]; OSRdyTbl[ptcb-OSTCBPrio 3] | OSMapTbl[ptcb-OSTCBPrio 0x07]; } else { ptcb-OSTCBDly 1; // 任务被挂起不能立即就绪 } } } ptcb ptcb-OSTCBNext; } OS_EXIT_CRITICAL(); }看到了吧核心逻辑就是遍历任务链表把所有OSTCBDly大于0的任务减1减到0了就把任务恢复到就绪表。这里有个非常重要的细节如果任务不是因为延时到点而是因为挂起OS_STAT_SUSPEND而不在就绪态那即使OSTCBDly减到0也不能让它就绪所以代码里做了一个状态判断并且把OSTCBDly强制设为1防止它反复进入这个分支。这是我当初读源码时最容易忽略的一行却直接决定挂起任务的正确性。OSTimeTick是在中断里调用的。所以哪怕任务正在跑tick 中断也会“挤”进来。这其实体现了抢占式内核的基本特征时间由中断驱动任务被打断是常态切换由调度器保证现场完整。你如果把OSTimeTick里的打印打开会发现它在高优先级任务运行期间也会触发完全是“无感”的。3.2 OSTimeDly 与 OSTimeDlyHMSM 的底层实现任务延时 API 有好几个OSTimeDly、OSTimeDlyHMSM、还有带超时的 Pend 函数它们都会最终操作OSTCBDly。看OSTimeDly的实现void OSTimeDly (INT16U ticks) { if (ticks 0) { OS_ENTER_CRITICAL(); if (OSIntNesting 0) { // 不允许在中断里延时 return; } if (OSLockNesting 0) { // 调度被锁也不允许延时 return; } y OSTCBCur-OSTCBPrio 3; OSRdyTbl[y] ~OSMapTbl[OSTCBCur-OSTCBPrio 0x07]; if (OSRdyTbl[y] 0) { OSRdyGrp ~OSMapTbl[y]; } OSTCBCur-OSTCBDly ticks; // 设定延时 OS_EXIT_CRITICAL(); OS_Sched(); // 让出 CPU } }注意三点第一延时前要把自己从就绪表里摘掉否则调度器还是会选中你第二设置OSTCBDly后立刻调用OS_Sched让系统去选择新的最高优先级任务第三如果ticks是0干脆什么都不做。所以OSTimeDly(0)不会让出 CPU它只是浪费一点时间。你想“让出 CPU 但不延时”可以用OSSchedLock配合其他方式或者调用OS_TASK_SW之类但 uC/OS-II 默认没有把这个需求直接做成 API。OSTimeDlyHMSM其实是个“换算函数”把小时、分钟、秒、毫秒换算成 tick 数再调用OSTimeDly。它的计算公式不复杂但有一个坑如果换算出来的 tick 数是0调用OSTimeDly(0)就立刻返回了任务没有延时很多人在这里“觉得 API 不生效”。所以实际使用时要留意OS_TICKS_PER_SEC的配置和你传入的时间是否匹配。比如OS_TICKS_PER_SEC 1000 时OSTimeDlyHMSM(0, 0, 0, 500)换算成 500 tick是有效的如果OS_TICKS_PER_SEC 100同样参数换算成 50 tick也没问题但如果你传一个比一个 tick 周期还短的时间比如10ms 配OS_TICKS_PER_SEC 50每 tick 20ms就会得到0 tick直接返回任务没睡。4. 内核对象信号量、互斥量、消息与事件标志的源码剖析4.1 事件控制块 ECB所有内核对象的“统一基类”uC/OS-II 的内核对象设计可以说是一种极简版的“面向对象”。它定义了一个事件控制块结构体typedef struct os_event { INT8U OSEventType; // 对象类型信号量、互斥量、邮箱、队列 void *OSEventPtr; // 消息指针或队列控制块指针 INT16U OSEventCnt; // 信号量计数值或事件标志组的标志复用 OS_PRIO OSEventGrp; // 等待事件的任务组位图 OS_PRIO OSEventTbl[OS_MAX_EVENTS 1]; // 等待事件的任务就绪表 } OS_EVENT;每个内核对象除了事件标志组用的是OS_FLAG_GRP都共享这个结构。创建信号量、互斥量、邮箱本质都是分配一个OS_EVENT节点然后设置其中的字段调用 Pend 时把当前任务从 CPU 就绪表里摘掉并加入这个OS_EVENT的等待表OSEventTbl[]、OSEventGrp调用 Post 时从等待表里找出最高优先级任务把它恢复到 CPU 就绪表。等待表的操作和就绪表几乎一模一样都是“组位”的位图结构。你如果在读代码时发现OS_EventTaskRdy和OS_Sched里的位操作很相似没看错这就是同一套算法的复用。区别只在于CPU 就绪表是全局唯一的而每个事件控制块都有自己的“局部就绪表”表示谁在等这个事件。这里我建议你用调试器实际看一下OSEventTbl的变化。比如创建两个任务同时 Pend 同一个信号量当两个任务都阻塞后查看这个信号量控制块的OSEventGrp和OSEventTbl你会发现它们记录了这两个任务对应的两个 bit。这时候哪怕你不看任何文档也能猜出 Post 的时候要从这里捞人。4.2 信号量 OSSem计数值与等待表的前后逻辑信号量的核心 API 是OSSemCreate、OSSemPend、OSSemPost、OSSemAccept。前两个很容易理解重点看 Pend/Post 的对称逻辑void OSSemPend (OS_EVENT *pevent, INT16U timeout, INT8U *perr) { OS_ENTER_CRITICAL(); if (pevent-OSEventCnt 0) { pevent-OSEventCnt--; // 有资源直接拿走 OS_EXIT_CRITICAL(); *perr OS_ERR_NONE; return; } // 没资源阻塞当前任务 OSTCBCur-OSTCBStat | OS_STAT_SEM; OSTCBCur-OSTCBDly timeout; // 超时时间可为0表示无限等 OS_EventTaskWait(pevent); // 加入事件等待表 OS_EXIT_CRITICAL(); OS_Sched(); // 让出 CPU // 被唤醒后回来 OS_ENTER_CRITICAL(); if (OSTCBCur-OSTCBStat OS_STAT_SEM) { // 如果标志还在说明是超时唤醒 OS_EventTO(pevent); *perr OS_ERR_TIMEOUT; } else { OSTCBCur-OSTCBEventPtr NULL; *perr OS_ERR_NONE; } OS_EXIT_CRITICAL(); }注意这段代码里“唤醒后”的检查逻辑任务被 Post 唤醒时OS_STAT_SEM位会被清掉所以可以通过这个标志位判断自己到底是拿到了信号量还是超时了。这在实际项目里非常重要——如果只调用 Pend 而不检查perr一旦因为超时醒来你可能会把一个没有实际意义的共享资源当成有效信号导致后面逻辑错乱。再看 PostINT8U OSSemPost (OS_EVENT *pevent) { OS_ENTER_CRITICAL(); if (pevent-OSEventGrp ! 0) { // 有人等着 OS_EventTaskRdy(pevent, (void *)0, OS_STAT_SEM); // 唤醒最高优先级等待任务 OS_EXIT_CRITICAL(); OS_Sched(); return OS_ERR_NONE; } if (pevent-OSEventCnt 65535) { pevent-OSEventCnt; // 没人等计数值加1 OS_EXIT_CRITICAL(); return OS_ERR_NONE; } OS_EXIT_CRITICAL(); return OS_ERR_SEM_OVF; }这个逻辑非常直观有人等就唤醒一个没人等就计数加1。信号量的计数上限是65535因为OSEventCnt是INT16U。你自己实现信号量时也可以学这个套路但要注意计数溢出保护很多简化版信号量在这里偷懒上线后偶发崩溃追查起来特别费劲。OSSemAccept是不阻塞版本的 Pend如果有计数就减1返回“成功”没有计数直接返回“失败”绝不阻塞。它适合在中断里使用或者用在“轮询但不希望任务被挂起”的场景。我在状态机里经常用它来检测某个事件是否发生如果发生就立刻处理没有发生就继续跑状态机不浪费调度周期。4.3 互斥信号量 OSMutex优先级继承怎么用代码实现互斥量和普通信号量最大的区别是它解决了“优先级反转”问题。什么叫优先级反转举一个教科书级的例子任务A优先级高正在等一个互斥量任务C优先级低持有这个互斥量正在执行任务B优先级中等不需要这个互斥量但它就绪了把 CPU 抢走了于是高优先级的 A 反而在等低优先级的 C而 C 还要等中优先级的 B 让出 CPU算下来 A 被 B 间接阻塞了。uC/OS-II 的解法是优先级继承Priority Inheritance当高优先级任务 A 去 Pend 一个已经被低优先级任务 C 持有的互斥量时系统临时把 C 的优先级提升到 A 的优先级。这样 B 再就绪时调度器选中 C 而不是 BC 能赶紧跑完并释放互斥量然后再恢复原来的优先级。用代码看会更清楚。OSMutexPend做了一件事ptcb (OS_TCB *)pevent-OSEventPtr; // 谁持有这个互斥量 if (ptcb-OSTCBPrio prio) { // 持有者优先级更低数值更大 // 保存原始优先级然后提升 ptcb-OSTCBBasePrio ptcb-OSTCBPrio; // 把持有者从原来的就绪位移除 OSRdyTbl[ptcb-OSTCBPrio 3] ~OSMapTbl[ptcb-OSTCBPrio 0x07]; if (OSRdyTbl[ptcb-OSTCBPrio 3] 0) { OSRdyGrp ~OSMapTbl[ptcb-OSTCBPrio 3]; } // 用新的优先级重新放回就绪表 ptcb-OSTCBPrio prio; OSRdyGrp | OSMapTbl[ptcb-OSTCBPrio 3]; OSRdyTbl[ptcb-OSTCBPrio 3] | OSMapTbl[ptcb-OSTCBPrio 0x07]; }释放互斥量时OSMutexPost再把持有者的优先级恢复ptcb-OSTCBPrio ptcb-OSTCBBasePrio; // 把提升后的优先级清掉把原始优先级放到就绪表 OSRdyTbl[ptcb-OSTCBBasePrio 3] | OSMapTbl[ptcb-OSTCBBasePrio 0x07]; OSRdyGrp | OSMapTbl[ptcb-OSTCBBasePrio 3]; OSRdyTbl[prio 3] ~OSMapTbl[prio 0x07];注意恢复优先级时要同时处理“提升后的优先级”在就绪表里的残留。很多移植者在裁剪代码时容易漏掉这两步导致任务醒来之后以错误的优先级运行或者就绪表出现一个“幽灵位”调度器永远选一个不存在的任务。遇到这种情况建议直接查OSRdyTbl和任务的OSTCBPrio是否一致。优先级继承不是万能的。它只能缓解反转不能完全消除。比如持有资源的任务 C 可能因为其他原因阻塞导致继承的优先级被“冻结”。所以业界还有优先级天花板方案但 uC/OS-II 默认用继承因为开销小、实现简单、代码只有几十行。面试时能把这几十行讲清楚已经超过大多数应聘者了。4.4 消息与队列数据的传递靠一个指针消息邮箱OSMbox本质上就是一个“能装一个指针的盒子”。OSMboxPost会把指针存到pevent-OSEventPtr然后把等待在这个邮箱上的最高优先级任务唤醒OSMboxPend则反过来如果邮箱里有消息直接取走指针并清空OSEventPtr没有消息则阻塞直到别的任务 Post 或者超时。核心实现其实不长void *OSMboxPend (OS_EVENT *pevent, INT16U timeout, INT8U *perr) { void *msg; OS_ENTER_CRITICAL(); msg pevent-OSEventPtr; // 尝试直接取消息 if (msg ! (void *)0) { pevent-OSEventPtr (void *)0; // 取走后清空 OS_EXIT_CRITICAL(); *perr OS_ERR_NONE; return (msg); } // 没有消息阻塞任务 OSTCBCur-OSTCBStat | OS_STAT_MBOX; OSTCBCur-OSTCBDly timeout; OS_EventTaskWait(pevent); OS_EXIT_CRITICAL(); OS_Sched(); // 唤醒后取消息 OS_ENTER_CRITICAL(); msg OSTCBCur-OSTCBMsg; if (msg ! (void *)0) { *perr OS_ERR_NONE; } else if (OSTCBCur-OSTCBStat OS_STAT_MBOX) { OS_EventTO(pevent); *perr OS_ERR_TIMEOUT; } else { *perr OS_ERR_NONE; } OS_EXIT_CRITICAL(); return (msg); }消息队列OSQ的实现稍微复杂一点它把OSEventPtr指向一个队列控制块OS_Q里面维护一个环形缓冲区支持先进先出也可以选择后进先出。但无论邮箱还是队列传递的“内容”都是指针不是数据拷贝。这是很多新手容易踩坑的地方你 Post 一个局部变量的地址出去等任务切回来局部变量已经失效了收消息的任务拿到一个悬空指针。正确的做法是传递静态分配的缓冲区地址或者从内存分区OSMemGet申请一块内存用完再释放。4.5 事件标志组位操作带给你的同步自由事件标志组是另一类对象它用独立的OS_FLAG_GRP结构管理。每个 bit 表示一个事件“是否发生”任务可以等“任意一个事件发生”OS_FLAG_CONSUME或 AND/OR 的组合或者“全部事件发生”也可以选择消费掉这些标志置0。OSFlagPend的入参里有wait_type比如OS_FLAG_WAIT_SET_ALL表示等待的所有位都置1才返回OS_FLAG_WAIT_SET_ANY表示其中有任一位置1就返回。它内部维护一个等待链表OSFlagWaitList每个等待节点记录了等待的位掩码和等待类型。事件标志组在某些场景下比信号量更灵活比如“等待多个传感器全部就绪”这种需求用信号量要写很多判断逻辑用事件标志组一行搞定。但要注意事件标志组不能像信号量那样保证互斥访问它只负责事件状态的同步。你把它当成“多条件一次性等待”的开关来用不要拿它当共享资源的锁使。5. 从理论到板子一个三任务协同的完整示例5.1 场景设计与代码结构光看源码容易飘我写一个实际示例把调度和内核对象串起来。假设有三件事任务A优先级5周期性采集温湿度传感器数据放到共享缓冲区任务B优先级10从消息队列接收“传感器数据已更新”的通知然后处理数据任务C优先级15用互斥量保护一个显示屏资源刷屏显示结果。任务之间传递数据用的是一块全局静态缓冲区通过互斥量和消息队列协调。伪代码如下static OS_MUTEX MutexLcd; static OS_MBOX MboxData; void TaskA (void *p_arg) { static INT8U buf[32]; while (1) { // 采集数据填入 buf snprintf((char *)buf, sizeof(buf), T%.1f H%.1f, temp, humi); OSMboxPost(MboxData, (void *)buf); // 通知任务B OSTimeDlyHMSM(0, 0, 0, 200); // 200ms 采集一次 } } void TaskB (void *p_arg) { INT8U *pmsg; INT8U err; while (1) { pmsg (INT8U *)OSMboxPend(MboxData, 0, err); // 等待数据通知 if (err OS_ERR_NONE) { // 处理 pmsg 指向的数据 } } } void TaskC (void *p_arg) { while (1) { OSMutexPend(MutexLcd, 0, err); // 刷新LCD独占屏资源 OSMutexPost(MutexLcd); OSTimeDly(10); } }这个例子里消息队列传递的是TaskA内部的静态缓冲区地址所以TaskA在下一次循环往这个缓冲区写数据之前必须确保TaskB已经读取完。实际操作中我用的是内存分区方案从OSMemGet申请一块内存填数据后把指针传给TaskBTaskB用完后OSMemPut归还。这样更安全也顺便把内存管理模块用起来了。5.2 运行流程与调度顺序推演从OSStart开始假设三个任务都被创建TaskA优先级最高5先运行。采集缓冲区数据Post 消息然后OSTimeDlyHMSM自我阻塞200ms。调度器发现TaskB优先级10就绪切入TaskB。OSMboxPend立刻返回因为有消息。处理数据循环回来继续 Pend此时消息已空TaskB阻塞。调度器选择TaskC优先级15运行。加锁刷屏释放锁OSTimeDly(10)睡10个 tick。没有其他就绪任务系统运行空闲任务。等 tick 中断把TaskA唤醒重复循环。这里面值得琢磨的是如果TaskA采集数据的速度比TaskB处理数据快邮箱会不会爆答案是消息邮箱只有一个指针位TaskB还没取走时TaskA再次 Post 不会产生堆积要么覆盖要么返回错误取决于配置。所以生产环境里如果没有接收方消费Post 函数会失败或直接覆盖。这也是为什么你在设计时要评估“生产速率”和“消费速率”否则要么丢消息要么消息过期。我还建议你在每个任务里加一个执行计数器或者 GPIO 翻转引脚用示波器看每个任务的执行间隔。实测下来你会发现高优先级任务频繁抢占时低优先级任务的周期会变得很不稳定。这正是抢占式调度的代价低优先级任务的执行时间方差变大。如果你的低优先级任务必须稳还是要考虑把它的逻辑拆到高优先级里或者用消息驱动而不是纯周期驱动。6. 常见问题与排查技巧实录6.1 源码级排查实录实际调 RTOS 项目最常见的故障有三类第一类是“任务跑飞或硬件异常”。优先查任务栈大小是否够用OSTaskCreate分配的栈空间不足任务栈溢出会覆盖相邻内存轻则变量被改重则直接进 HardFault。uC/OS-II 自带OS_TaskStkChk可以检测任务栈的高水位我在项目 check 位里每5秒调用一次发现某个任务栈使用率超过85%就打印告警。查过几次后我发现大多是snprintf这类格式化输出用了大栈。解决办法是减少格式化字符串长度或者把大数组移到静态区。第二类是“任务不运行但系统没死”。优先查是不是任务被 Pend 在某个事件上没人 Post或者OSEventTbl里的等待任务没有按期唤醒。我调试时喜欢在OS_Sched里临时加一个OSPrioHighRdy的断点条件表达式当它等于某个值并且持续很久不变化时基本能锁定是谁占着 CPU 不放手。如果是OSLockNesting被某人锁死了调度器永远不会切走重点查谁调了OSLockSched忘记配对。第三类是“偶发数据被踩”。优先级高的任务和优先级低的任务共享一个全局变量但一个写一个读没有用互斥量或关中断保护。裸机时代可能很久才露馅上了 RTOS 之后切换时机变多踩数据概率大增。这一类问题的排查最好的工具是内存断点在共享变量地址上设置硬件数据断点触发时看调用栈是谁在访问。6.2 面试官最爱的几个 RTOS 问题如果你是用这篇内容去准备面试我帮你把几个高频问题串一下。“uC/OS-II 是怎么查找最高优先级任务的”答通过OSRdyGrp和OSRdyTbl两张位图表加上OSUnMapTbl查表O(1) 时间。“任务切换的本质是什么”答保存当前任务上下文寄存器、栈指针、状态到自己的任务栈从OSTCBHighRdy取出最高优先级任务的栈指针恢复它的上下文跳到新任务继续执行。“在中断里能调用OSSemPost吗”答可以。OSSemPost内部会调用OS_Sched但OS_Sched在OSIntNesting 0时不会执行任务切换而是等中断退出时由OSIntExit统一处理。所以你在 ISR 里 Post 信号量是安全的但要意识到实际的任务切换不会立刻发生而是在中断完全退出后才发生。“信号量和互斥量的区别”答语义上信号量侧重“资源数量”或“事件通知”互斥量强调“独占访问”并且互斥量支持优先级继承用来防止优先级反转。“uC/OS-II 支持时间片轮转调度吗”答经典版本本身不支持同优先级分时轮转。它要求每个优先级最多一个任务默认最多64个优先级。如果你需要同优先级多任务轮转就得自己改造调度器或者换别的 RTOS。这个问题经常出现在面试里面试官想考察你是否清楚抢占式调度和分时调度的本质区别。还有一个高频考点是“临界区怎么保护”。uC/OS-II 提供OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()对应OS_CRITICAL_METHOD三种实现方法1是直接开关中断方法2是保存中断状态再关中断退出时恢复方法3是利用 Cortex-M 的PRIMASK读取/写回。在 Cortex-M 上推荐方法3因为它不会因为嵌套关中断导致状态丢失。你写驱动时如果临界区内执行时间太长会影响中断响应所以要尽量短。6.3 读 uC/OS-II 源码的一点体会这6736行代码我读了三遍。第一遍走马观花知道个大概第二遍一行行画图把所有结构体字段和调用关系写满了一张 A3 纸第三遍是自己动手把OS_Sched、OSIntExit、OS_EventTaskRdy这几个关键函数抄到工程里改成打印日志的版本跑在开发板上看实际输出。说实话最痛苦的阶段是第二遍但收获最大的也是第二遍。如果让我给一个“源码阅读路径”建议会是这样先读os_core.c里的OSInit、OSStart、OS_Sched再去读os_task.c里的OSTaskCreate和OSTaskDel然后回头读os_time.c里的OSTimeTick最后再攻内核对象。内核对象里我建议先读信号量因为它最简单其他对象都是在它基础上加字段、加分支。把信号量读透互斥量和邮箱都能顺下来。我见过很多工程师用 RTOS 用了两三年问起来全是 API 怎么调一旦系统出诡异问题就只会加大延时、加vTaskDelay硬扛。其实很多问题只要你对源码里的内核对象原理有概念光看挂起任务列表就能定位。uC/OS-II 虽然老代码风格也不花哨但它把 RTOS 最核心的思想用最小系统完整表达了一遍。读明白这6736行你收获的不只是一个内核的知识而是一整套“并发系统怎么设计”的底层直觉。后面这个系列我打算继续写两篇一篇把 uC/OS-II 在 Cortex-M 上的移植文件和启动汇编完整过一遍另一篇拿一个实际的小项目比如带几个传感器和一个屏幕的采集器把前面所有机制串起来。你有兴趣的话可以先把这篇里的示例代码在自己板子上跑一遍特别是把OSRdyGrp和OSRdyTbl的值在中断里抓出来看看眼见为实。
