排行榜重大宣布：在单片机RTOS领域，STC32G12K128单片机全面碾压 STM32F103C8T6

杨*** · 发表于 2024-4-11 14:52:01

重大宣布：

在单片机RTOS领域，STC32G（STC32G12K128）单片机

全面碾压 M3（STM32F103C8）单片机

为了深刻了解STC32G单片机RTOS的性能，本次测试新增加了笔者的作品

“微山x51 uC/OS-II STM32F103C8 移植版（uCx51-uCOS-II CM3） V1.10”。

测试软件是“Keil MDK”，测试的硬件是STM32F103C8T6单片机，工作主频为72MHz。

将测试结果归算到24MHz（测量时间x3）参加排名，结果排名垫底！

STC32G单片机RTOS实时响应时间测试 2024年4月18日排行榜

为了使大家能更好地了解STC32单片机上的各个RTOS的特色，笔者用自编的测试程序对STC单片机上移植的uC/OS-II和原生的CosyOS-II等RTOS的“中断实时响应时间”和“任务切换实时响应时间”这两个指标进行了测试，测试结果统一换算到24MHz主频，排名如下：

==== RTOS实时响应时间 2024年4月18日排行榜 =========

排名中断响应任务切换时间最大关闭时间* 作者作品

1 6.221微秒 6.221微秒 0（不关闭） 杨为民挑战者x51(TZZx51-uCOS2) V3.30

2 8.500微秒 7.875微秒 1～2微秒 TZZ1983 uCOSII_STC251(No_PendSv_V1.00)

3 9.375微秒 7.500微秒 0（不关闭） CosyOS CosyOS-II-STC32G-TEST-V2.1.3-20240410

4 9.875微秒 7.500微秒 1～2微秒 TZZ1983 uCOSII_STC251(PendSv_V1.08)

5 10.000微秒 7.500微秒 1～2微秒 TZZ1983 uCOSII_STC251(PendSv_V1.00)

6 11.000微秒 8.125微秒 1～2微秒熊仔熊仔版 uC/OS-II STC32G

7 11.625微秒 11.375微秒～10微秒 TZZ1983 FreeRTOS@STC32G(PendSv)

8 13.997微秒 13.997微秒 1～2微秒杨为民微山x51 uC/OS-II EX

9 21.750微秒 19.125微秒～12微秒 杨为民 微山x51 uC/OS-II CM3

注：最大关闭时间* 为RTOS系统因临界区保护最大关闭总中断的时间

附件10_RTOS_实时响应时间测试_TZZ1982_FreeRTOS_PendSv_240418.rar (1.08 MB, 下载次数: 7)

==== RTOS实时响应时间 2024年4月15日排行榜 =========

排名中断响应任务切换时间最大关闭时间* 作者作品

1 6.221微秒 6.221微秒 0（不关闭） 杨为民挑战者x51(TZZx51-uCOS2) V3.30

2 8.500微秒 7.875微秒 1～2微秒 TZZ1983 uCOSII_STC251(No_PendSv_V1.00)

3 9.375微秒 7.500微秒 0（不关闭） CosyOS CosyOS-II-STC32G-TEST-V2.1.3-20240410

4 9.875微秒 7.500微秒 1～2微秒 TZZ1983 uCOSII_STC251(PendSv_V1.08)

5 10.000微秒 7.500微秒 1～2微秒 TZZ1983 uCOSII_STC251(PendSv_V1.00)

6 11.000微秒 8.125微秒 1～2微秒熊仔熊仔版 uC/OS-II STC32G

7 13.997微秒 13.997微秒 1～2微秒杨为民微山x51 uC/OS-II EX

8 21.750微秒 19.125微秒～12微秒 杨为民 微山x51 uC/OS-II CM3

注：最大关闭时间* 为RTOS系统因临界区保护最大关闭总中断的时间

附件9_RTOS_实时响应时间测试_微山x51_ARM_M3_V11_240415.rar (6.27 MB, 下载次数: 4)

====RTOS实时响应时间 2024年4月12日排行榜 =========

排名中断响应任务切换时间最大关闭时间* 作者作品

