企业官网建设流程全解析

简介：MicroC/OS-II在80C196上的移植论文文档，面向嵌入式开发者与实时操作系统学习者，聚焦资源受限单片机上引入抢占式多任务内核的完整实现思路。内容围绕C196编译器选型、与处理器相关的数据类型和函数改写、任务划分与优先级调度展开，并针对80C196片内仅220字节、外扩约3.5KB的存储条件，讨论功能模块裁剪、OSRdyTbl与OS_TCB精简等具体做法。时间资源部分涉及250μs时钟节拍、弃用OSTimeDly、简化中断退出与任务切换，以及临界段开关中断等移植注意事项。压缩包共1个doc文件，约45KB，适合作为移植报告或论文参考；已有283人学习，读者可从中获取代码适配、资源平衡和老系统不改变硬件前提下的功能升级案例，对不改硬件而提升实时性与稳定性的工程实践也有参考价值。

1. 从"主循环撑不住"说起：为什么要在 80C196 上移植 MicroC/OS-II

某款基于 80C196 的老控制器要加三样功能：CAN 收发、键盘显示刷新、一路闭环控制，硬件已定型不能改。原软件是典型的无限循环加中断服务，加完功能后 CAN 开始丢帧，控制周期从 5 ms 抖到 12 ms。问题不在某个函数写得慢，而在单任务顺序执行这个模型本身。

这就是把 MicroC/OS-II 移植到 80C196 的动机。它是一个源码开放、可裁剪、抢占式的多任务实时内核，任务按优先级抢占 CPU，关键任务不必等前面的循环走完。这套方案适合硬件不能动、实时性又已经顶到天花板的老平台升级，也适合拿它当实时操作系统移植类毕设的完整骨架。

2. 总体方案设计：内核裁剪边界与存储、时间两条资源线

移植这件事，很多人一上来就翻 OS_CPU_C.C，改完编译通过就以为成了。80C196 这种资源量级的平台，真正决定成败的是先做减法——内核留多少、RAM 怎么切、时间片里塞得下什么。这三件事定不下来，代码改得再漂亮也会在联调阶段整片塌掉。我一般把总体设计拆成三张账：功能账、存储账、时间账。

2.1 内核结构拆解：哪些文件必须留，哪些可以整段删掉

MicroC/OS-II 的源码是模块化的，OS_CORE.C 负责任务调度、就绪表维护和事件控制块初始化，OS_TASK.C 负责任务创建、挂起、删除，这两个是内核的骨架，一行都裁不得。OS_TIME.C 提供 OSTimeDly、OSTimeDlyHMSM 这类延时接口，本项目实际用的是直接操作任务定时器的写法，这一块大部分可以砍掉。OS_SEM.C、OS_MBOX.C、OS_Q.C、OS_MEM.C、OS_FLAG.C 分别对应信号量、邮箱、消息队列、内存分区和事件标志组，老控制器的任务间通信靠共享标志位和就绪表就够，这几个文件整段不参与编译。

配置集中在 OS_CFG.H 里，裁剪不是删文件就完事，宏要跟着改，否则编译出来的结构体里还留着大数组。下面这张表是我在 6 任务系统里用的配置组合。

提示：改完 OS_CFG.H 一定要重新编译整个工程，不能只编译改动过的文件。头文件里的宏会影响 OS_TCB、OS_EVENT 这些结构体的成员布局，增量编译很容易留下新旧结构体混用的隐患。

裁剪的连带影响要提前想清楚。把 OS_LOWEST_PRIO 从 63 降到 7，OSRdyTbl 就从 8 字节数组缩成一个字节，OSUnMapTbl 的索引方式也跟着变；关掉 OS_Q_EN 之后，OS_QPost 这类函数的调用点要在应用层全部清掉，不能靠链接器去报未定义符号来发现，那样排查成本太高。通常的做法是先在纸面上把"用到的 API 清单"列出来，再对着 cfg 文件逐条勾，勾完再动手改源码。

2.2 存储资源账本：220 字节片内 RAM 的分法

这颗片子片内可用 RAM 只有 220 字节，外部扩了 3584 字节（3.5K）。地址空间不是均质的——片内访问是一条指令，片外要走间接寻址，速度和指令长度都吃亏。所以分区的原则很明确：内核的调度热数据放片内，任务栈和大的缓冲区放片外。

