“零中断延迟”是否可以实现： RTOS的最大中断延迟时间测量

杨***

一、不关闭总中断与零中断延迟

（1）STC8H和STC32G/F系列单片机的推出为在STC单片机上移植主流 RTOS和研发针对STC单片机的RTOS提供了硬件基础。不过由于STC系列单片机缺乏像Cortex-M系列单片机上的专门针对RTOS的“SVC”和“PendSV”软中断指令，因此对于RTOS的临界区保护方法出现了“关闭总中断”和“不关闭总中断”两种类型，后者又被称为“零中断延迟”类型。

（2）对于STC单片机，除了定时器0的不可屏蔽中断模式3外，其余的中断都受总中断控制。如果RTOS的临界区保护方法是采用关闭总中断的方法，则RTOS系统运行到临界区中时（比如进行任务切换时），关闭总中断会导致所有的新中断被禁止，新中断要延迟到系统从临界区中退出，总中断重新被打开后才能发生。这种延迟影响了RTOS的实时性。

（3）结论：对于STC单片机上的RTOS，只要临界区保护方法是采用关闭总中断方法的，无论是可嵌套的或者是不可嵌套的，都可能对单片机的用户中断产生阻塞，对用户中断的发生时间产生延迟。

假定在RTOS系统中，程序中临界区保护最长的那一段的执行时间为T，那么这个时间T就是这个RTOS系统运行时用户中断的“最大中断延迟时间”，也就是在最坏情况下用户中断可能产生的最大延迟时间。

（4）不关闭总中断的临界区保护方法的思路是在进入临界区时不关闭总中断吗，只关闭那些涉及RTOS系统服务的中断，这样那些不涉及RTOS系统服务的用户中断仍然可以及时发生，这样就不会影响RTOS系统对用户中断响应的实时性了，理论上就可以实现对用户中断的“零中断延迟”了。

（5）为了验证不关闭总中断的临界区保护方法在STC单片机上是否能真正实现“零中断延迟”，笔者在STC32G单片机上分别采用了关闭总中断的和不关闭总中断这两种临界区保护方法对uC/OS-II进行了移植（微山x51和挑战者x51）。本文介绍了对这两种RTOS进行“最大中断延迟时间”的测量方法和测量结果。

（6）本文还对率先在STC单片机是采用“不关闭总中断”临界区保护方法的CosyOS-II进行了测量。

（7）最后得到结论是：

A）在STC单片机是目前采用“不关闭总中断”临界区保护方法的RTOS，无论是笔者的挑战者x51或者是CosyOS-II的目前版本，都没有能真正实现对用户中断的“零中断延迟”。

B）这些“不关闭总中断”临界区保护方法的RTOS的“最大中断延迟时间”与“关闭总中断”临界区保护方法的RTOS的“最大中断延迟时间”都在同一个量级。

二、关闭总中断的RTOS系统的最大中断延迟时间测量

（8）针对STC32G/STC8H单片机的具体情况，本文对最大中断延迟时间测量方法是用定时器3产生一个1微秒（1MHz）的用户中断，该中断仅仅是在P00端口上产生一个方波，然后用逻辑分析仪查看这个用户中断的信号是否被RTOS系统阻塞，测量最大的阻塞时间，就是该RTOS以微秒为单位的“最大中断延迟时间”。

（9）下图是采用“关闭总中断”临界区保护方法的uC/OS-II移植版微山x51的测试程序：

其中ISR只有一行程序“CPL  080H;”。由于这条指令不会改变PSW和任何寄存器的内容，所以ISR连中断现场保护都不需要。

程序中的080H对应于P00端口，可以通过对逻辑分析仪的0通道测量这个中断信号。

（10）为了模拟正常的RTOS运行环境，本测试在任务B和任务C之间进行了任务切换和任务休眠，见下图：

其中包括了RTOS的基本功能调用。