1 6.221微秒 6.221微秒 0（不关闭） 杨为民挑战者x51(TZZx51-uCOS2) V3.30

2 8.500微秒 7.875微秒 1～2微秒 TZZ1983 uCOSII_STC251(No_PendSv_V1.00)

3 9.375微秒 7.500微秒 0（不关闭） CosyOS CosyOS-II-STC32G-TEST-V2.1.3-20240410

4 9.875微秒 7.500微秒 1～2微秒 TZZ1983 uCOSII_STC251(PendSv_V1.08)

5 10.000微秒 7.500微秒 1～2微秒 TZZ1983 uCOSII_STC251(PendSv_V1.00)

6 11.000微秒 8.125微秒 1～2微秒熊仔熊仔版 uC/OS-II STC32G

7 13.997微秒 13.997微秒 1～2微秒杨为民微山x51 uC/OS-II EX

注：最大关闭时间* 为RTOS系统因临界区保护最大关闭总中断的时间

附件7_RTOS_实时响应时间测试_CosyOS_V213_20240410_240412.rar (4.06 MB, 下载次数: 7)

附件8_RTOS_实时响应时间测试_挑战者x51_V330_240412.rar (137.45 KB, 下载次数: 10)

==== RTOS实时响应时间 2024年4月11日排行榜 =========

排名 中断响应 任务切换时间 作者作品

1 8.500微秒 7.875微秒 TZZ1983 uCOSII_STC251(No_PendSv_V1.00)

2 9.875微秒 7.500微秒 TZZ1983 uCOSII_STC251(PendSv_V1.08)

3 10.000微秒 7.500微秒 TZZ1983 uCOSII_STC251(PendSv_V1.00)

4 11.000微秒 8.125微秒熊仔熊仔版 uC/OS-II STC32G

5 13.997微秒 13.997微秒杨为民微山x51 uC/OS-II EX

6 21.125微秒 20.250微秒 CosyOS CosyOS-II-STC32G-TEST-V2.0.1-20240318

附件1_RTOS_实时响应时间测试_微山x51_EX_240411.rar (89.25 KB, 下载次数: 6)

附件2_RTOS_实时响应时间测试_熊仔版_STC32G_240411.rar (656.4 KB, 下载次数: 6)

附件3_RTOS_实时响应时间测试_TZZ1982_No_PendSv_240411.rar (1.11 MB, 下载次数: 6)

附件4_RTOS_实时响应时间测试_TZZ1982_PendSv_V100_240411.rar (1017.33 KB, 下载次数: 9)

附件5_RTOS_实时响应时间测试_TZZ1982_PendSv_V108_240411.rar (1.13 MB, 下载次数: 7)

附件6_RTOS_实时响应时间测试_CosyOS_V201_20240318_240411.rar (4.15 MB, 下载次数: 7)

Cos*** · 发表于 2024-4-17 13:54:17

如果放在相同的主频，ARM的综合性能明显不及STC32，
这一点无论是从理论上还是实践上都能证明。

我早前就做过这方面的对比测试，用CosyOS专业版测试程序，
STC32G主频24M，STM32F407主频168M，主频高出7倍，
平均测试分数（性能）仅高出4倍左右。

个人见解，ARM的强项就是可以上很高的主频，用快跑的方式达到高性能。
究其根本原因，我认为主要还是因为STC的CISC架构支持对内存的直接访问和运算，
而RISC架构必须通过寄存器中转，即只能通过寄存器间接访问内存并在寄存器上运算。

我认为51、251最牛x的地方还是bit，不仅能直接访问，
还能直接做条件判断并跳转：JB、JNB、JBC。

尤其是JBC指令，条件判断、条件分支、清除条件，一石三鸟，简直就是神操作！
还有DJNZ、CJNE等指令，也都属于一石三鸟类型，异常强大！

STC开拓创新、勇攀高峰，针对MCS251发展了自己的微架构，
STC32内部数据总线为32位，可一次性完成对1、2、4字节内存数据的读写，
再结合直接内存访问和运算，使得STC32展现出超乎想象的强大性能！

STC32 / STC8，永恒的经典！

以上所述纯属个人观点，有不妥之处还请谅解。

