FreeRTOS 让 FreeRTOS 在 C251 上从能用到好用, 2026/9/14更新

cy***

楼主花费精力，把自己的研究成果分享给大家，是难能可贵的，创造好的氛围，鼓励和支持创新。

tzz1***

感谢对本移植的持续关注。经过这段时间的讨论，有几个问题已经逐步清晰，这里一并说明。

一、关于“强行在中断内切换任务”
关于这一点，你在后续的回复中已调整为“逻辑可行”，不再使用“强行在中断内切换任务”的表述。这是一个积极的进展。
本移植用最低优先级中断模拟PendSV进行任务切换，其机制是借鉴 PendSV 分层思想，并保证 51 的 RETI 计数正确——切换请求只置标志，
真正的上下文切换发生在所有中断退出后的基级，不存在“从嵌套中直接返回”的场景。这一点我们已有共识，不再展开。

二、关于临界区保护中 _testbit_(EA)  的正确性

你在质疑中提到“临界区是否没关中断”，这里正面解释一下。

_testbit_(EA) 对应的是 JBC 指令（Jump if Bit set and Clear bit）。这条指令在一个不可分割的操作中同时完成三件事：
测试EA位、如果为1则跳转、同时将该位清零。由于整个过程由硬件原子性地执行，不会被任何中断打断，
因此它天然实现了“保存旧中断状态”和“关中断”两个动作的原子性。

本移植的临界区实现逻辑是：

如果进入临界区时EA为1（中断开启），JBC指令会原子性地将EA清零并跳转，同时保存“进入前EA”的状态；
如果EA原本为0，JBC不跳转，记录“进入前EA=0”。
退出临界区时，根据嵌套计数归零后恢复进入前的EA状态。
JBC方案可以正确处理任意深度的嵌套，这正是OS临界区保护的标准做法。

三、关于4个NOP与OS移植稳健性的关系

STC官方文档对4个NOP的说明有明确场景：当执行了操作中断相关寄存器的指令（例如 TR0 = 0），
如果希望这条指令产生的中断能够被响应，再关总中断，需要在中间加入4个NOP，等该指令真正生效后再执行 EA = 0。
这里4个NOP服务的是“让前一条指令执行完成”，针对的是特定硬件寄存器的时序要求，而不是泛化的“关中断前都要加NOP”。
它是指令隔离，不是临界区保护。

进入 OS 临界区之前，通常并没有一条“刚操作了中断相关寄存器、且希望该中断被响应”的指令。
它只是单纯地需要关总中断并记忆状态，进入原子操作。此时在关中断之前是否有中断请求，不属于临界区保护的范围。
临界区保护的是 portENTER_CRITICAL() 到 portEXIT_CRITICAL() 之间的代码序列。
如果某个应用确实需要在关中断前响应特定中断或使某个设定生效，应由该应用自己显式处理，而不是把责任转嫁给OS的临界区宏。

4个NOP解决的是指令级时序问题，OS临界区解决的是代码级原子性问题，两者是正交的。把4个NOP与OS移植稳健性绑定，在技术上不成立。

四、感谢

最后，感谢你投入时间对本移植进行审视和质疑。
经过这一轮讨论，至少有几个点已趋于清晰：任务切换机制不再被表述为“强行在中断内切换任务”，
临界区实现得到了正面解释，4个NOP的适用边界也有了明确界定。这种基于代码和原理的讨论，对完善移植本身是有价值的。


代码开源，欢迎继续基于事实和原理进行技术交流。

杨***

这是我的技术分析结论：

在没有 PendSV 的单片机上硬上 FreeRTOS：关总中断切任务的安全隐患清单
https://www.stcaimcu.com/thread-25602-1-1.html
(出处: 国芯人工智能技术交流网站)

在没有 PendSV 的单片机上硬上 FreeRTOS：关总中断切任务的安全隐患清单

一、先说结论有，而且不止一个。
如果你打算把 FreeRTOS 从 ARM Cortex-M 单片机搬到 STC32G12K128 这类没有 PendSV 异常硬件、也没有 BASEPRI 中断屏蔽寄存器的 8051 增强型单片机上，并且采用 "在中断里关总中断强行切换任务" 的做法，
那么功能上大概率能跑通，但实时性和可靠性会比 ARM 原版差一截。
具体有哪些隐患、严重到什么程度，下面结合一段真实可跑的移植代码逐条说。

五、那到底能不能用
直接给结论。
做演示、做玩具、做对实时性不敏感的小东西 —— 能用。
做产品、做有安全要求的设备、做工业现场的控制器 —— 这套移植方案的安全余量不够。
具体判断标准有三条，你可以对着自己的项目量一量。
第一条，用 GPIO 翻转实测 CLR EA 到 SETB EA 的最长时间，包括 PendSV 和 Timer0 两个地方。
第二条，找出你系统里最不能等的那个中断 —— 可能是急停、可能是看门狗、可能是总线错误。
第三条，把上面两个数加起来，看是不是远小于那个最紧急中断能容忍的延迟窗口。
如果加起来已经接近甚至超过容忍窗口，那就别在这种架构上硬撑 FreeRTOS 了。
要么换 MCU，要么老老实实前后轮询加状态机，不一定比被一堆隐患拖住的 RTOS 差。

最后说一句
FreeRTOS 官方这么多年一直没出 8051 的官方移植，不是没人想做。
是因为在没有 NVIC、没有 BASEPRI、没有 PendSV 这种硬件原语的单片机上，你要么用关总中断换正确性，要么用关总中断换原子性。
怎么选都是同一个结果：关中断时间比 ARM 长，最坏情况响应延迟比 ARM 大。
移植者能做的，只是把这个窗口尽量压短、把契约尽量做硬。
知道自己在做什么，比能不能跑起来重要得多。

杨***

大刀*** 发表于 2026-9-19 08:54
本帖中触发敏感词的内容已被系统监测删除。
本帖初衷为技术学术交流，目前已经严重偏离主题，大量楼层出现 ...

古代学堂里有一种东西，叫做戒尺！

古代学堂里有一种人，非得被打着骂着才肯好好读书。
本帖子头几页里有一个人，不说他两句就不会好好谈技术问题！欢迎大家去观摩。
我的问题提了几天，没人回答，这下不就好好谈技术，讨论具体的安全隐患了。