（11）为了找到用户中断延迟发生在什么地方，本测试程序给出了P01和P02两个参考信号，对应逻辑分析仪的通道1和通道2。这两个信号对于uC/OS-II的系统节拍处理“OSTimeTick()”和中断任务切换“uCx51_IntSched()”函数。测试信号程序见下图：

（12）系统节拍产生的中断延迟。下图是1毫秒周期的系统节拍产生的用户中断延迟信号：

从中可以看到，当没有发生任务切换时，系统节拍（通道1）和中断任务切换程序（通道2）导致的用户中断延迟（通道0）的时间是10.625微秒（11.625-1.000）。

（13）任务切换产生的中断延迟。下图是uC/OS-II系统在进行中断外任务切换时产生的用户中断延迟信号：

从图中可以看到用户中断（通道1）多次被延迟（不均匀脉冲部分），也就是多次进入和退出临界区保护。其中最长的延迟时间是11.750微秒（12.750-1.000）。

（14）结论：对于使用关闭总中断作为临界区保护方法的uC/OS-II的最大中断延迟时间为12微秒左右。

（15）注意：本文的1微秒的用户中断测试是处于RTOS的非正常工作状态下，因此测试程序运行了一段时间后有可能进入死机状态。

三、不关闭总中断的RTOS系统的最大中断延迟时间测量

（16）挑战者x51是为了研究“零中断延时”技术在STC32G单片机是对uC/OS-II进行移植的版本，该版本采用了不关闭总中断的临界区保护方法。

（17）除了研究“不关闭总中断”的零中断延迟问题，挑战者x51还研究了关闭总中断对RTOS的影响。为了达到关闭总中断也不影响RTOS系统的运行效果，挑战者x51将系统节拍和中断任务切换都放到定时器0中断中，并且将定时器0设置为不可屏蔽中断模式3，同时还将定时器0的中断优先级设置为最高优先级3。

（18）下图为挑战者x51的中断延迟信号图：

从图中可以看到，由于定时器0的不可屏蔽中断（通道1）存在，在系统节拍和中断内任务切换时用户中断信号（通道0）被延迟了3.625微秒（4.625-1.000）。

（19）从图中还可以看到，由于采用了不关闭总中断的临界区方法，在中断外任务切换期间（通道3的正脉冲），用户中断没有受到任何影响。

（20）结论：挑战者x51没有实现真正的“零中断延迟”。其最大中断延迟时间约为4个微秒。

（21）本论坛的CosyOS-II 的临界区保护方法也是不关闭总中断的，本文对排行榜上的“CosyOS-II-STC32G-TEST-V2.1.3-20240410”版本进行了测试。

A）对其每1毫秒一次的节拍中断处理进行测量如下图：

大约是13.125微秒（14.125-1.000）

B)对其休眠任务“uDelay_ms(5)”切换造成的用户中断延迟测试如下图：

其中也出现了多次中断延迟（猜测是含有PenSV中断造成的），其中最长的延迟为11.250微秒（12.250-1.000）。

C)对其任务恢复“uResumeTask(TASK_B);”切换造成的用户中断延迟测试如下图：

其中也出现了多次中断延迟（猜测是含有PenSV中断造成的），其中最长的延迟为12.250微秒（13.250-1.000）。

（22）结论：CosyOS也没有实现真正的“零中断延迟”。其最大中断延迟时间约为13个微秒，与使用关闭总中断作为临界区保护方法的uC/OS-II的最大中断延迟时间差不多。

Cos***

CosyOS 在说明书中明确指出：
“只要您的用户中断不是最低优先级就可实现零中断延迟，
而且支持随意调用系统服务，对零中断延迟无影响”。

这一点要求是没有办法的事情，
在 CosyOS 中，内核服务层（系统中断）占用最低中断优先级，
用户中断若想实现零中断延迟，就必须要高于最低中断优先级。

