本帖最后由 杨为民 于 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对于高优先级用户中断真正是“零中断延迟的”。
附件401_倚天剑x51_V31_STC8H_超载极限测试.rar
(89.21 KB, 下载次数: 97)
附件402_CosyOS-II-STC8H-TEST_超载极限测试.rar
(408.81 KB, 下载次数: 83)
| 
|手机版|小黑屋|深圳国芯人工智能有限公司
( 粤ICP备2022108929号-2 )
发表于 2024-5-25 01:03:21
发表于 2025-2-20 15:47:57