把 OS_TaskIdle 换成应用最低优先级任务这一招很省，但也最容易出事。空闲任务原本是个死循环，永远不就绪、永远不阻塞；换成真实任务之后，它有了自己的就绪条件和阻塞点，一旦它因为等事件被挂起，而其他任务也全部阻塞，就绪表就是空的，调度器会拿着一个无效的 OSTCBHighRdy 去做切换。通常的做法是在这个"伪空闲任务"里保留一段永远可执行的兜底逻辑，比如喂狗和状态灯刷新，保证就绪表任何时候都不为空。

另外要提醒一点：裁剪 OS_TCB 成员时，凡是内核代码里读过、写过的字段都不能动，只能删那些"本配置下永远不会被访问"的。比如 OSTCBDly 在弃用 OSTimeDly 之后看起来没用，但节拍中断里的任务定时器递减还是要靠它，删了就会在联调时得到一个"任务永远不超时"的玄学现象。

2.3 时间资源账本：250 μs 节拍下每一项开销都要算

MicroC/OS-II 手册推荐的时钟节拍是 10～200 ms，那是给资源宽裕的平台写的。本系统因为要在一拍之内完成 CAN 报文的周期判定和闭环控制的采样对齐，节拍定在 250 μs，比推荐值高两个数量级，系统额外开销必然大幅上升。

按 16 MHz 晶振、大部分指令 1～2 个机器周期估算，250 μs 大约是 2000 个机器周期。一次完整的节拍中断如果包含"重装软件定时器 + 计数 + 就绪判定 + OSIntExit + 上下文切换"，保守估计要吃掉 150～250 个机器周期，占比 8%～12%。这个比例在实时系统里已经算重了，所以每一项都要抠。

注意：把 OSIntExit 和 OSIntCtxSw 内联进 ISR，等于绕过了内核的中断嵌套计数。这样做的前提是系统里只有节拍中断会触发任务切换，其他中断一律不切。这个前提必须在设计文档里写死，后面谁加了一个"顺手切一下"的中断，整个调度就乱了。

3. 移植实现：与处理器相关的四类代码改写与验证顺序

所谓移植，说到底就是改写那一小撮和处理器硬件绑死的代码：数据类型宽度、堆栈增长方向、临界段开关、上下文保存与恢复。剩下的内核逻辑一行都不用碰，这也是选 MicroC/OS-II 的现实理由。实现顺序我一般按"数据类型 → 堆栈初始化 → 上下文切换 → 节拍中断"推进，每一步都能单独验证，失败时定位范围小。

编译器用的是一款支持内嵌汇编的 C196 编译器，能内嵌汇编，所以全部函数都放在 OS_CPU_C.C 里实现，没有单独的 OS_CPU_A.ASM 文件。能写成 C 的就用 C 写，只有直接操作堆栈指针和寄存器的片段用内嵌汇编，这样代码分散度低，后来人接手也能读。

3.1 数据类型与配置文件：OS_CPU.H、OS_CFG.H、INCLUDES.H

OS_CPU.H 是移植的第一道关，里面三类东西必须和 80C196 的实际位宽对齐：基本数据类型、堆栈单位、临界段宏。80C196 是 16 位机，int 是 16 位，栈按字节编址但压栈单位是字，堆栈增长方向是从高地址向低地址。

/* OS_CPU.H —— 与 80C196 相关的类型与宏定义 */ typedef unsigned char BOOLEAN; /* 布尔量，8 位即可 */ typedef unsigned char INT8U; /* 无符号 8 位 */ typedef signed char INT8S; typedef unsigned int INT16U; /* 80C196 的 int 为 16 位 */ typedef signed int INT16S; typedef unsigned long INT32U; /* 32 位量较少用，注意访问非原子 */ typedef unsigned int OS_STK; /* 堆栈单位：一个栈元素占一个字 */ #define OS_STK_GROWTH 1 /* 1 表示堆栈从高地址向低地址增长 */ /* 临界段：直接对应 80C196 的 DI / EI 指令 */ #define OS_ENTER_CRITICAL() asm DI /* 关中断 */ #define OS_EXIT_CRITICAL() asm EI /* 开中断 */

OS_STK 定义为 16 位是无符号整型而不是 char，这一点很关键。如果按 8 位定义，OSTaskStkInit 里*--stk每次只退一个字节，压进去的返回地址和 PSW 就会被拆成两半错位存放，任务第一次被调度时直接跑飞，而且现象是随机地址，极难定位。OS_STK_GROWTH 取 1 之后，内核里所有和栈相关的指针运算方向才会正确。