请杨老师更换其它可配置中断优先级的中断，如定时器1中断，并配置为非最低优先级，再次进行对比测试！
看看结果会如何 ？？？

届时，真相便会大白于天下！


到底什么是  “零中断延迟” ？
“不关闭总中断” 等于 “零中断延迟” 吗？
这些问题，便可通过本次的对比测试，昭告天下！

杨***

CosyOS 发表于 2024-5-7 01:38
CosyOS 在说明书中明确指出：
“只要您的用户中断不是最低优先级就可实现零中断延迟，
而且支持随意调用系 ...

这是我在另一个帖子里的答复

（1）“前提条件是，不能是最低优先级中断”。具体问题必须具体分析，对于STC32G系列单片机，其中断结构如下图：



其中最低优先级至少包括了INT2、INT3、Timer2、Timer3和Timer4，这些都是用户最常用的定时器中断资源，CosyOS-II对这些中断都不能实现“零中断延迟”，那么CosyOS-II“零中断延迟”的意义就要大打折扣了。
（2）“关闭总中断”的临界区保护方法造成的“中断延迟”时间经对比测试与“不关闭总中断”对最低优先级的“中断延迟”时间相差不多。那么如果用户能够接受CosyOS对Timer2、Timer3和Timer4这几个中断的“中断延迟”，为什么不能接受“关闭总中断”的其他RTOS比如uC/OS-II同样量级的“中断延迟”？
（3）对于作为软件系统单片机RTOS最重要的宗旨是什么？最重要的指标是什么？我认为是可靠性和安全性，不是中断响应速度！如果RTOS是安全可靠的，各种速度指标会促进硬件的发展来解决。况且对于大规模工业应用，10几个微秒的中断响应已经是够先进的了。比如对于PLC，本论坛的EasyLad的8毫秒时间响应（EasyLad  8ms STC32G12K128(32MHz)）已经是够先进的了，见《几种PLC运行速度大PK》（https://www.stcaimcu.com/forum.p ... &extra=page%3D1）。但是如果RTOS的安全性可靠性得不到保障，速度指标再高也不能减小用户系统面临的风险。
（4）我在本帖144楼的问题：（2）当时我就想一个问题，为什么Cortex-M架构的单片机上主流的RTOS：uC/OS、FreeRTOS和RT-Thread都采用 “关闭总中断”作为临界区保护方法？是它们的技术不行还是理念不行？

我的答案是它们不是技术上不能实现，而是它们的理念是RTOS必须安全可靠。用“关闭总中断”作为临界区保护方法，可以确保RTOS系统的临界区程序的执行不被打断，不受干扰地完成。但是对于用“不关闭总中断”作为临界区保护方法，高优先级的中断可能中断正在RTOS系统临界区的程序执行，然后去执行另外的程序，就可能产生意想不到的危险。所以这些主流RTOS都采用了用“关闭总中断”作为临界区保护方法。
（5）按照CosyOS本尊的说法：
CosyOS 的 原则 是 “简单易用”，以极具浪漫主义色彩的宏定义，实现高度的面向对象、和良好的易用性。
CosyOS 的 宗旨 是 “零中断延迟”，支持内核均已实现全局不关总中断、零中断延迟，从系统层面保证了用户中断的实时响应。
每个RTOS都有它的“标签”或是“特色”，这是该RTOS的安身立命之本。
CosyOS 的标签、特色、就是：易用性、零中断延迟。

其中没有一个字提到“安全可靠”，这种RTOS的设计理念我不赞同。


（1）你说的“真正的零中断延迟的确是不可能的”。这个结论我在进行对比研究后很赞同。
所以结论是：一切“零中断延迟”都“不是真正的”，都是“假的”或者都是“有条件的”！
（2）这个论坛里小白很多，为避免误解，建议你以后将“零中断延迟”的表达改为“高优先级中断零延迟”或者“零中断延迟（高优先级）”，这个表达比较科学一点。

Cos***

