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

fan***

V1.21
发现并修复一个bug, 请在顶楼下载。

杨***

Cos*** 发表于 2024-5-7 13:07
很多现有的 RTOS，都是墨守陈规，一致采取了 古老的 临界区保护技术（关闭总中断），
并未吸取 Arm 为 OS  ...

很多现有的 RTOS，都是墨守陈规，一致采取了 古老的 临界区保护技术（关闭总中断），
并未吸取 Arm 为 OS 设计的、现代的、OS思想。



你这一杆子打死的人太多了：这个论坛里除了你其他人都是“墨守成规”吗？
论坛外的RT-Thread和其他国内大厂推出的基于ARM和RISC-V的RTOS也都是“墨守成规”吗？

tzz1***

fan*** 发表于 2024-5-8 08:23
V1.21
发现并修复一个bug, 请在顶楼下载。

我发现你的进出临界区的代码很高效。所以我新做的移植参照你的临界区的做法。

现在发现一个有意思的小细节，临界区改成如下这样更快！


#define  OS_ENTER_CRITICAL()    do{EA=0;uxCriticalNesting++;}while(0)
#define  OS_EXIT_CRITICAL()       do{if(!--uxCriticalNesting)EA=1;}while(0)


分析一下： 编译后，进临界区是固定的两条汇编指条，没什么好说的
出临界出，按照我发出这样的出写格式，会被编译为 DJNZ指令，
也就是把 “减1 ，判断，跳转“ 合成为一条汇编指令，这个编译器有时候比我们聪明哈
这样一来， 出临界区也是两条汇编指令。

这将是51核，最快的可嵌套进出临界区办法！

fan***

tzz1*** 发表于 2024-5-8 09:50
我发现你的进出临界区的代码很高效。所以我新做的移植参照你的临界区的做法。

现在发现一个有意思的小细 ...

编译器确实是比我们想象的要聪明。
do{if(!--uxCriticalNesting)EA=1;}while(0)   和  do{if(--uxCriticalNesting==0)EA=1;}while(0) 编译结果是一样的

tzz1***

fan*** 发表于 2024-5-8 10:02
编译器确实是比我们想象的要聪明。
do{if(!--uxCriticalNesting)EA=1;}while(0)   和  do{if(--uxCritical ...

不一样的，==0 因为是整形变量， 会用JZ  JNZ  CJNE   ADD,0XFF 等手段
你看一下编译结果：




用！是逻辑量，再看一下：



当然了，这种细节只是无意中发现的，哪种做法都是对的，并不用太在意

fan***

tzz1*** 发表于 2024-5-8 10:13
不一样的，==0 因为是整形变量， 会用JZ  JNZ  CJNE   ADD,0XFF 等手段
你看一下编译结果：

我的编译结果是一样的啊，我有看过，你的怎么不一样？ 奇怪了。
;         OSExitCritical() ;
                        ; SOURCE LINE # 168
        DJNZ         OSEnterSum,?C0021
        SETB         EA
; }
                        ; SOURCE LINE # 169
?C0021:

杨***

Cos*** 发表于 2024-5-7 12:49
是这样一个原则，外部中断（IRQHandler）的优先等级 应 高于 内核服务 和 任务。
而 内核服务 的优先等级  ...

你在168楼说：“Keil 在此基础上进一步发展出了新一代的 OS模型，可实现“零中断延迟”。”

你在169楼说：很多现有的 RTOS，都是墨守陈规，一致采取了 古老的 临界区保护技术（关闭总中断），并未吸取 Arm 为 OS 设计的、现代的、OS思想。



（1）我不确定Keil是哪一年发明“不关闭总中断”的“零中断延迟”。
（2）但我确定我1980年代使用的PDP-11计算机上的RT-11实时多任务操作系统的临界区保护方法就没有关闭总中断了。
（3）但我确定我1989年参与指导的研究生在PC/AT计算机开发的RTOS-X86的临界区保护方法也没有关闭总中断，他现在已博导退休了。



（4）关于临界区保护是计算机操作系统的基本理论问题，关不关闭总中断的影响早就研究的很透彻了。因此FreeRTOS和uC/OS等RTOS早就留下了接口，让移植者选择临界区保护方法是不是需要“关闭总中断”了。
（5）ARM的Cortex-A/M指令集是一款专门考虑了OS/RTOS用途的指令集，因此这之后的FreeRTOS和uC/OS-III的设计已经充分考虑Cortex-M架构的特点了，它们主流的移植者都选择“关闭总中断”是另有原因的，绝不是“墨守陈规”。
（6）考虑到STC33单片机已经进入测试阶段了，我已经在M3上移植了“关闭总中断”的uC/OS-II，并且测试中断响应的源程序和测试结果已经放在排行榜帖子里了。要不你也把你的“零中断延迟”的M3/M4上的CosyOS-II的测试程序也放上来，和我移植的uC/OS-II比较一下。这样RTX4/5的理念和方法是不是创新，我移植的RTOS是不是“墨守成规”？
比一比不就知道了？用事实说话，行吗？

fan***

fanxsp 发表于 2024-5-8 10:20
我的编译结果是一样的啊，我有看过，你的怎么不一样？ 奇怪了。
;         OSExitCritical() ;
                        ; SOURCE LIN ...

这个我是有专门看过汇编代码，我自已感觉  用 ==0  会直观一点，你的变量类型是不是 unsigned char?

tzz1***

fan*** 发表于 2024-5-8 10:20
我的编译结果是一样的啊，我有看过，你的怎么不一样？ 奇怪了。
;         OSExitCritical() ;
                        ; SOURCE LIN ...

那我就不知道了，
发个版本出来，我们对比一下：

fan***

tzz1*** 发表于 2024-5-8 10:22
那我就不知道了，
发个版本出来，我们对比一下：

版本一样的，你的变量类型是不是 unsigned char?