杨为民 发表于 2024-5-4 14:31
（1）在我学的操作系统理论术语中，临界区保护方法分为“关闭中断”的和“不关闭中断”的两大类。“不关 ...
感谢杨老师的指教！
本帖最后由 CosyOS 于 2024-5-4 18:15 编辑
杨老师说的我都赞同！
中断的阻塞是必然存在的，“真正的零中断延迟”是没有可能的。
“零中断延迟”这个说法，最早我是从 Keil RTX 4/5 的 相关说明中看到的，至于它的出处，想必可能是 Keil。
我所理解的“零中断延迟”，与 Keil 的相关描述类似。
零中断延迟并非是中断响应时间为零，而是指当引入了RTOS以后，中断响应时间仍然能够达到MCU内核特性的响应时间，
即只要中断发生，就能按中断优先级立即抢占。也就是说，中断响应时间不受RTOS影响，与裸机编程是一样的。
按照我的个人理解，所谓“零中断延迟”，最重要的还是“用户中断的响应时间不受RTOS影响”。
如果在“最高优先级中断 或 不可屏蔽中断 中处理临界段”，虽然没有关闭总中断，但却与“关闭总中断处理临界段”的效果相同，
都将导致用户中断的响应时间受到了RTOS的影响，都是 因RTOS处理临界段而导致用户中断不能实时响应。
至于，由于用户中断已经响应而导致的相同优先级或更低优先级的用户中断不能实时响应，
那是必然会发生的事情，是用户个人的问题了，只要RTOS不会影响用户中断的实时响应就好，这是 CosyOS 的理念。
当然，我并不排斥采用“关闭总中断处理临界段”，和在“最高优先级中断 或 不可屏蔽中断 中处理临界段”这两种方法，
只是建议处理临界段的时间要尽可能的短，并把这个时间的最大值告知用户。
本帖最后由 CosyOS 于 2024-5-5 01:20 编辑
有时候，用语言是难以描述清楚一个问题的实质的，
但我们可以通过看他是怎么做的，来了解他的 核心设计思想。
Keil RTX 4/5 - 实时运行模型
【用户中断层】（用户中断：按中断优先级实时抢占、零中断延迟）
↓
【内核服务层】（系统中断：处理内核服务、上下文切换等）
↓
【任空务空层】（任空空务：按任务优先级实时抢占）
内核服务层，由 SysTick、PendSV、SVC 构成；
SysTick：系统节拍；
PendSV：中断挂起服务的执行、任务调度与切换；
SVC： 执行任务中调用的内核服务；
SysTick、PendSV 均为最低优先级，是互斥访问的；
SVC 比它们高一级，以抢占 SysTick、PendSV；
如果当前正在 SysTick 或 PendSV 中，那必定不在 任务 中，而只有任务才能触发 SVC，所以，SysTick、PendSV 不会被 SVC 打断；
如果当前正在 SVC 中，SysTick、PendSV 是无法打断SVC的；
从而实现 SysTick、PendSV、SVC，三者间的互斥访问。
除中断本地服务之外，所有内核服务均在内核服务层（服务层临界区）执行，从而保证服务的“操作流”不会被打断。
❉建议用户中断不要使用最低两级优先级，以免被系统中断抢占，导致丢失响应或处理延误。
CosyOS-II - 实时运行模型
【用户中断层】（用户中断：按中断优先级实时抢占、零中断延迟）
↓
【内核服务层】（系统中断：处理内核服务、上下文切换等）
↓
【任空务空层】（任空空务：按任务优先级实时抢占）
内核服务层，由 SysTick、PendSV、任务临界区 构成；
SysTick：系统节拍；
PendSV：中断挂起服务的执行、任务调度与切换；
任务临界区：执行任务中调用的内核服务；
SysTick、PendSV 均为最低优先级，是互斥访问的；
任务临界区 是要关闭 SysTick、PendSV 中断；
从而实现 SysTick、PendSV、任务临界区，三者间的互斥访问。
除中断本地服务之外，所有内核服务均在内核服务层（服务层临界区）执行，从而保证服务的“操作流”不会被打断。
❉建议用户中断不要使用最低一级优先级，以免被系统中断抢占，导致丢失响应或处理延误。
由此不难看出，Keil RTX 4/5 和 CosyOS-II 的 核心设计思想 是一致的，
都是 以用户中断优先级为最高，内核服务不要影响用户中断的实时响应，任务的优先级为最低。
通过以上介绍，相信大家对 Keil RTX 4/5 和 CosyOS-II 的 零中断延迟技术，将会理解的更为透彻！
CosyOS 发表于 2024-5-4 18:11
杨老师说的我都赞同！
中断的阻塞是必然存在的，“真正的零中断延迟”是没有可能的。
（1）去年当我正在以系列文章介绍uC/OS-II的移植，介绍的移植对象采的临界区保护方法是连嵌套都没有实现的，只能采用最简单的直接关闭/打开中断的方法才能运行的。
那时我应约和你采用PK的方式《STC 原生RTOS PK 移植RTOS 》（https://www.stcaimcu.com/forum.php?mod=viewthread&tid=2297）
来介绍STC单片机的两种不同类型的RTOS，“不关闭总中断”的临界区保护方法的 RTOS PK“关闭总中断”的临界区保护方法的RTOS。
（2）当时我就想一个问题，为什么Cortex-M架构的单片机上主流的RTOS：uC/OS、FreeRTOS和RT-Thread都采用 “关闭总中断”作为临界区保护方法？是它们的技术不行还是理念不行？
当时我对RTX的评价是“不堪大用”，理由是其“过分依赖”Keil的编译器，“缺少广泛”的开源库资源支持，因此难以成为STC单片机上的主流的RTOS。
（3）为了深入研究探讨这两种不同类型的RTOS的优势与不足，我自己特地移植了一个“不关闭总中断”的uC/OS-II版本（主流RTOS）：挑战者x51(TZZx51-uCOS2) V3.30，不过它实现的技术路线与CosyOS截然不同。
（4）我将另外用系列文章来讨论“零中断延迟问题”，欢迎大家围观参与。
CosyOS 发表于 2024-5-4 18:56
有时候，用语言是难以描述清楚一个问题的实质的，
但我们可以通过看他是怎么做的，来了解他的 核心设计思想 ...
中国古人说“它山之石可以攻玉”
中国古人又说“南栀北桔”和“东施效颦”
听谁的？某个电视剧里说的好: “试一试就知道了”。
所以我亲自用“关闭总中断”和“不关闭总中断”两种方法
在STC32G单片机是同时移植了主流的RTOS：
uC/OS-II，同时给出了“微山x51”和“挑战者x51”两个移植版本供大家比较和交流。
对于这两个不同方法的特点和性能比较，我已经发表了系列文章进行了分析讨论。
我还将对采用这两种方法的RTOS进行深入测试，会把测试结果分享给大家
杨为民 发表于 2024-5-4 19:44
中国古人说“它山之石可以攻玉”
中国古人又说“南栀北桔”和“东施效颦”
好的杨老师，对相关问题，我要做进一步的和更为全面的，研究、分析、和反思，
不能天天只盯着“零中断延迟”，要用更大的视角来全方位审视 RTOS 的相关问题，
争取在未来能有所突破。
本帖最后由 fanxsp 于 2024-5-5 12:09 编辑
tzz1983 发表于 2024-4-8 11:57
嗯,用一段时间看看再说, 我想到几个可能要改善的参考点.
现在看来支持Large模式应该也是有必要的，进一步看看能不能做成 small、large模式可配置
STC8, 用户变量尽量使用 xdata;
STC8, idata尽量给RTOS使用，给堆栈使用
本帖最后由 fanxsp 于 2024-5-5 16:17 编辑
fanxsp 发表于 2024-5-5 12:04
现在看来支持Large模式应该也是有必要的，进一步看看能不能做成 small、large模式可配置 ...
@tzz1983，这个办法好，系统函数全部都指定为 small, 这样系统就不受编译器 smalllarge模式的影响，用户可以自由指定编译器的small、large模式，我试一下看。
神农鼎 发表于 2024-5-5 14:30
STC8, 用户变量尽量使用 xdata;
STC8, idata尽量给RTOS使用，给堆栈使用
是的，尽量尊守这个原则。