杨为民 发表于 2024-5-7 10:39
这是我在另一个帖子里的答复

（1）“前提条件是，不能是最低优先级中断”。具体问题必须具体分析，对于ST ...

杨老师讲的确实有道理，对于 STC8、STC32 等 单片机 来说，
许多 中断 都被固定设计为最低优先级、无法调整，
这对 CosyOS 来说，的确不是一个好消息。
而 Arm内核则不同，除了个别的几个负优先级异常，
其它所有异常和IRQHandler，都可随意调整优先级。

关于 RTOS 安全性、可靠性的问题，我已经在另外的帖子中进行了论述，
欢迎杨老师批评、指导。
https://www.stcaimcu.com/forum.php?mod=viewthread&tid=7491&extra=page%3D1&page=17

神***

优先级固定为0的可以不用其为中断，
TIMER2/3/4 如只做波特率发生器，
INT2/INT3/INT4改用 所有普通的I/O都支持外部中断

Cos***

通过姚总的提示  和  上述的  STC32G中断优先级结构图 不难看出，
对于 STC32G 来说，大部分中断都是可配置中断优先级的，
这对 CosyOS 来说，无疑是一个好消息。

“有条件的零中断延迟” 总好过 “无条件的有中断延迟”，这是我的个人观点。

杨***

神农鼎 发表于 2024-5-7 14:00
优先级固定为0的可以不用其为中断，
TIMER2/3/4 如只做波特率发生器，
INT2/INT3/INT4改用 所有普通的I/O都 ...

姜还是老的辣，你说的是正道！


CosyOS-II 既然不采用不可屏蔽中断模式3，那么放弃定时器0，将定时器4作为系统节拍定时器即可。
然后把定时器2和定时器3留给串口1到串口4做波特率发生器，而串口1到串口4的中断中断优先级是可以调高的。
然后用INT4作为Cosy-II的PendSV中断，这样除了INT2和INT3，在CosyOS-II中其他所有的“用户中断都是零延迟的”了

杨***

CosyOS 发表于 2024-5-7 14:35
通过姚总的提示  和  上述的  STC32G中断优先级结构图 不难看出，
对于 STC32G 来说，大部分中断都是可配置 ...

（1）“有条件的零中断延迟” 总好过 “无条件的有中断延迟”，这是我的个人观点。
这个观点我十二分赞同！从学术上这个观点表达还不够，应该是：“有条件的零中断延迟” 肯定好过 “无条件的有中断延迟”！

（2）只要你作为本尊带头在“零中断延迟”前加上定语，无论是“有条件的零中断延迟”、或者是“高优先级中断零延迟”、又或者是“零中断延迟（高优先级）” 、再或者是你在另一篇帖子回复中介绍的“用户中断层零延迟”，我愿意采用你的新说法，并将其作为“不关闭总中断”临界区保护方法的首要优点加以介绍。
（3）为什么我想劝说你要加上定语，是因为本来“不关闭总中断”作为STC单片机RTOS的临界区保护方法还有许多优点和先进性，我不想让别人误解为需要用含糊的“零中断延迟”来作为噱头进行宣传。加上定语，不但词语上更加科学准确，而且无损于“不关闭总中断临界区保护方法”的光辉！


（4）除了这个有争议的说法，CosyOS-II还有更多的特色和先进性等待你本尊亲自去介绍。

Cos***

杨为民 发表于 2024-5-7 16:40
姜还是老的辣，你说的是正道！

杨老师的这个建议的确很好，
待我好好梳理一番，并在未来做出适当调整。

Cos***

杨为民 发表于 2024-5-7 17:23
（1）“有条件的零中断延迟” 总好过 “无条件的有中断延迟”，这是我的个人观点。
这个观点我十二分赞同 ...

感谢杨老师的建议，
“零中断延迟”的说法，的确容易造成误解，
应当适当加以修饰，我完全接受杨老师的建议。
我需要想一想，到底如何描述才好。