简介：MicroC/OS-II 在 80C196 微控制器上的移植研究文档，面向嵌入式开发人员与实时操作系统学习者，聚焦资源受限环境下抢占式多任务内核的代码适配、裁剪与性能优化。文档以单篇完整论文形式交付，压缩包内共 1 个 doc 文件，大小约 45KB，结构紧凑，便于嵌入式开发者查阅与归档。已有 283 人学习，适合需要理解 RTOS 移植流程与工程取舍的读者参考。内容围绕 TASKING C196 编译器环境展开，涵盖 OS_CPU.H、OS_CFG.H 等硬件相关代码改写，片内 220 字节与外部 3.5KB 存储条件下的任务表、任务控制块裁剪，以及 250μs 时钟节拍下弃用 OSTimeDly、合并中断退出与任务切换等时间资源优化；同时说明 6 个任务的优先级与堆栈分配、临界段开关中断处理等实现细节。可为老系统在不改变硬件设计的前提下升级功能、提升实时性与可靠性提供具体参考，尤其适合需要评估 RTOS 在资源受限 MCU 上落地方式的工程场景。
1. 从「无限循环＋中断」到抢占式内核：为什么任务一多，顺序执行的余量就不够用了
给一颗片内只有 220 字节 RAM、外部再扩 3.5K 的单片机塞进 MicroC/OS-II 这样的抢占式多任务实时内核，听上去像把衣柜搬进抽屉。可真正做过 MicroC/OS-II 移植的人会发现，难的不是让内核跑起来，而是把它削到刚好装得下，还能留出 250μs 的节拍余量。这套内核标称可移植、可固化、可裁剪，但在资源紧张的 80C196 上，「可裁剪」三个字会变成一道算术题：每砍掉一个变量，都得先确认没有任何一条路径会读到它。传统「无限循环＋中断服务」在任务少时确实够用，可一旦某个循环体变长，最坏响应时间就不再可控——这正是抢占式内核要解决的问题，也是移植真正要付出的代价。
2. 就绪表与优先级：内核怎么在常数时间内决定「下一个跑谁」
调度器的本质是一次「选最大」的操作：在所有就绪任务里挑出优先级最高的那个。朴素做法是维护一条就绪链表，每次调度从头扫一遍，复杂度 O(n)。任务少的时候这没什么，但当调度发生在每一次节拍中断、每一次信号量释放、每一次消息投递之后，这个 O(n) 就成了压在时间预算上的固定成本。MicroC/OS-II 把它压成了 O(1)，靠的是位图加查表这套组合拳。
2.1 OSRdyTbl 与 OSUnMapTbl：一张位图换掉一次遍历
内核为每个优先级准备一个二进制位，任务就绪就把对应位置 1，任务挂起或延时到期就把位清 0。原始版本里这是两级结构：OSRdyGrp记录哪几个「组」里有就绪任务，OSRdyTbl[]是每组的 8 位明细，两级各查一次表，最多支持 64 个优先级。
真正让它变成 O(1) 的是OSUnMapTbl这张 256 字节的查找表：给定任意一个字节，直接返回其中最低的那个置位位的下标。因为 MicroC/OS-II 里优先级数值越小优先级越高，所以「最低置位位」恰好就是「最高优先级任务」。
/* OSUnMapTbl 的生成逻辑：对 0~255 每个值，返回其最低置位位的下标 */ for (i = 0; i < 256; i++) { OSUnMapTbl[i] = 0xFF; /* 默认值，实际实现里 0 号项单独处理 */ for (j = 0; j < 8; j++) { if (i & (1 << j)) { /* 从低位往高位找第一个 1 */ OSUnMapTbl[i] = j; /* 优先级数值小的先被选中 */ break; } } } /* 调度时只需一次移位加一次查表 */ OSPrioHighRdy = OSUnMapTbl[OSRdyTbl];这段逻辑的价值在于：无论当前有多少个任务就绪，选出最高优先级任务永远只需要「读一个字节、查一次表、取一个下标」这三步，指令周期数是固定的。参数OSRdyTbl是 8 位就绪位图，OSUnMapTbl是 256 字节的常量表——注意它占的是 ROM 不是 RAM，在 3.5K 的程序空间里这 256 字节是要算进预算的。如果连 ROM 都紧张，常见的替代做法是把查表换成一个 8 次迭代的小循环，代价是每次调度多几十个指令周期。这就是典型的空间换时间抉择，没有标准答案，只有你的资源账本。
2.2 OS_TCB 与优先级表：任务的身份和它的栈指针放在哪
每个任务对应一个任务控制块OS_TCB，里面最关键的三个字段是：栈顶指针OSTCBStkPtr、优先级OSTCBPrio、延时计数OSTCBDly。切换任务时，内核做的事情朴素得惊人——把当前 CPU 的栈指针存进旧任务的OSTCBStkPtr，再从新任务的OSTCBStkPtr里取出栈指针装回 CPU。所谓「任务切换」，在硬件层面就是换了一个栈。
为了让「按优先级找 TCB」也是 O(1)，内核还维护一张OSTCBPrioTbl[]，以下标就是优先级的方式直接索引 TCB 指针。这条设计把「优先级 → 任务」的映射变成了数组寻址，不需要任何搜索。代价是这张表的大小等于优先级总数，所以在 80C196 上它被裁到只剩 8 项。
原始OS_TCB里还有OSTCBY、OSTCBBitY、OSTCBBitX三个字段，它们是配合OSRdyGrp做两级位图运算时预先算好的掩码，纯粹是为了省几条移位指令。一旦就绪表被压成单个字节、OSRdyGrp被彻底删掉，这三个字段就永远不会被读到，留在结构体里就是白占 RAM。把它们删掉是移植中最没有争议的一刀。
2.3 调度时机：任务就绪和任务切换为什么可以分开
初学者常有的误解是「任务一就绪就必须立刻切换过去」。MicroC/OS-II 把这两件事拆开了：置就绪位是「登记」，调用OS_Sched()才是「执行切换」。这个拆分在中断上下文里极其有用。
设想一个 CAN 接收中断：数据到了，中断服务函数把缓冲区的数据搬走，然后置位通信任务的就绪位，接着直接返回。此时通信任务已经「就绪」，但没有发生切换——CPU 继续跑被中断的那个任务，直到下一次节拍中断或该任务主动让出 CPU 时才真正切过去。这样做的收益有两层：中断服务函数短了，中断延迟可控；切换点集中在少数几个地方，栈帧的对齐关系容易验证。代价是响应时间多了最多一个节拍周期的延迟，在 250μs 节拍下这个数字是可以接受的。
提示：把「就绪」和「切换」分开，前提是你对最坏延迟心里有数。如果某个任务的就绪到运行之间不允许超过某个时间，就得把它放在节拍中断的那条切换路径上，而不是指望下一次自然调度。
3. 移植到底在移什么：内核与 CPU 之间那几份隐式契约
「移植」这个词容易让人以为是改一堆硬件驱动。实际上 MicroC/OS-II 的内核主体——调度、延时、事件控制、消息队列——一行都不用动，它跟硬件之间只通过少数几个接口打交道。移植的工作量集中在一份头文件和一份 C 文件上，但每一处改动背后都藏着一份「内核假设 CPU 会这么做」的契约。
3.1 OS_CPU.H：数据类型、栈增长方向和临界段宏
这份头文件要交代三件事。
第一是数据类型。内核代码里到处是INT8U、INT16U、INT32U、OS_STK这些 typedef，它们必须精确对应到目标平台的实际宽度。80C196 是 16 位机，OS_STK定义为 16 位无符号整数，这个宽度直接决定了栈上每一个格子的字节数，也就决定了栈帧布局。定义错了不会编译报错，只会在某个深夜以随机死机的方式暴露出来。
第二是栈的增长方向，通过OS_STK_GROWTH声明。内核在初始化任务栈时需要知道「往哪个方向压栈」，才能把伪造的初始栈帧摆到正确的位置。80C196 的栈是向下增长的，所以任务栈初始化函数里那些*--stk的写法是对的——每写一个字，指针先减再存。
第三是临界段宏。中断随时可能到来，而链表插入、就绪位置位这类操作必须原子完成，否则数据结构会被撕成两半。80C196 的 PSW 里有中断使能位，一条DI关中断、一条EI开中断，是最省的实现：
/* 进入临界段：禁止中断，保护不可分割的代码 */ #define OS_ENTER_CRITICAL() asm DI /* 退出临界段：重新允许中断 */ #define OS_EXIT_CRITICAL() asm EI这两行是整个移植里最短、也最容易被低估的代码。它们没有任何嵌套计数，意味着临界段不能嵌套调用——内核自身遵守这个约定，但应用代码如果随手在临界段里调用一个内部也用了临界段的函数，EI就会提前打开中断，保护的完整性瞬间消失。所以临界段里只放几条指令，是必须守住的纪律，不是风格偏好。
顺带说一句编译器。这套移植选了 TASKING 的 C196，理由很实际：它支持在 C 里内嵌汇编，于是所有跟 CPU 相关的函数都可以写在OS_CPU_C.C一个文件里，不需要单独维护一个.ASM。能用 C 表达的就用 C，只有必须精确控制寄存器和栈指针的地方才落到汇编。这个选择把代码的分散度降下来了——以后改一个栈帧布局，不用在两个文件之间来回对照。
3.2 OSTaskStkInit：给一个还没运行过的任务伪造一份栈帧
这是整个移植里最需要想清楚的一个函数。一个任务从创建到第一次被调度，中间从来没有真正运行过，它的栈上当然也没有「保存下来的现场」。但内核切换任务的动作是统一的：取出新任务的栈指针，弹寄存器，返回。这就要求OSTaskStkInit提前在一个空栈上伪造出一份看起来像「刚刚被中断过」的现场。
OS_STK *OSTaskStkInit(void (*task)(void *pd), void *pdata, OS_STK *ptos, INT16U opt) { OS_STK *stk; stk = (OS_STK *)ptos; /* 栈顶，向下增长 */ *--stk = (OS_STK)task; /* 任务入口地址，ret 时跳过去 */ *--stk = (OS_STK)0x0000 | gimask; /* PSW：预置中断屏蔽位 IMASK */ *--stk = (OS_STK)0x0000 | gimask1; /* IMASK1 与 WSR：中断屏蔽与窗口选择 */ *--stk = (OS_STK)4; /* DX */ *--stk = (OS_STK)3; /* CX */ *--stk = (OS_STK)2; /* BX */ *--stk = (OS_STK)1; /* AX */ return ((OS_STK *)stk); /* 返回最终栈顶，存进 TCB */ }逐行看这份栈帧的意图：最上面压入的是任务入口地址，这样切换函数最后那条ret一执行，PC 就跳到了任务函数开头，任务「像从没被打断过一样」开始运行。紧接着是 PSW，gimask决定这个任务运行时允许哪些中断进来——每个任务可以有自己的一套中断掩码，这个能力在小系统里未必用得上，但栈帧格式必须留出位置。再往下是IMASK1和WSR（窗口选择寄存器），80C196 的寄存器窗口机制需要它来定位当前寄存器组。最后四个是通用寄存器 DX、CX、BX、AX 的初始值，这里填了占位数字，因为任务第一次运行时并不依赖它们。
关键在于这份栈帧的「形状」必须跟OSCtxSw里pop的顺序严格镜像。栈是后进先出，压入顺序是 task、PSW、IMASK1/WSR、DX、CX、BX、AX，那么弹出顺序就必须是 AX、BX、CX、DX、IMASK1/WSR、PSW、PC。任何一处顺序颠倒，任务第一次运行就会跳到一个莫名其妙的地址上——这是移植中最经典的一类翻车现场。
3.3 OSStartHighRdy 与 OSCtxSw：pusha/popa 必须严格对称的那几行
这两个函数长得几乎一样，区别只在于「要不要先保存现场」。
OSStartHighRdy在多任务启动时被调用一次，此时没有任何任务在运行，所以不需要保存任何东西，直接把最高优先级就绪任务的栈指针装回 CPU、弹出寄存器、跳过去就行：
void OSStartHighRdy(void) { OSRunning = TRUE; /* 置系统运行标志 */ OSTCBCur = OSTCBHighRdy; /* 当前 TCB 指向最高优先级就绪任务 */ psp = OSTCBHighRdy->OSTCBStkPtr; /* 取出它的栈指针 */ asm { pop dx; pop cx; pop bx; pop ax; popa; /* 弹出其余寄存器 */ /* 此处 ret 会取走栈上的任务入口地址，任务开始运行 */ } }OSCtxSw则在运行过程中被OS_Sched()调用，此时必须先把当前任务的寄存器现场压栈，再换栈、再弹出新任务的现场：
void OSCtxSw(void) { asm { /* 保存被中断任务的现场 */ pusha; push ax; push bx; push cx; push dx; } OSTCBCur->OSTCBStkPtr = psp; /* 栈指针存回旧任务的 TCB */ OSTCBCur = OSTCBPrioTbl[OSPrioHighRdy]; /* 取新任务的 TCB */ OSPrioCur = OSPrioHighRdy; /* 更新当前优先级 */ psp = OSTCBCur->OSTCBStkPtr; /* 取得新任务的栈指针 */ asm { /* 恢复新任务的现场 */ pop dx; pop cx; pop bx; pop ax; popa; } }两个函数的压栈顺序是pusha; push ax; push bx; push cx; push dx，弹栈顺序是pop dx; pop cx; pop bx; pop ax; popa，完全镜像。这里的psp是一个全局变量，始终指向「当前正在运行的任务的栈顶」——它不是一个抽象概念，就是 CPU 栈指针的一份影子副本。切换的全部内容就是把这个影子副本在 TCB 和 CPU 之间搬来搬去。
真正需要留意的是OSCtxSw的调用场景：它可能从任务上下文被调用（任务主动让出 CPU），也可能从中断上下文被调用（中断结束时发现更高优先级任务就绪）。这两条路径进来时，栈上的内容是不一样的——中断进来时硬件已经压了一些东西。如果两条路径共用同一段切换代码却按同一种方式理解栈顶，弹出的时候就会错位。这是下一章要专门拆开的部分。
4. 当资源只剩 3.7K 字节、节拍只有 250μs：内核怎么裁
前面三章讲的是「内核本来长什么样」，这一章讲的是「在这颗芯片上它必须变成什么样」。80C196 系统的物理资源是：片内可用 RAM 220 字节，外部扩展 3584 字节，合计约 3.7K。MicroC/OS-II 推荐 10～200ms 的时钟节拍，而这个系统实际需要 250μs——快了将近两个数量级。空间和时间两头同时收紧，裁剪就不是可选项，而是前提。
4.1 空间裁剪：把 OSRdyTbl 压成一个字节，把 TCB 削到只剩骨头
先明确一条原则：片内 RAM 快，外扩 RAM 慢，所以操作系统自己的关键变量和应用里高频访问的变量优先塞进片内那 220 字节，外扩的 3.5K 留给任务栈和低频数据。这条原则决定了裁剪的方向——不是「能删就删」，而是「删到能放进片内」。
实际动的刀有五处。
第一刀，裁掉用不到的功能模块及其变量。信号量、互斥量、邮箱、消息队列、事件标志组、固定大小的内存分区管理，这些如果应用里一个都不用，对应的数据结构和函数就全部不参与编译。MicroC/OS-II 的源码结构对这件事很友好，OS_CFG.H里一串OS_XXX_EN开关就是为这个准备的。
第二刀，裁掉用不到的规模。应用里实际只有 6 个任务，那么原始设计中「最多 64 个优先级、两级就绪表」的规模就是纯浪费。OSRdyTbl从一个数组改成一个 8 位变量，OSRdyGrp直接删掉——因为只剩一组，它的值永远是 0，留着一个恒为 0 的变量毫无意义。连带地，OSUnMapTbl的用法也从「查两次表」简化成「查一次表」。
第三刀，改OS_InitTaskIdle的内容，让应用里优先级最低的那个任务顶替空闲任务。原始设计里空闲任务是一个独立任务，有自己的 TCB 和栈，作用是「CPU 没事干的时候有个东西在跑」。但嵌入式系统里最低优先级的任务往往本来就承担着类似的兜底职责（比如巡检、看门狗喂狗），把它复用作空闲任务，直接省下一整个 TCB 加一份任务栈。这一刀省下来的 RAM 相当可观。
第四刀，裁OS_TCB的字段。前面提到的OSTCBY、OSTCBBitY已经失去意义；如果不用事件控制，OSTCBEventPtr也可以去掉；如果不用任务名字符串，OSTCBTaskName去掉。每个字段看起来只有一两个字节，但乘以任务数就不是小数目。
第五刀，裁掉中断嵌套相关的内容。原始内核用一个OSIntNesting计数器记录中断嵌套层数，只有在嵌套层数为 0、也就是最外层中断即将退出时才允许任务切换。如果这个系统的中断设计保证不会嵌套（或者在设计上就禁止嵌套），那么这个计数器和围绕它的判断都可以去掉，既省 RAM 又省指令周期。
/* 裁剪后的 OS_TCB：只保留真正会被读到的字段（示意） */ typedef struct os_tcb { OS_STK *OSTCBStkPtr; /* 栈顶指针，切换时唯一真正用到的字段 */ INT8U OSTCBDly; /* 延时计数，为 0 表示未延时 */ INT8U OSTCBPrio; /* 任务优先级 */ /* OSTCBY / OSTCBBitY / OSTCBBitX 已删除：单字节就绪表不需要分组掩码 */ /* OSTCBEventPtr 已删除：不使用事件控制 */ /* OSTCBTaskName 已删除：不使用任务名 */ } OS_TCB;这张结构体是裁剪思路的浓缩。OSTCBStkPtr必须留，它是切换的全部；OSTCBDly必须留，节拍中断每来一次要对所有延时的任务减一；OSTCBPrio看着像冗余（TCB 指针本来就放在以优先级为下标的数组里），但某些路径上需要从 TCB 反查优先级，留着能省几次寻址。其余的，凡是没有代码路径会读的，一律删。
注意：裁剪变量和裁剪功能是两件事。删掉一个功能模块时，对应的变量会自然失去引用；但删掉一个变量时，必须确认所有引用路径都已经被裁掉，包括那些藏在条件编译分支里、平时不编译但将来可能打开的路径。血泪经验是：先删功能，再删变量，每次删完都重新完整编译一遍看有没有隐式引用。
4.2 时间裁剪：250μs 节拍下，函数调用本身就是奢侈品
时钟节拍从推荐的 10～200ms 提速到 250μs，意味着同样的时间窗口里，节拍中断的次数多了几十到上百倍。如果节拍是 200ms，每秒中断 5 次，中断服务函数的开销再大也无关痛痒；250μs 的节拍意味着每秒 4000 次中断，每次多花 20 个指令周期，一年下来就是白白烧掉的算力。
于是这一层的优化思路非常直接：把中断服务函数里的每一层函数调用都摊平。
第一条措施，弃用OSTimeDly，直接操作任务延时计数再调用OS_Sched。OSTimeDly是个包装得很周到的函数，参数校验、临界段保护、就绪表操作、调度触发一应俱全。但在只有 6 个任务、调用点固定的系统里，这些通用性都是开销。直接写「置OSTCBDly、清就绪位、调OS_Sched」这三步，语义一样，指令少一截。
第二条措施，弃用OSIntExit和OSIntCtxSw，把它们的代码直接摊进定时器中断服务函数。这两个函数本来是为「任意中断都可能触发任务切换」这个通用场景设计的，里面有一整套中断嵌套判断和栈指针修正逻辑（因为从中断上下文切换和从任务上下文切换，栈的基准是不一样的）。在定时器中断这条固定路径上，这些判断的结论是已知的，可以全部省掉。
第三条措施，压低其他中断服务函数的代码长度，并且在这些中断里不做任务切换。道理是：切换本身要花时间，而切换又是在中断上下文里做的，如果每个中断都可能切换，中断延迟的方差就会变大，节拍中断的准时性就受到影响。把切换点收敛到节拍中断这一处，其他中断只管置就绪位然后赶紧退出，是一个用响应延迟换时钟精度的取舍。
第四条措施，根据编译出来的汇编代码反推 C 代码的优化点。这一条听起来很笨，但在这个资源量级上非常有效——编译器在某些写法下会生成意料之外的寄存器保存和恢复序列，把循环里的一个临时变量挪到外面、把一个 16 位运算改成 8 位、把频繁访问的全局变量固定到片内，都能实打实地省下周期。
4.3 OSTickISR 内联：把 OSIntExit 和 OSIntCtxSw 摊平进中断服务函数
把前面几条措施落到代码上，就是定时器中断服务函数的最终形态。这个函数同时承担三件事：维护软件定时器、按分频驱动各级定时、在必要时完成一次任务切换。
void OSTickISR(void) { /* 重置软件定时器（原文此处省略，属于硬件相关动作） */ OS250usCount++; /* 250us 计数器加 1 */ if ((OS250usCount & 0x03) == 0) { /* 每 4 次，即 1ms 到一个 */ OS1msCount++; /* 1ms 定时器 */ OS50msDly++; /* 50ms 定时器 */ OSRdyTbl |= 0x20; /* 直接置位：TaskChk（位 5）就绪 */ } /* 以下为原 OSIntExit + OSIntCtxSw 的内联展开 */ OSPrioHighRdy = OSUnMapTbl[OSRdyTbl]; /* 查表取最高优先级就绪任务 */ if (OSPrioHighRdy != OSPrioCur) { /* 与当前任务不同才需要切换 */ OSTCBCur->OSTCBStkPtr = psp; /* 保存被中断任务的栈指针 */ OSTCBCur = OSTCBPrioTbl[OSPrioHighRdy]; OSPrioCur = OSPrioHighRdy; psp = OSTCBCur->OSTCBStkPtr; /* 取出新任务的栈指针 */ asm { pop dx; pop cx; pop bx; pop ax; popa; /* 恢复新任务现场 */ ret; /* 中断返回，PC 落到新任务 */ } } /* 未发生切换时，函数自然结束，走编译器生成的常规中断返回路径 */ }这段代码里有几个值得停下来看的点。
OSRdyTbl |= 0x20这一行是裁剪的直接产物。原始实现里「让一个任务就绪」要调OSTaskResume或者操作两级就绪表，这里变成对一个字节做一次或运算，位 5 对应优先级 5 的 TaskChk 任务。整个动作一条指令，还天然是原子的——单字节位操作在 16 位机上不会被中断撕开（前提是该位不是由多个中断同时操作，这一点在设计中断优先级时要确认）。
OSPrioHighRdy != OSPrioCur这个判断是必须的。如果最高优先级就绪任务就是当前正在跑的任务，那么「切换到自己」是没有意义的，白白做一遍保存和恢复。这个短路判断在节拍中断里命中的概率很高——大多数节拍到来时，跑着的任务仍然是最该跑的那个。
切换代码被完整内联，四行赋值加一段汇编，前面没有函数调用、没有参数压栈、没有返回地址。省下来的不只是几个周期，还有一种隐性成本：函数调用会改变栈的形状，从中断上下文进入函数再返回，栈指针的基准点必须重新校准。摊平之后，psp在整个路径上的含义始终如一，出错的可能性也随之降低。
最后那段汇编里的ret是整段代码的收尾动作。在 80C196 上，中断返回和子程序返回共用ret，它会从栈上弹出 PC 和 PSW。因为此时栈顶已经被换成了新任务的栈，ret弹出的就是新任务的返回地址——于是「中断返回」这个动作同时完成了「任务切换」。这是整个移植里最精妙的一笔：不需要额外的切换指令，中断返回本身就是切换。
5. 移植避坑：堆栈错位、开关中断时机和优先级分配的血泪经验
前面几章讲的是「应该怎么做」，这一章讲的是「哪里容易做错」。下面这几条都是从实际调试里熬出来的，每一条都对应过一段不太愉快的时光。
5.1 堆栈指针错位：最贵的 bug 往往只有一行之差
现象：系统跑几分钟到几小时不等，随机死机或者跳到莫名其妙的地址；有时候加一句无关的打印语句，故障消失；有时候改一下编译优化等级，故障频率变化。
原因：入栈和出栈不匹配。最典型的两种形态：一是中断服务函数里自己压了寄存器、退出时忘了弹，或者弹的顺序跟压的顺序不一致；二是中断退出有两条路径——正常退出和任务切换退出——这两条路径出栈的内容不同，如果代码里把两条路径合并了，就会出现「该弹 7 个字结果弹了 5 个」的情况。栈指针一旦错位，后续所有的返回地址、局部变量、甚至别的任务的数据都会跟着错位，表现出来就是彻底的随机性。
解决：把每一条可能改变栈指针的路径都画成栈帧图，标清楚进去时栈上有什么、出去时必须还原成什么样，逐条对照。特别要注意OSTaskStkInit伪造的初始栈帧和OSCtxSw弹出时的顺序必须严格镜像。调试手段上，给每个任务的栈填充固定魔数（比如0x5A5A），定期检查栈底附近的魔数是否被改写，能提前发现栈溢出——栈溢出和栈错位表现出来的症状几乎一样，先排除前者能省很多时间。
5.2 临界段与中断嵌套的边界
现象：偶发的数据错乱，链表节点丢失，就绪表里莫名多出或少掉一位；故障率跟中断频率正相关。
原因：临界段没包住该包的操作，或者临界段里做了不该做的事。前者的典型是「读—改—写」被中断打断：任务 A 正在修改就绪表，中断来了，中断服务函数也改了就绪表，返回后任务 A 把自己那份旧值写回去，中断的修改就丢了。后者的典型是在临界段里调用了一个内部也用了临界段保护的函数，内层的EI把中断提前打开了，外层以为还保护着，实际上已经裸奔。
解决：OS_ENTER_CRITICAL和OS_EXIT_CRITICAL没有嵌套计数，这是个硬性约束，必须靠代码纪律而不是机制来保证。具体做法是：临界段里只放几条不调用任何函数的指令；凡是需要多个步骤的操作，先在临界段外把数据准备好，进临界段只做最后那一次赋值。另外要注意中断屏蔽的时机——在中断服务函数里操作全局变量时，如果该中断本身的优先级高于节拍中断，需要考虑的就不只是关中断，还有中断嵌套层数的问题，这也是为什么在这个系统上干脆把中断嵌套相关内容裁掉了。
5.3 优先级分配与同类任务的分层
现象：系统功能都正常，但某些场景下响应变慢，或者某个低优先级任务长时间得不到运行。
原因：优先级分配只考虑了「重要性」，没考虑「时间容忍度」。一个通信故障处理任务看起来很重要，被给了高优先级，但它一旦触发就要占用大量时间做错误恢复，期间所有低优先级任务全部饿死，整个系统的定时节拍都被拖累。
解决：按容忍时间分层，而不是按主观重要性分层。同样的通信工作也要区分：接收数据的容忍时间可能是几毫秒，必须高优先级；故障处理的容忍时间可能是几十毫秒甚至更长，放在低优先级完全够用。这条经验在原文里被明确写出来，值得反复咀嚼——「同类型工作，也同样需要有优先级区分」，这句话背后是「任务的重要性」和「任务的紧迫性」这两个概念的分离。
还有一条相关的：尽量减少任务数量。每个任务意味着一份独立的栈、一个 TCB、以及一次切换开销，任务数量翻倍，切换开销也跟着上去。能把逻辑合并到一个任务里顺序执行的，就不要拆成两个任务。这条听起来跟「用 RTOS 就是为了多任务」矛盾，但在小资源 MCU 上，任务划分的粒度本身就是一种设计取舍。
提示：定时器周期不要拍脑袋。节拍太快，中断开销吃掉有效算力；节拍太慢，软定时精度不够。合理的做法是从应用里最紧的那个软定时需求反推，再留一倍余量，而不是直接照搬推荐值或者别人项目里的数字。
6. 设计取舍：抢占式内核在小资源 MCU 上的收益边界
聊到这里，可以回头看看引入这个内核到底换来了什么、付出了什么。
| 维度 | 无限循环＋中断服务 | 抢占式内核 |
|---|---|---|
| RAM 占用 | 一套全局变量加一个栈 | 每任务独立栈，外加 TCB 和就绪表 |
| ROM 占用 | 只有业务代码 | 内核代码加业务代码，需裁到 3.5K 以内 |
| 最坏响应时间 | 取决于最长循环体，通常无法给出上界 | 由优先级和临界段长度决定，可估算 |
| 中断延迟 | 短，路径直接 | 多一层就绪表判断和可能的切换 |
| 功能扩展 | 加一个功能要改主循环结构，牵一发动全身 | 加一个任务，优先级独立，边界清晰 |
| 调试难度 | 逻辑线性，容易跟踪 | 并发交错，需要额外手段观察任务状态 |
这张表里最值得盯的是第三行。抢占式内核真正的价值不在于「能同时跑多个任务」——单核上从来没有真正的同时——而在于最坏响应时间变得可估算。在顺序执行的架构里，一个紧急事件从发生到被处理，要等当前循环体跑完，而这个时间随着功能增加会不断变长，最后没人说得清到底是多久。引入内核之后，这个时间被拆成了几段可测量的部分：中断延迟、临界段长度、优先级高于它的任务占用时间，每一段都能算。这种「不确定性被转化成可计算的预算」的能力，才是它在实时系统里立足的根本。
代价同样清晰。内核本身要吃 RAM 和 ROM，节拍中断要吃掉固定的 CPU 时间，任务切换要吃掉指令周期，临界段会给中断延迟加上一个下限。在小资源平台上，这些成本不是百分比级别的，而是能直接决定「这个功能能不能加进去」的硬约束。所以判断标准不是「RTOS 先不先进」，而是「你的系统里有没有一个必须给出响应时间上界的需求」——有，就值得付出这些成本；没有，顺序循环反而更省。
移植这件事本身也藏着取舍。把硬件相关代码集中到一个 C 文件、用内嵌汇编而不是独立汇编文件，牺牲的是一点点代码密度（编译器生成的汇编未必最优），换来的是可读性和可维护性；把就绪表压成一个字节，牺牲的是优先级数量的扩展性，换来的是每次调度省下的几条指令和几个字节；把切换逻辑内联进定时器中断，牺牲的是代码复用，换来的是栈路径的唯一性和可验证性。每一处都是在「已知的、确定的小损失」和「未知的、可能的大风险」之间做选择。
我自己的习惯是：任何一次涉及栈帧或者临界段的改动，改完之后都要在纸上把栈的生长和回收画一遍，画不出来就不许编译。这个习惯是被一次持续了两天的随机死机逼出来的——最后发现只是中断退出的一条分支少弹了一个寄存器，而那条分支平时几乎不会走到。从那以后我每次动这类代码，都强制走一遍「画栈帧、标路径、对顺序」的流程，宁可慢半天，也不想再对着示波器和反汇编猜。希望帮到你。
本文还有配套的精品资源，点击获取