INCLUDES.H 是个总头文件，所有 .C 文件都包含它。移植时要在里面补上 80C196 的寄存器定义头文件和应用层的公共头文件，顺序上硬件头文件在前、应用头文件在后，避免应用里定义的宏覆盖掉寄存器位定义。

3.2 任务堆栈初始化：OSTaskStkInit 的入栈顺序决定生死

这个函数只在任务创建时被调一次，但它决定了任务第一次被调度时能不能"像刚被中断过一样"正确恢复。原理是伪造一个中断现场：按 80C196 中断响应时硬件压栈的顺序，把 PSW、返回地址、通用寄存器依次摆到栈顶，再把栈指针指到这个伪造现场的底部。调度器第一次切到这个任务时，执行的是和中断返回完全相同的出栈序列，于是任务就从它的入口地址开始跑。

/* OSTaskStkInit —— 为新建任务伪造一个中断现场 */ OS_STK *OSTaskStkInit(void (*task)(void *pd), void *pdata, OS_STK *ptos, INT16U opt) { OS_STK *stk; stk = (OS_STK *)ptos; /* ptos 指向任务栈的栈顶（高地址） */ *--stk = (OS_STK)task; /* 任务入口地址，ret 指令取出后跳转 */ *--stk = (OS_STK)0x0000 | gimask; /* PSW：中断屏蔽位按应用配置 */ *--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); /* 返回新的栈顶，存入 OSTCBStkPtr */ }

压在栈里的这几项和后面 OSCtxSw、OSStartHighRdy 里的出栈序列是一一对应的，出栈顺序必须是压栈顺序的严格逆序：先 popa 恢复 AX/BX/CX/DX，再 pop 出 WSR 和 PSW，最后靠 ret 弹出入口地址。任何一项顺序对不上，任务起来之后寄存器就是错的值，表现出来往往是"任务能进去，但算出来的数全是乱的"。gimask 和 gimask1 两个屏蔽字按应用实际需要的中断源来定，通常是节拍定时器和 CAN 接收。

这个函数返回的指针会被存进任务的 OSTCBStkPtr，所以最后返回的必须是减去 7 个栈元素之后的地址，不能返回原始的 ptos。这一点在调试时可以用一个技巧验证：任务创建完先不启动调度器，直接读 OSTCBPrioTbl 里对应 TCB 的栈指针，和创建时传入的 ptos 相减，差值应该正好是 7 个栈元素。

3.3 上下文切换：OSCtxSw 与 OSStartHighRdy 的成对写法

上下文切换有两个入口，一个是系统启动时第一次运行最高优先级任务，一个是任务运行过程中由 OS_Sched 触发。两者的保存部分不同（启动时没有"被中断的任务"），恢复部分完全一致。恢复部分必须写得一模一样，因为将来任何一处改了寄存器列表，另一处忘了改，就会出现"第一次能跑，切一次就死"的诡异现象。