杨*** · 发表于 2024-4-11 14:52:36

本帖最后由杨为民于 2024-4-11 21:53 编辑

单片机RTOS“实时响应时间”的定义与测量方法

（1）众所周知对于单片机RTOS的最重要指标是对事件发生的“实时响应时间”，但是什么是RTOS的“实时响应时间”，业界有各种说法。笔者先用逻辑排除两个可能：

首先不可能是正在运行的用户任务对事件的响应时间，比如用循环语句不断地检测某个条件（来判断事件是否发生）成立进而做出相应的处理。因为用户任务是用户自己编写的程序，其响应时间长短不属于RTOS系统本身。

其次不可能是“中断响应时间”。当一个事件发生后，对应的中断是否能够发生，依赖于很多硬件和软件条件，比如事件中断的优先级高低和用户是否关闭了中断，这些也不属于RTOS系统本身。

（2）因此笔者任务单片机RTOS对事件发生的“实时响应时间”指的是将“休眠的任务”唤醒到执行状态的时间。

唤醒任务分为两种情况：一种情况是中断内唤醒，比如事件发生导致对应的中断发生，在ISR内利用“中断唤醒”功能将高优先级的正在等待的休眠任务唤醒。比如异步通信（CAN...）接收到一帧数据产生中断需要唤醒相应的任务来处理。

另一种情况是中断外由当前正在执行的任务唤醒。比如要调用异步通信（CAN...）发送程序来发送控制信息。

（3）下面是测量被中断唤醒任务所需要的时间的RTOS程序：

任务A休眠等待在第24行程序处。P01是中断唤醒测量端口标志，任务A被唤醒后的第一行程序（26行）将其清零。

下图是中断内唤醒任务的ISR程序：

其中第71行设置P01=1，第72和73行是调用“OSTaskResume(2)”函数来唤醒任务A，第76行是调用“uCx51_IntSched()”函数来进行中断内任务切换，实现唤醒任务A的功能。测试P01端口的正脉冲宽度就可以得到“单片机RTOS的中断实时响应时间”

（4）下面是测量非中断唤醒任务所需要的时间的RTOS程序：

其中任务B休眠等待在第45行程序处。P03是非中断唤醒测量端口标志，任务B被唤醒后的第一行程序（47行）将其清零。

（5）在任务C中第71行设置P03=1，第72是调用“OSTaskResume(3)”函数来实现唤醒任务B的功能,由于任务B的优先级3高于任务C的优先级4，所以任务就被RTOS任务调度程序调度到任务B开始继续执行。因此测试P03端口的正脉冲宽度就可以得到“单片机RTOS的任务切换实时响应时间”

（6）下面是对微山x51 uC/OS-II 进行实测的波形：

对第1和第3通道的正脉冲进行测量得到：主频为33.1776MHz

中断实时响应时间为10.125微秒。

任务切换实时响应时间为10.125微秒。

杨*** · 发表于 2024-4-11 14:53:33

本帖最后由杨为民于 2024-4-22 00:56 编辑

致歉：由于经验有限，经事后查明笔者帮熊仔网友写的测试程序严重背离作者意愿，非真实结果，特此向熊仔网友道歉。

说明：以后排行榜只接受本尊亲自提交的测试。

STC8H系列单片机 RTOS实时响应时间测试 2024年4月22日排行榜

为了使大家能更好地了解STC8H单片机上的各个RTOS的特色，笔者用自编的测试程序对STC8H单片机上移植的uC/OS-II和原生的“天山x51”等RTOS的“中断实时响应时间”和“任务切换实时响应时间”这两个指标进行了测试，测试结果统一换算到24MHz主频，排名如下：

====STC8H系列单片机 RTOS实时响应时间 2024年4月22日排行榜=========

排名中断响应任务切换时间最大关闭时间* 作者作品

1 15.625微秒 14.000微秒～3微秒 fanxsp 51MCU专用RTOS TinyRTOS51

2 23.500微秒 20.500微秒 0（不关闭） CosyOS CosyOS-II-STC8H-TEST-V2.2.1-20240421

3 54.950微秒 44.755微秒～10微秒杨为民微山x51 uC/OS-II STC8H

