原创极简的51-MCU专用RTOS TinyRTOS51

Cos***

杨*** 发表于 2024-5-4 14:31
（1）在我学的操作系统理论术语中，临界区保护方法分为“关闭中断”的和“不关闭中断”的两大类。“不关 ...

感谢杨老师的指教！

Cos***

杨老师说的我都赞同！
中断的阻塞是必然存在的，“真正的零中断延迟”是没有可能的。

“零中断延迟”这个说法，最早我是从 Keil RTX 4/5 的 相关说明中看到的，至于它的出处，想必可能是 Keil。
我所理解的“零中断延迟”，与 Keil 的相关描述类似。


零中断延迟并非是中断响应时间为零，而是指当引入了RTOS以后，中断响应时间仍然能够达到MCU内核特性的响应时间，
即只要中断发生，就能按中断优先级立即抢占。也就是说，中断响应时间不受RTOS影响，与裸机编程是一样的。


按照我的个人理解，所谓“零中断延迟”，最重要的还是“用户中断的响应时间不受RTOS影响”。
如果在“最高优先级中断 或 不可屏蔽中断 中处理临界段”，虽然没有关闭总中断，但却与“关闭总中断处理临界段”的效果相同，
都将导致  用户中断的响应时间受到了RTOS的影响，都是 因RTOS处理临界段而导致用户中断不能实时响应。


至于，由于  用户中断已经响应  而导致的  相同优先级或更低优先级的用户中断不能实时响应，
那是必然会发生的事情，是用户个人的问题了，只要RTOS不会影响用户中断的实时响应就好，这是 CosyOS 的理念。


当然，我并不排斥采用“关闭总中断处理临界段”，和  在“最高优先级中断 或 不可屏蔽中断 中处理临界段”这两种方法，
只是建议  处理临界段的时间要尽可能的短，并把这个时间的最大值告知用户。

Cos***

有时候，用语言是难以描述清楚一个问题的实质的，
但我们可以通过看他是怎么做的，来了解他的 核心设计思想。

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 的 零中断延迟技术，将会理解的更为透彻！

杨***

Cos*** 发表于 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）我将另外用系列文章来讨论“零中断延迟问题”，欢迎大家围观参与。

杨***

Cos*** 发表于 2024-5-4 18:56
有时候，用语言是难以描述清楚一个问题的实质的，
但我们可以通过看他是怎么做的，来了解他的 核心设计思想 ...

中国古人说“它山之石可以攻玉”

中国古人又说“南栀北桔”和“东施效颦”

听谁的？某个电视剧里说的好: “试一试就知道了”。
所以我亲自用“关闭总中断”和“不关闭总中断”两种方法
在STC32G单片机是同时移植了主流的RTOS：
uC/OS-II，同时给出了“微山x51”和“挑战者x51”两个移植版本供大家比较和交流。
对于这两个不同方法的特点和性能比较，我已经发表了系列文章进行了分析讨论。
我还将对采用这两种方法的RTOS进行深入测试，会把测试结果分享给大家

Cos***

杨*** 发表于 2024-5-4 19:44
中国古人说“它山之石可以攻玉”

中国古人又说“南栀北桔”和“东施效颦”

好的杨老师，对相关问题，我要做进一步的和更为全面的，研究、分析、和反思，
不能天天只盯着“零中断延迟”，要用更大的视角来全方位审视 RTOS 的相关问题，
争取在未来能有所突破。

fan***

tzz1*** 发表于 2024-4-8 11:57
嗯,用一段时间看看再说, 我想到几个可能要改善的参考点.

现在看来支持Large模式应该也是有必要的，进一步看看能不能做成 small、large模式可配置

神***

STC8, 用户变量尽量使用 xdata;
STC8, idata尽量给RTOS使用，给堆栈使用

fan***

fanxsp 发表于 2024-5-5 12:04
现在看来支持Large模式应该也是有必要的，进一步看看能不能做成 small、large模式可配置 ...

@tzz1983  ，这个办法好，系统函数全部都指定为 small, 这样系统就不受编译器 small  large  模式的影响，用户可以自由指定编译器的small、large模式，我试一下看。

fan***

神*** 发表于 2024-5-5 14:30
STC8, 用户变量尽量使用 xdata;
STC8, idata尽量给RTOS使用，给堆栈使用

是的，尽量尊守这个原则。