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

杨***

Cos*** 发表于 2024-5-7 01:29
真正的零中断延迟的确是不可能的，
但 CosyOS 可确保 使用了 CosyOS-II 的用户，
用户中断的响应时间与裸 ...

（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的设计理念我不赞同。

fan***

tzz1*** 发表于 2024-5-7 09:51
我理解的CosyOS, 中断调用系统服务时，仍不受临界区影响的。
他使用的方法是，中断需要用系统服务时， ...

这个我知道，中断响应是不受临界区影响，这时程序可以处理紧急事务，处理紧急事务时，不能调用系统服务，紧接着如果要调用系统服务，那这个要调用的服务也是会被临界区延迟，因为它也要等临界区结束。支持NMI的RTOS，也可以实现部份中断，达到这个效果。

tzz1***

fan*** 发表于 2024-5-7 09:57
这个我知道，中断响应是不受临界区影响，这时程序可以处理紧急事务，处理紧急事务时，不能调用系统服务， ...

这个我也没想到， 不过服务仍属OS范畴，中断响应高于所有OS服务和应用， 这个原则上是没有问题的。

不过有所得，也必有所失。这么一趟弯弯绕，本来很简洁的临界区，处理来就会变得很复杂，笨重，这个就是CosyOS很难处理的麻烦哈

fan***

tzz1*** 发表于 2024-5-7 10:02
这个我也没想到， 不过服务仍属OS范畴，中断响应高于所有OS服务和应用， 这个原则上是没有问题的。

不过 ...

是啊，是有一些好处，但同时也要付出代价，于期这样，还不如提供一些可选择的机制，让用户根据需要，自行选择，这样还简单一点。
中断高于服务，这个是没有错。但是中断的目的，就是要完成紧急事务，完成紧急事务时，也不能调用系统服务，这和用NMI的方法实现“零延迟”的效果是完全一样的。

杨***

tzz1*** 发表于 2024-5-7 09:04
关于“零中断延迟”的说法， 我站队CosyOS
请参照：
https://www.stcaimcu.com/forum.p ... ptid=7724&pid ...

（1）“关于“零中断延迟”的说法， 我站队CosyOS”，呵呵，双标

请问你最新移植的“uC/OS-II@STC8H”为什么不像CosyOS采用“不关闭总中断”的临界区保护方法？既然你们的理念相同，是你的技术不行吗？哈哈，打脸


（2）你站队的说法是指CosyOS的“零中断延迟”的表达，还是我的“高优先级中断零延迟”或者“零中断延迟（高优先级）”表达？你能看出它们之间中文文字意义上有什么不同吗？

杨***

fan*** 发表于 2024-5-7 10:12
是啊，是有一些好处，但同时也要付出代价，于期这样，还不如提供一些可选择的机制，让用户根据需要，自行 ...

“让用户根据需要，自行选择，这样还简单一点” 当然应该，百花齐放，让用户有更多的选择。
不过对于科学问题，要让用户选择，就要使用科学的方式把情况表达清楚，免得产生歧义。如果“零中断延迟”的标题不改，只在文中注明，在网络上会被称为“标题党”

fan***

杨*** 发表于 2024-5-7 10:23
“让用户根据需要，自行选择，这样还简单一点” 当然应该，百花齐放，让用户有更多的选择。
不过对于科学 ...

我刚才讲的和你说的，不是同一个问题。我也认为，"零中断延迟“这个名词容易产生误解。

Cos***

fan*** 发表于 2024-5-7 09:57
这个我知道，中断响应是不受临界区影响，这时程序可以处理紧急事务，处理紧急事务时，不能调用系统服务， ...

是这样一个原则，外部中断（IRQHandler）的优先等级 应 高于 内核服务 和 任务。
而 内核服务 的优先等级 应 高于 任务。
这才有了由上而下的 三层设计（RTX 4/5、CosyOS）：
用户中断层（零中断延迟）
内核服务层（系统中断，占用最低中断优先级）
任   务   层

最早，Arm内核 把 OS 的 系统服务 分为两类，
一类是紧急的、需要尽早执行的，可通过调用 SVC 来间接执行；
一类是允许缓期执行的，可通过触发 PendSV 来挂起执行。
这便有了早期的 Arm设计的OS模型：
SVC（处理紧急的系统服务）
用户中断层
SysTick + PendSV（处理缓期执行的系统服务）
任   务   层

Keil 在此基础上进一步发展出了新一代的 OS模型，可实现“零中断延迟”。
该模型的理论出发点就是：
外部中断（IRQHandler）的优先等级 应 高于 内核服务 和 任务；
而 内核服务 的优先等级 应 高于 任务。

如果对该理论不认同，则无法应用这一类模型在 OS 上。



下面，我再简单介绍一下 Arm内核 对 OS 的 优化设计，和 “安全关键” 的现代OS思想。
“安全关键” 主要包括 两方面内容，空间隔离 和 时间隔离。
下面介绍 空间隔离。

任务中调用的服务，通过调用SVC来间接执行；
中断中调用的服务（中断挂起服务），通过触发PendSV来缓期执行。
实现了 用户代码 与 内核服务 的空间隔离、任务服务 与 中断服务 的空间隔离。（两对空间隔离）

空间隔离的优势：
1、内核服务可以经过充分的测试，从而能使系统更加健壮和可靠。
2、任务无需在特权级下运行，可以运行在用户级（无法直接访问关键寄存器），用户程序无需承担因误操作而瘫痪整个系统的风险。
3、如果在任务中调用中断服务（必将触发PendSV），由于权限不够，会引发总线 fault。
4、如果在中断中调用任务服务（必将触发SVC），由于用法错误，将上访成硬 fault。
从而全面提升整个系统的安全性和可靠性。

RTX的“零中断延迟”，只是在上述“安全关键”的基础上，附加的特性而已。

Cos***

很多现有的 RTOS，都是墨守陈规，一致采取了 古老的 临界区保护技术（关闭总中断），
并未吸取 Arm 为 OS 设计的、现代的、OS思想。
不可否认，关闭总中断的临界区保护技术 的确 是 安全的、可靠的；
但“新思想”，在安全性、可靠性方面，考虑的则更为周全。

Cos***

补充说明：

由于 CosyOS 在设计上 要兼容 8051 和 Arm，
所以，只是部分借鉴了 “Arm 的现代OS思想”，
并未完全照搬，否则是难以应用于51的。

CosyOS 的 “安全运行时”，就是 上述 “安全关键” 中的 时间隔离。