4 55.469微秒 60.480微秒～10微秒杨为民天山x51 RTOS STC8H

5 92.448微秒 95.904微秒～15微秒杨为民泰山x51 RTOS STC8H（使用长缨8编译器+STC IDE）

注：最大关闭时间* 为RTOS系统因临界区保护最大关闭总中断的时间

附件25_RTOS_实时响应时间测试_泰山x51_STC8H_240418.rar (2.83 MB, 下载次数: 5)

附件26_RTOS_实时响应时间测试_TinyRTOS51_STC8H_240418.rar (197.91 KB, 下载次数: 4)

附件27_RTOS实时响应时间测试_CosyOS-II-STC8H-TEST-V2.2.1-20240421.rar (405.79 KB, 下载次数: 2)

====STC8H系列单片机 RTOS实时响应时间 2024年4月16日排行榜=========

排名中断响应任务切换时间最大关闭时间* 作者作品

1 37.375微秒 36.250微秒 0（不关闭） CosyOS CosyOS-II-STC8H-TEST-V2.1.3-20240410

2 54.950微秒 44.755微秒～10微秒杨为民微山x51 uC/OS-II STC8H

3 55.469微秒 60.480微秒～10微秒杨为民天山x51 RTOS STC8H

注：最大关闭时间* 为RTOS系统因临界区保护最大关闭总中断的时间

附件21_RTOS_实时响应时间测试_微山x51_STC8H_240416.rar (83.8 KB, 下载次数: 4)

附件22_RTOS_实时响应时间测试_天山x51_STC8H_240416.rar (182.12 KB, 下载次数: 4)

附件24_RTOS实时响应时间测试_CosyOS-II-STC8H-TEST-V2.1.3-20240416.rar (352.48 KB, 下载次数: 4)

杨*** · 发表于 2024-4-11 14:54:02

本帖最后由杨为民于 2024-4-12 21:46 编辑

2024年4月12日排行榜点评

（1）大家都使用同样的开源代码“UCOS2”，但是不同的人在同一硬件平台STC32G上移植出来RTOS的指标特性是不一样的。
结论：不同的人，为了不同的移植/设计目标，采用了不同的技术路线，移植出来的效果自然就会不一样。用定量的指标来统一衡量移植版和其他RTOS的特性，就会显示出差别。
（2）使用同样的指标对不同的RTOS进行统一测量，然后按测量结果排序，自然就有了排名前后。上过学的大家潜意识里习惯了“排名前的比排名后的RTOS要好”，但是对于软件产品好和差却未必按排名。
在这个用户需求多元化的今天，一个硬件产品比如单片机，是不是按主频高低排名越高越好？是不是按内存大小排名越大越好？肯定不是，硬件是合适产品应用就最好。
同样一个软件产品比如RTOS，是不是实时响应时间越短越好？肯定也不是，软件产品是达到移植/设计目标就最好。

（3）点评排行榜最后一名《微山x51 uC/OS-II EX》。这是我为大家讲解如何从现有的uC/OS-II 51移植版先移植到STC8H系列单片机，然后再移植到STC32G系列单片机上的系列文章中的一篇。因此这个EX版本的所有汇编语言部分除了“PUSH”和“POP”指令，全部与STC8H版本一样，只使用了R0-R7这几个寄存器，而且对EDATA区域的变量和指针的存取仍然只使用“MOVX”指令，没有使用80251的“MOV @WRi”EDATA专用指令，所以程序效率太低，自然就排名最后了。
结论：如果从EX版的设计目标“为将STC8H的RTOS移植到STC32G上搭一座桥”来看，已经达到了。整个移植部分重点在解决8051与80251寄存器现场问题，而数据处理仍然保留了8051汇编程序。所以对这个EX版虽然是最后一名，但是我很满意。
（4）点评排行榜第一名《挑战者x51(TZZx51-uCOS2) V3.30》。这个作品是按照“软件产品”的标准来研制的，其设计目标有3个：
首先是让用户自由地关闭和打开“总中断”，且用户关闭总中断的时间不受限制，并且用户关闭总中断后，系统节拍处理不受影响，任务调度不受影响。
其次是移植的RTOS在工作期间不关闭总中断，实现用户中断零延迟。
最后是“唤醒任务的实时响应时间”尽可能短。
结论：这3个目标都达到了，因此我也很满意。

