华山论剑（4）：倚天剑x51，真正实现了“零中断延迟”的STC单片机RTOS
本帖最后由 杨为民 于 2024-5-27 07:18 编辑一、前言本文是华山论剑系列文章的的第4篇。第1篇文章《科普“零中断延迟”的临界区保护方法》介绍了“零中断延迟”的概念和STC单片机RTOS临界区保护的两类方法：关闭和不关闭总中断的临界区保护方法。第2篇文章《“零中断延迟”是否可以实现： RTOS的最大中断延迟时间测量》介绍了如何测量单片机RTOS的中断延迟时间，并且对“同等优先级中断”的延迟时间进行了实际测量，结论是：对于硬件中断优先级与系统中断相同或更低的用户中断而言，哪怕在用户中断里没有调用系统服务，由于系统中断的阻塞，用户中断也不可能是“零中断延迟”的。换言之“零中断延迟”的概念仅适用于那些优先级高于系统中断的用户中断。第3篇文章《CosyOS-II-STC8H在测试高优先级中断服务调用时崩溃了》介绍了用CosyOS-II官宣的“零中断延迟”测试程序进行测试的结果。结果表明当在用户中断中进行系统服务调用时，如果用户中断的周期小于25微秒（40KHz），则系统运行崩溃。在该帖子中，CosyOS本尊给出了崩溃的原因。本篇文章介绍了对倚天剑x51和CosyOS-II进行含系统服务的用户高优先级中断的响应时间的测试方法、实际测试结果和测试结论。“倚天剑x51-RTOS for STC8H”是笔者专为STC8H系列单片机研制的RTOS。倚天剑x51也采用“不关闭总中断”的临界区保护方法，但是倚天剑x51具体实现的方法与CosyOS-II有巨大的不同，因此两者对于用户的“高优先级有系统服务中断”的性能也有很大的差异。倚天剑x51对于用户的“高优先级有系统服务中断”真正实现了“零中断延迟”，而CosyOS-II对于用户重复中断调用有限制，当用户重复中断周期小于7微秒（大约）后，系统会崩溃，因此只有当用户重复中断周期长于限制值时，CosyOS-II才算是“零中断延迟”的。 二、测试方法介绍（1）本文的测试方法是对本论坛RTOS排行榜的方法进行改造而来的。对CosyOS-II的测试程序来源于该排行榜，测试结果仅适用于那个测试版本，未必代表CosyOS-II最新版本的水平。（2）首先是采用可以设置中断优先级的定时器1作为用户中断定时器，将其优先级设置为最高级，同时将系统节拍定时器0的中断优先级设置为最低级：
（2）为了测试用户高速中断响应，将原来的中断唤醒任务A的处理内容修改为只是反转P02端口信号：
这个任务平常挂起在第21行，由定时器1中断唤醒，反转信号后又挂起。因此任务A的执行周期就是定时器1中断中调用系统唤醒服务的周期。
（3）任务B和任务C的任务切换是非中断任务切换：
它们的任务优先级低于任务A。
（4）用户中断调用系统服务的测试程序如下：
其中第80行是调用系统服务唤醒任务A，如果将该行注释掉，就可以进行无系统调用的用户中断测试。正常情况下，可以采用9.2毫秒周期的用户重复中断来测试各种中断响应和任务切换时间。
（5）正常运行时的信号如下：
其中第2通道是用户中断信号方波，第3通道是用户中断调用系统唤醒服务的信号，通道4是任务A的运行信号，每执行一次任务A，通道3的电平反转一次。其中第7通道是任务C的信号，每5毫秒反正一次。第5通道是任务C唤醒任务B的信号，第6通道是任务B的信号。任务B每被唤醒一次，产生一个50毫秒的正脉冲。三、极限测试结果
（6）测试1是无系统调用高优先级中断的测试，用户重复中断周期设置为1微秒。下图是倚天剑x51的测试信号图：
其中通道1是系统1毫秒节拍信号，可以看到通道2的用户1微秒重复中断是连续的。测试结论：由于倚天剑x51和CosyOS-II采用的都是“不关闭总中断”的临界区保护方法，所以这两个RTOS对于高优先级的不含系统服务调用的用户重复中断，都没有什么影响，都是真正“零中断延迟的”。（7）中等强度测试2是调用高优先级中断的测试，用户重复中断周期设置为97微秒。下图是CosyOS-II的测试信号图：
图中可以看到3个任务都正常运行，局部放大如下图：
图中用户重复中断周期97微秒，每个周期产生一次中断调用，任务A被执行一次。 测试结论：中等强度测试2，由于97微秒的用户重复中断周期比较长，所以倚天剑x51和CosyOS-II这两个RTOS对于97微秒的含系统服务调用用户重复中断，都没有什么影响，都是真正“零中断延迟的”。（8）高强度测试3是调用高优先级中断的测试，用户重复中断周期设置为11微秒。下图是CosyOS-II的测试信号图：
下图是倚天剑x51的测试信号图：
从图中可以看到，由于11微秒的用户重复中断周期已经小于在STC8H单片机上的RTOS的中断任务切换时间，因此高优先级的任务A占据了CPU的全部处理时间，优先级低的任务B和任务C再也得不到执行的机会了，图中的通道5、6、7已经没有信号了。不过这种现象是正常的。测试结论：对于高强度测试3，由于11微秒的用户重复中断周期短于中断任务切换时间，所以倚天剑x51和CosyOS-II这两个RTOS的低优先级任务B和任务C已经得不到执行的机会了，但中断唤醒任务A仍然可以执行。因此对于11微秒的含系统服务调用用户重复中断，这两个RTOS都是真正“零中断延迟的”。（9）超高强度测试4是调用高优先级中断的测试，用户重复中断周期设置为7微秒。下图是CosyOS-II的测试信号图：
当用户重复中断周期为7微秒时CosyOS-II崩溃了，只剩通道2的用户中断测试信号。下图是倚天剑x51的测试信号图：
从图中可以看到任务A仍然在正常运行。测试结论：对于超高强度测试4，当用户重复中断周期为7微秒时CosyOS-II已经崩溃了。倚天剑x51的中断唤醒任务A仍然可以执行。因此对于7微秒的含系统服务调用用户重复中断，只有倚天剑x51是真正“零中断延迟的”。（10）极高强度测试5是调用高优先级中断的测试，用户重复中断周期设置为1微秒。下图是CosyOS-II的测试信号图：
当用户重复中断周期为1微秒时CosyOS-II仍然崩溃，只剩通道2的用户中断测试信号。下图是倚天剑x51的测试信号图：
从图中可以看到任务A仍然在正常运行。 测试结论：对于极高强度测试5，当用户重复中断周期为1微秒时CosyOS-II仍然崩溃。倚天剑x51的中断唤醒任务A仍然可以执行。对比前面7微秒的图，可以看到系统节拍定时器0由于中断阻塞已经停止工作了。 （11）最终结论：由于用户中断定时器1的中断优先级高于系统节拍定时器0的中断优先级，在测试5的极端情况下，尽管系统节拍定时器0都已经停止工作了，但是1微秒的含系统服务调用的用户重复中断仍然在正常运行。因此只有倚天剑x51对于高优先级用户中断真正是“零中断延迟的”。
本帖最后由 杨为民 于 2024-5-25 01:38 编辑
第3篇文章《CosyOS-II-STC8H在测试高优先级中断服务调用时崩溃了》介绍了用CosyOS-II官宣的“零中断延迟”测试程序进行测试的结果。结果表明当在用户中断中进行系统服务调用时，如果用户中断的周期小于25微秒（40KHz），则系统运行崩溃。在该帖子中，CosyOS本尊给出了崩溃的原因。
华山论剑（3）： CosyOS-II-STC8H在测试高优先级中断服务调用时崩溃了
https://www.stcaimcu.com/forum.php?mod=viewthread&tid=8516
(出处: 国芯技术交流网站)
第2篇文章《“零中断延迟”是否可以实现： RTOS的最大中断延迟时间测量》介绍了如何测量单片机RTOS的中断延迟时间，并且对“同等优先级中断”的延迟时间进行了实际测量，结论是：对于硬件中断优先级与系统中断相同或更低的用户中断而言，哪怕在用户中断里没有调用系统服务，由于系统中断的阻塞，用户中断也不可能是“零中断延迟”的。换言之“零中断延迟”的概念仅适用于那些优先级高于系统中断的用户中断。
华山论剑（2）： “零中断延迟”是否可以实现： RTOS的最大中断延迟时间测量
https://www.stcaimcu.com/forum.php?mod=viewthread&tid=8196
(出处: 国芯技术交流网站)
第1篇文章《科普“零中断延迟”的临界区保护方法》介绍了“零中断延迟”的概念和STC单片机RTOS临界区保护的两类方法：关闭和不关闭总中断的临界区保护方法。
华山论剑（1）： 科普“零中断延迟”的临界区保护方法
https://www.stcaimcu.com/forum.php?mod=viewthread&tid=8151
(出处: 国芯技术交流网站)
第5篇文章《华山论剑（5）：CosyOS-II-STC8H在有函数重入时又崩溃了》
华山论剑（5）：CosyOS-II-STC8H在有函数重入时又崩溃了
https://www.stcaimcu.com/forum.php?mod=viewthread&tid=8604
(出处: 国芯技术交流网站)
不使用临界区保护时，我可以写不可重入代码破坏任何MCU操作系统。
因此，这不是操作系统单方面的责任
页:
[1]