/* OSStartHighRdy —— 系统启动，第一次运行最高优先级就绪任务 */ void OSStartHighRdy(void) { OSRunning = TRUE; /* 置系统运行标志 */ OSTCBCur = OSTCBHighRdy; /* 当前 TCB 指向最高优先级任务 */ psp = OSTCBHighRdy->OSTCBStkPtr; /* 取出该任务的栈指针 */ asm { pop dx; /* 恢复通用寄存器 */ pop cx; pop bx; pop ax; popa; /* 恢复 PSW 等状态字 */ 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/popa 和 push ax/push bx 这两组的相对顺序，必须和 3.2 里 OSTaskStkInit 的压栈顺序对齐：伪造现场时是先压入口地址、再压 PSW、再压 DX/CX/BX/AX，那么恢复时就必然是先 popa 再 pop 出 DX 到 AX。这里没有 pop ret 的指令，ret 是在 popa 之后由返回地址自然弹出的。

psp 这个变量是本移植里一个绕不开的东西。80C196 的栈指针不是一个可以直接用 C 变量表达的寄存器，编译器生成的 C 代码不能直接读写它，所以只能用汇编层的一个符号来承接。这个符号必须声明成全局的、且不能被编译器优化掉，通常放在一个独立的汇编模块里，或者用编译器支持的扩展关键字固定它。

3.4 时钟节拍：把 OSIntExit 和 OSIntCtxSw 内联进 ISR

节拍是 250 μs，用软件定时器实现。为了省掉两次函数调用和一次重复的临界段判断，这一版没有调 OSIntExit 和 OSIntCtxSw，而是把它们的源码直接内联进了节拍 ISR。代价是这段代码可读性变差，收益是省下来的机器周期在 250 μs 的预算里非常可观。

/* OSTickISR —— 250us 软件定时器中断服务函数，内含任务切换 */ void OSTickISR(void) { /* 重置软件定时器 */ OS250usCount++; /* 250us 计数器加 1 */ if ((OS250usCount & 0x03) == 0) { /* 每 4 拍，即 1ms 到一次 */ OS1msCount++; /* 1ms 定时器 */ OS50msDly++; /* 50ms 定时器 */ OSRdyTbl |= 0x20; /* 让 TaskChk 任务就绪，位 5 对应其优先级 */ } /* 以下为 OSIntExit 的内联版本：找到最高优先级就绪任务 */ OSPrioHighRdy = OSUnMapTbl[OSRdyTbl]; if (OSPrioHighRdy != OSPrioCur) { /* 需要切换才切 */ OSTCBCur->OSTCBStkPtr = psp; /* 保存被中断任务的栈指针 */ OSTCBCur = OSTCBPrioTbl[OSPrioHighRdy]; /* 取新任务 TCB */ OSPrioCur = OSPrioHighRdy; psp = OSTCBCur->OSTCBStkPtr; /* 取新任务栈指针 */ asm { pop dx; /* 恢复现场 */ pop cx; pop bx; pop ax; popa; ret; /* 中断返回到新任务 */ } } }

这里有几个参数要盯住。OSUnMapTbl 是就绪表到优先级的反查表，就绪表缩成一个字节之后，这张表也要相应缩到 256 项以内，否则查出来的是越界值。OSRdyTbl |= 0x20 里的 0x20 对应优先级 5，改任务优先级必须同步改这一位，两处不同步就是"任务永远不跑"或者"跑错任务"。(OS250usCount & 0x03) == 0这个判断决定了 1 ms 任务的节拍，改节拍基准时这里是第一个要动的地方。

其他中断服务函数一律不在里面做任务切换，只置就绪位或者写共享变量。这样做缩短了关中断窗口，节拍误差能压下来；代价是响应延迟从"立即"变成"下一个 250 μs 拍"，对 CAN 这类有容忍时间的通信任务完全够用。

4. 任务划分与调度设计：6 个任务的优先级表与就绪切换分离

内核移植通了只是能跑，任务怎么切分才是决定这套系统好不好用的地方。任务数不是越多越好，每多一个任务，就多一份栈空间、多一份切换开销、多一个优先级要排。80C196 这个资源量级，6 个任务是实测下来比较平衡的点。

4.1 任务划分：先按事件源分，再按截止时间排序

划分任务的第一个原则是"一个事件源一个任务"，而不是"一个功能一个任务"。CAN 接收、键盘扫描、定时采样这些各自有独立触发条件的，应该拆开；而"显示刷新"和"显示内容计算"这种强耦合、共享同一份数据的，合并在一个任务里反而省事，省掉一次任务间同步。

优先级数字越小越高。CAN 接收排第一，是因为它有硬件 FIFO，溢出了就真丢数据，后悔药没得吃。控制算法排第二，周期性和确定性要求最高。故障处理排在最低，理由在后面 4.3 里说。

栈大小 256 字节不是拍脑袋定的。做法是先把栈填成固定魔数，跑满 30 分钟各种工况，再看每个栈里魔数被覆盖的最深处，取实测值加 30% 余量。留太少会在某个极端分支里悄悄踩栈，现象是"偶发跑飞"，查起来非常痛苦。

4.2 就绪与切换分离：中断里只置就绪，节拍里再切

这是本方案里我认为最值得抄的一条设计。MicroC/OS-II 默认允许在任意中断退出时触发任务切换，但在这颗片子上，每个中断都走一遍 OSIntExit 的开销加起来很可观。本方案改成：CAN 接收中断只做"把 TaskCanRx 置就绪"这一件事，然后直接返回；真正的任务切换统一放在 250 μs 的节拍中断里做。

CAN 接收中断: 收数据 → 写缓冲 → OSRdyTbl |= 0x02 → 返回（不切换） 节拍中断: 计数 → 置就绪位 → 查最高优先级 → 需要则切换

这样做的收益是三重的：一是缩短了 CAN 中断的关中断窗口，降低丢帧概率；二是任务切换的时机变得可预测，始终在节拍边界上，系统的时序分析一下子简单了；三是中断服务函数里不需要再包临界段，减少了嵌套关中断的次数。

代价是响应延迟从"中断返回即切换"变成"最多等一个节拍"。250 μs 的额外延迟，对 CAN 报文处理完全在容忍范围内，但对那种要求微秒级响应的信号就不合适了。是否采用这个设计，取决于系统里最紧的那条截止时间，不能一概而论。

4.3 同类型任务分级与优先级反转的规避

优先级分配最容易犯的错是"按功能重要性排"，而正确的排法是"按截止时间排"。一个不重要的任务如果截止时间很紧，优先级也该高；一个很重要的任务如果容忍时间有 100 ms，就没必要占着高优先级。

故障处理任务就是这个逻辑。通信故障处理听起来很重要，但实际业务里对故障的容忍时间通常在几十到上百毫秒量级，只要在这个窗口内处理掉就行。如果把它放到高优先级，一旦发生不可恢复性错误，故障处理函数会占用大量时间，把控制任务和采样任务全堵在后面，整个系统的实时性直接崩掉。放到最低优先级，它慢慢跑，不影响任何关键路径。

提示：同类型工作也要分优先级。接收数据要高于故障处理，因为接收有硬件 FIFO 溢出风险，故障处理只是记录和上报，两者的紧迫程度差一个数量级。

优先级反转在这个系统里表现为另一种形式：TaskChk 和 TaskDisplay 共享一块显示缓冲区，如果 TaskDisplay（优先级 6）正在写缓冲区时被 TaskChk（优先级 5）抢占，而 TaskChk 也去读这块缓冲区，就会读到半新半旧的数据。解决办法不是加信号量（本配置把信号量裁掉了），而是用双缓冲加一个"写完成"标志位：写方先写备用缓冲区，写完后原子地交换指针，读方永远读已经完成的那一份。这比引入信号量省得多，代价是多占一块缓冲区的 RAM。

5. 移植避坑：五个最容易翻车的现场与排查手法

这一节写的是我在联调阶段真实撞过的坑，按"现象 → 原因 → 解决"记，照着排查能省不少时间。

5.1 堆栈指针错位：现象是任务随机跑飞

现象：任务创建成功，调度器启动后，某个任务执行几条指令就跳到完全无关的地址，用仿真器看 PC 值每次都不一样，像是随机的。

原因：OS_STK 的类型宽度和实际压栈单位不匹配。如果 OS_STK 定义成 8 位，*--stk每次只退一个字节，而 80C196 压栈是按字进行的，压进去的入口地址和状态字就被拆开错位存放，ret 弹出来的地址自然是一个无效值。

解决：确认 OS_STK 定义为 16 位无符号整型，确认 OS_STK_GROWTH 为 1，然后在 OSTaskStkInit 返回前加一条断言，检查返回指针与入参 ptos 的差值正好等于压入的栈元素个数。这个断言在开发阶段保留，量产前用宏关掉。

5.2 入栈出栈不匹配：现象是第一次切任务就死

现象：单任务能跑，一旦发生第一次任务切换，系统就停在某个死循环里或者复位。

原因：OSCtxSw 里的 push 序列和 pop 序列不对称。最典型的是 pusha 之后又 push 了 ax/bx/cx/dx，但恢复时只写了 popa 没写对应的 pop，或者顺序写反了。因为切任务时恢复出来的寄存器值全错，任务一执行就访问到非法地址。

解决：把 OSCtxSw、OSStartHighRdy 和 OSTaskStkInit 三处的寄存器序列抄在一张纸上，逐个比对，压栈顺序的逆序必须等于出栈顺序。中断服务函数里的处理同理：正常退出和任务切换退出这两条路径的出栈内容必须严格对应，不能一条多弹一个、一条少弹一个。

5.3 临界段漏加：现象是偶发数据错乱

现象：系统跑几分钟到几小时才出一次错，就绪表里出现不该有的位，或者某个任务的 TCB 指针被改成乱值。复现极难，加打印就消失。

原因：就绪表、TCB 链表这类内核数据结构，在任务上下文和中断上下文里都会被读写。某段操作忘了包 OS_ENTER_CRITICAL/OS_EXIT_CRITICAL，正好在"读—改—写"的中间被节拍中断打断，中断里也改了同一份数据，两次修改互相覆盖。

解决：把所有对 OSRdyTbl、OSRdyGrp、OSTCBPrioTbl 的读改写操作全部用临界段包住，包括那些"看起来只有一条赋值"的地方。判断标准很简单：如果这条 C 语句编译出来超过一条指令，就存在被打断的窗口。查这类问题时，可以在进入和退出临界段时翻转一个空闲 IO 口，用示波器看关中断窗口的长度和分布，能很快定位到漏加的位置。

5.4 节拍中断里塞太多逻辑：现象是节拍漂移

现象：系统运行一段时间后，基于节拍计数的定时全部变慢，示波器量出来的实际节拍比 250 μs 长，而且负载越重漂得越厉害。

原因：节拍 ISR 里除了必要的计数和切换，还塞进了应用逻辑，比如状态机推进、数据打包。ISR 执行时间一旦超过节拍周期，下一个节拍就会被推迟，误差逐拍累积。

解决：节拍 ISR 只保留三件事——重置定时器、递增计数器并置就绪位、判断是否需要切换。其余逻辑全部挪到任务里，靠计数器的值来判断"到点没到点"。改完之后用 IO 口翻转法量一次 ISR 的实际执行时间，留出至少 50% 的余量。

5.5 优先级拍脑袋分配：现象是高优先级任务饿死低优先级

现象：系统功能都正常，但某个任务几乎从来不执行，或者执行得断断续续，日志里能看到它被创建但没输出。

原因：两个任务的实际优先级冲突，或者高优先级任务里有一个不阻塞的死循环。MicroC/OS-II 是严格按优先级抢占的，高优先级任务只要一直就绪，低优先级任务一点 CPU 都分不到，不存在"时间片轮转"这种兜底机制。

解决：给每个任务明确写出它的阻塞条件——靠什么事件阻塞、最长阻塞多久。凡是"永远就绪"的任务，只允许存在一个，而且必须是空闲任务或它的替代者。优先级表定下来之后，用就绪表打印的方式验证一遍：在节拍 ISR 里记录每个优先级在 1 秒内被调度的次数，跑满一分钟看分布是否符合设计预期。

6. 验收与答辩：用一张测试表证明移植真的成立

移植做完了怎么证明它成了，这是答辩和交付时最容易被追问的地方。编译通过、灯能闪、串口能打印，这些都不算证据。我一般准备一张"可测量、可复现、有阈值"的验收表，每一项都对应一个具体的内核行为。

抢占延迟这一项最值得花时间测，它是整套方案的价值所在。测法是让一个低优先级任务在循环里不断翻转一个 IO 口，同时用定时器在某个时刻把高优先级任务置就绪，用双踪示波器看两个沿之间的时间差。这个数字直接回答了"引入实时操作系统到底带来了什么"——原来主循环模式下这个延迟可能是几毫秒甚至十几毫秒，现在稳定在几百微秒以内。

答辩时如果被问到"为什么不用现成的 RTOS"，回答的逻辑要落在资源约束上：通用 RTOS 的内核对象和调度器是按资源宽裕的平台设计的，最小配置下来 RAM 和节拍开销都吃不消；MicroC/OS-II 的源码完全开放，可以把就绪表缩成一个字节、把 TCB 里不用的字段删掉、把中断退出内联进 ISR，这些改造在闭源方案里做不了。再加上抢占式调度和高优先级任务优先的确定性，正好对上这颗片子的约束。

还有一个常被追问的点是"裁剪之后还是不是原来那个内核"。回答的关键是划清边界：裁剪只动了配置宏、未使用的模块和与硬件相关的四个文件，调度算法、就绪表查找、任务状态机这些核心逻辑一行没改，所以行为是等价的。为了证明这一点，可以做一次对照实验：同一份任务代码，在未裁剪的仿真环境里跑一遍，在裁剪后的目标板上跑一遍，比较任务调度序列，两者一致就说明裁剪没有改变语义。

我从这个项目里落下了一个习惯：任何一次内核移植，验收表必须在写第一行移植代码之前就列出来，而不是等调通了再补。因为表里的每一项都会反过来约束设计——要求关中断窗口不超过 20 μs，就会逼着你在写 ISR 的时候就想清楚哪些逻辑该挪到任务里；要求栈留 70% 余量，就会逼着你老老实实去填魔数测深度，而不是凭经验拍一个 512 字节。希望这套结构能帮到你，少走几段我走过的弯路。

本文还有配套的精品资源，点击获取