解密：实现第一个目标，技术上系统节拍等处理采用“STC单片机专门为RTOS设计的定时器0的模式3--不可屏蔽中断的模式”。

实现第二个目标，技术上对于临界区保护采用“非关闭总中断”的方法而已。

实现第三个目标，技术上人工优化程序设计。

（5）排名的共同规律：排名前1、2的在切换任结论务时都采用的“No PendSv”的“直接切换法”。

而排名前3、4、5、6的在切换任务时都采用的“PendSv”的“软中断替代法”。

结论：由于“软中断替代法”对于中断唤醒任务情况，用户中断C251编译器保存和恢复了一次寄存器现场，而在切换任务时，“PendSv”软中断又保存和恢复了一次寄存器现场，

而“直接切换法”只保存和恢复了一次寄存器现场，因此“软中断替代法”多了一次中断，自然“中断实时响应时间”要长了。

结论：无论那种方法，非中断的任务切换都是只保存和恢复了一次寄存器现场，所以第3、4、5名的“任务切换时间”都是7.500微秒。

（6）各位本尊，请在跟帖中介绍一下自己的作品

Cos*** · 发表于 2024-4-11 16:21:50

本帖最后由 CosyOS 于 2024-4-11 18:16 编辑

1、CosyOS-II V2.0.1版测试程序，默认启用了任务管理器、滴答钩子、全局变量钩子、中断服务的同步测试，
会对测试结论造成一定的影响，尤其是统计求平均时间，影响可能会很大。
开启任务管理器后，每次任务切换都要做很多附加的工作，造成任务切换时间延长。
如“每调度监控”、“入栈监控”、“计算CPU使用时间”、“任务PC监控”等。

2、CosyOS-II 自 V2.1.0 版本开始，采用尤为高效的任务调度算法，任务调度与切换性能大幅提升！
任务切换时间较以前版本会有一个很大的提升。

下面，我将把杨老师修改后的测试程序调整为CosyOS-II 最新版V2.1.3，并根据本次的测试要求优化配置选项，
届时烦请杨老师不辞辛劳，再度评测。

Cos*** · 发表于 2024-4-11 17:19:00

本帖最后由 CosyOS 于 2024-4-11 18:56 编辑

测试程序已就绪，请杨老师评测：

RTOS_实时响应时间测试_CosyOS_V213_20240410_240411.rar (4.06 MB, 下载次数: 9)

测试程序配置情况如下：

系统配置：
1、系统时钟24MHZ，系统滴答周期1ms。
2、全局时间片，100ms。
3、共4个用户任务：TASK_0、TASK_A、TASK_B、TASK_C；2个系统任务：Starter、Sysidle。
启动任务完成后，Starter被自动删除。
4、禁用安全运行时，禁用任务管理器，禁用所有钩子函数，禁用用户动态内存分配，禁用软件RTC。
5、软件定时器均设置为16位。
6、启用所有线程通信工具。

MCU配置：
Code Rom Size：Large
4 Byte Interrupt Frame Size：打勾
内存方案配置：方案一：PSP; XSmall; near static & malloc, ptr-2

编译器设置：
CPU Mode：Source
Memory Model：XSmall
Code Rom Size：Large
4 Byte Interrupt Frame Size：打勾
优化等级：7级speed
Generate reentrant functions：打勾
Alias checking on pointer accesses：不打勾
L251 Misc：REMOVEUNUSED

Cos*** · 发表于 2024-4-11 19:10:12

本帖最后由 CosyOS 于 2024-4-11 19:56 编辑

我已经用我那老旧的示波器看了一下，
中断实时响应时间：9.6us左右；
任务切换实时响应时间：7.6us左右；
由于设备比较落后，这个时间是通过目测脉冲宽度得来的，会有一定误差。
准确时间等待杨老师公布最终结论。

tzz*** · 发表于 2024-4-11 19:39:56

本帖最后由 tzz1983 于 2024-4-11 19:42 编辑

杨老师辛苦了, 感谢杨老师的测评, 让大家对任务切换时间有个具体的认识.

任务切换时间如何测量? 对此好像没有一个统一的标准.
接下来就如何测量任务切换时间, 发表一些个人的观点.
早些时候 ,杨老师在分析替代法一文中,测量的任务切换时间为1.125微秒 (33M主频时).
今天看到新的测量结果是8.500微秒(24M主频), 炸一看, 吓一跳呀, 怎么会相差这么多!
于是我下载了代码分析了一会, 原因是对"任务切换时间"的定义不同!

之前的测量方法, 仅包含了"任务切换核心之切换上下文"那一部分的时间.

本帖新的测量方法,包含了激活任务的方法,比如 (OSTaskResume()),
这其中又包含了OS的一些内部服务, 然后再加上任务切换本身.
这就不难理解为什么偏差这么多了.

我支持杨老师的测量方法, 这样可以很直观的看出一个任务切换到另一个任务所需的时间. 而不是只关心"切换上下文".

但是此方法也有一个缺点,
比如: OSTaskResume() 和 OSSemPost() 都可以激一个任务,
但是显然用两个方法会得到不一样的结果. 因为他们内部除了切换任务外, 还会包含一些其它的OS服务.
这还只是同一个OS, 要是不同的OS, 测量的数值可能相差要更大了.
即如此, 又如何来定下一个可以统一认可的标准呢?

同上: 引导任务进入阻塞方法的方法也有多种.

tzz*** · 发表于 2024-4-11 20:19:45

本帖最后由 tzz1983 于 2024-4-11 20:25 编辑

关于OS响应时间的一点个人理解:

在说OS响应时间之前, 先说说中断的硬件响应时间,
假设一个中断没有被屏蔽，并且没有被同级或更高级的中断阻塞。
从中断标志就绪至执行第一条中断代码之间的时间, 叫中断响应时间,
这个时间一般是几个时钟到几十个时钟之间.

由于硬件响应时间无法用软件优化来改变, 所以当我们评价一份软件(OS)对中断响应的影响时,
应该除去硬件响应时间, 即不考虑硬件响应时间.
(比如CosyOS说是0中断延迟的, 我认为这种叫法是合理的. 即软件没有引起额外的响应延时).

现在可以给OS响应时间来一个定义: 即可能的, 由OS引起的最大的额外中断响应延时, 即为OS的响应时间.

在使用OS以后,  引起OS中断响应额外延迟的, 一般是指临界区引起的中断响应延迟.
(中断被同级或更高级中断阻塞而不能触发响应的, 不计入OS响应延迟, 因为即便是没有OS, 也会有这种情况,  这个锅OS不背)
所以临界区就是一把双刃剑, 用好了很舒服, 用不好就要自废武功。

一般商用实时OS都有一个最大响应延迟时间指标, 这个指标也是商用OS的一个重要指标.

那么如何对最大响应延迟来测量呢, 其实实测这个东西很难的.
一个完整的OS代码里, 可能包含了几百个临界区. 并且最坏的情况也不可能被轻易的尝试到.

话说回来,  这个东西虽然不好实测, 但理论分析却很容易,
一般是OS源码内最长执行时间的临界区代码, 就是最大的响应额外延迟.

Cos*** · 发表于 2024-4-11 20:38:23

本帖最后由 CosyOS 于 2024-4-11 20:41 编辑

tzz1983 发表于 2024-4-11 20:19
关于OS响应时间的一点个人理解:

在说OS响应时间之前, 先说说中断的硬件响应时间,

做为专业的RTOS，这个 “最大关闭总中断时间” 或 “最大中断响应延误时间”，
应由RTOS的开发者提供给用户，用户根据这个参数来判断，
高速中断是否有丢失响应的风险？
中断的延误处理时间能否满足实时性要求？

		自动登录	找回密码
密码			立即注册

排行榜重大宣布：在单片机RTOS领域，STC32G12K128单片机 全面碾压 STM32F103C8T6

点评

点评

点评

点评

点评

点评

排行榜重大宣布：在单片机RTOS领域，STC32G12K128单片机全面碾压 STM32F103C8T6