全局不关总中断的 RTOS，CosyOS-III-V1.2.0, 送 擎天柱-AI8051U转89C52核心板

Cos***

杨*** 发表于 2026-9-23 02:46
（1）我等你这个回复两年了，我很照顾你的面子没有在你帖子里质疑，并且以华山论剑的方式说明这只是技术讨 ...

首先感谢杨老师的提醒，这是我的疏忽。

关于上述两点问题，我再分别针对 STC32G、Cortex-M、RISC-V 等架构做一下适当的补充。
（CosyOS-III 最新版本 v3.1.5）


一、对可重入函数的支持
0、8051/STC8H
需要用户开启 syscfg.h 中的配置项，可重入函数需显示声明为 reentrant。

1、STC32G
STC32G 如果使用 Keil C251（C251 版本 >= 2.0），是直接支持可重入函数的。
可重入栈由 C251 编译器直接实现，是与 ARM 等同的原理，无需 OS 介入，直接即可支持。
但建议用户开启如下选项：全局生成可重入函数

这样在整个工程中，只要是非 STATIC 属性的（#pragma functions (static)）、
未涉及全局公共资源的（如 printf、malloc 等）函数，都将自动成为可重入函数，而不需要用户显示声明为 reentrant。
但这可能会导致一些报错（L127、L128），具体原因和解决方案可参考如下：
全局不关总中断的 RTOS，CosyOS-III-V1.2.0, 送 擎天柱-AI8051U转89C52核心板 - 第112页 - TF卡, SD卡, 文件系统, uCOS/FreeRTOS，GUI-uGFX/U8g2, RTOS 国芯人工智能技术交流网站 - AI32位8051交流社区


2、Cortex-M、RISC-V 等架构
Keil MDK（AC5、AC6）、IAR-EWARM、GCC、MounRiver Studio Ⅱ，等编译器、IDE 皆直接支持可重入函数，无需用户额外操作。


二、高频中断中调用服务
与 上一篇中对 STC8H 的描述基本一致。
但不同的是：
1、同主频下 STC32G 的平均性能会显著高于 STC8H，因此在高频中断中调用 FIFO服务的弊端问题，会有明显改善。
2、Cortex-M、RISC-V32 等都是32位机，最低主频一般 48M，也都有着不弱的性能表现，同样会有明显改善。
3、尤其是当主频达到 上百兆 后，调用一项 FIFO服务的时间，可在 零点几 us 之内完成，改善会更为明显。
4、如果对高频中断的要求较高，如中断周期 1us、必须调用 FIFO服务，采用更高主频、性能更强的处理器即可轻松应对。
总之，在实际项目中，用户仅需关注相关问题并把握“先FLAG，后FIFO”的使用原则，并进行针对性测试，便可防患于未然，有效解决高频中断中调用 FIFO服务 带来的风险问题。


CosyOS-III 最新版本 v3.1.5，还有很多新特性，未来我会陆续介绍。

杨***

Cos*** 发表于 2026-9-23 05:22
首先感谢杨老师的提醒，这是我的疏忽。

关于上述两点问题，我再分别针对 STC32G、Cortex-M、RISC-V 等架 ...

（1）对于有PendSV的Cortex-M 单片机RTOS，FIFO服务不是必须的，它是属于像Linux和Windows这样的OS操作系统的任务调度特征，在Cortex-A 这里架构是的操作系统上应用很正常。
（2）你将它应用到高性能的STC32位单片机和RV32单片机这两种没有PendSV单片机上是一个有价值的探索。
（3）顺带介绍一下，Cortex-A没有PendSV只有同步异常SVC，RV32架构没有PendSV只有机器模式软件中断MSIP（相当于CPU的TRAP指令），
STC32位单片机的80251指令集没有PendSV只有TRAP指令和对应的软中断，但是被厂家屏蔽了。所以你的探索有意义。
（4）建议继续研究深化你的FIFO服务任务调度方法，将你的系统CosyOS直接升级定位为“嵌入式小型实时OS系统”，而不是单片机RTOS。
你可以参考Cortex-A架构的Linux的PREEMRT_RT实时内核补丁的技术。

（5）建议你不要再强调所谓的“不关闭总中断”特征，原因两个：
首先是个OS操作系统比如Linux和Windos都不会关闭总中断，而FIFO服务就是解决的具体方案，CosyOS本来就是一个标准OS的技术方案，强调其实会拉低你的系统档次。
其次强调虽然取悦了一般单片机爱好者（尤其是还没有进阶到RTOS的），但是在懂得计算机操作系统原理的人眼里就是个笑话：你发明了一种吃饭可以不带口水兜的方法是什么意思？幼儿（RTOS）需要带，大人（OS操作系统）不需要带，这不很正常吗？有什么好炫耀的？

Cos***

杨*** 发表于 2026-9-23 12:25
（1）对于有PendSV的Cortex-M 单片机RTOS，FIFO服务不是必须的，它是属于像Linux和Windows这样的OS操作系 ...

感谢杨老师对 CosyOS 相关技术探索精神的肯定，并给出了中肯的建议。
下一步我会认真听取杨老师的建议并继续深化相关技术，
进一步提升 CosyOS 的可靠性。

再次感谢杨老师

喜糖***

神农鼎 发表于 2023-5-6 14:00
有啥在这讨论，官方保驾护航

有最新的教程吗？看的教程和下载到的。函数都不一样，有的有，有的没有，还有没见过的，点击这个博主的名字，想看这个博主发布的其他帖子，说没权限

Cos***

喜糖*** 发表于 2026-10-13 10:59
有最新的教程吗？看的教程和下载到的。函数都不一样，有的有，有的没有，还有没见过的，点击这个博主的名 ...

CosyOS 发展更新速度很快，现已发展到第三代，最新版本是 CosyOS-III v3.1.6。
如果是看的视频讲座，就用当时配套的资料。
虽然最新版本距视频讲座时的版本已相去甚远，但 CosyOS 的基本思想和多数 API 的用法大多没有改变，
看完视频讲座后直接使用最新版本通常不会有明显的障碍。
遇到问题可随时发帖提问，也可加入社区以便获得更为及时的回复。

Cos***

分享一下 CosyOS 近半年来取得的一些主要成就
（CosyOS 最新版本：CosyOS-III v3.1.6 released）


一、增加了新的栈用量检查方法（水印检查），使得对主栈和任务栈用量的检查更为准确，进一步提高可靠性并降低了栈溢出的风险。

二、创建服务功能升级，互斥信号量、二值信号量、计数信号量、飞信、邮箱等，提供了创建不初始化服务，
该功能可用来创建相应的数组，或把它们封装在结构体中（具体用法在 API手册-互斥信号量 中有示例）。

三、重构了移植架构，为使未来的移植工作可以更顺利的进行。


四、中断FIFO服务技术进一步升级，优化了包括中断FIFO服务装载器、中断FIFO服务处理器。
针对 STC32G/251 推出了新的中断FIFO服务互斥访问方案，新增方案包括 [INC]指令、关闭总中断。


五、新增对 RISC-V32 指令集架构的支持，并针对沁恒-青稞 RISC-V，推出了自研先进技术，可实现 CH32V 全程开启硬件压栈。
该技术为纯软件实现，不依赖特定硬件（0x804->bit5），V103、203 等皆可完美支持。
现已全面支持青稞 V2/V3/V4 系列微处理器，并全面支持全程开启硬件压栈。

六、CosyOS-III Cube 正式更名为 CosyOS3Cube。


七、CosyOS3Shell 串口调试工具，闪亮发布！


简介
CosyOS3Shell 是 CosyOS-III 的上位机调试工具，实现任务管理器、命令行、printf 共用同一个串口并分屏显示。
用户可使用该软件来呈现 printf、任务管理器，并进行命令行调试。
软件连同 CosyOS-III 一起打包开放给用户免费使用，绿色免安装。

优势
1、分屏显示解决了串口调试时，多类信息混杂、难以区分的痛点。
2、任务管理器内容刷新时，屏幕丝毫不会滚动或闪烁，用户体验度拉满。
3、高精度时间戳，取自串口线程（而非UI线程）接收包头的时刻，实际误差仅受驱动层影响。
     同时修改 Windows 系统节拍周期为 1ms，软件关闭时恢复默认值（15.625ms）。

详情
1、主窗口包括任务管理器窗口和命令行窗口。
2、命令行支持动态操作任务，包括恢复任务、挂起任务、重置任务、删除任务、清除阻塞、设置任务优先级等。
3、printf 窗口是外挂的子窗口。
     如果用户调试与系统调试共用同一个串口，应打开 printf 窗口；
     如果用户调试与系统调试采用不同的串口，需另外使用其它串口助手来呈现用户打印。


八、优化了 for STC8H 的 demo_debug.c，DEBUG_MODE 为 0 时，允许串口接收。



关于用户调试（printf）与系统调试（任务管理器+命令行）的补充说明
1、用户调试与系统调试应尽量采用不同的串口，这样 DEBUG_MODE 可以安全的使用（1）或（2），性能会大幅提升。
2、如果串口数量紧张，用户调试与系统调试可以共用同一个串口，但 DEBUG_MODE 最好为（0），不要用（1）或（2），
因为用户调试（printf）随时可能会被系统调试的中断打断，导致串口输出内容混乱。
3、如果用户在多个任务中都要 printf，建议给 printf 加上调度锁，以保证线程安全（不会出现打印一半时切换到另一个任务又进行另一个打印）。
示例：
uScheduleLock();
printf("task_1\r\n");
uScheduleUnlock();


稍后会在顶楼发布最新版工程模板，欢迎大家下载试用。

机灵***

Cos*** 发表于 2024-5-25 07:18
关于 CosyOS-II 定时中断 与 定时查询 的一些技术细节，确实是难以用语言来准确描述的。
但之所以会如此设 ...

我是这样理解的，不知道对否?

定时中断       关键在“中断”
                    裸机编程，必须用户设置好定时器，使能中断，等到定时器溢出中断，然后中断里产生标志，取定时操作事务；定时器在初始化 且 设置重载后，一般就不再管它了。
                    现在CosyRTOS，用户也需要相应的设置，才能启动“定时中断”，定时中断了，信号驱动调度器去执行对应的任务(事务)；


定时查询       关键在“查询”
                    裸机编程，查询是安装一定的节奏循环的，这个节奏最直接的就是某个定时器中断里的计数器变量; 定时器在初始化 且 设置重载后，一般就不再管它了。
                    现在CosyRTOS，最直接的节奏基础就是“系统节拍”，只要设置了定时查询，系统启动，就不断执行定时查询 并触发信号执行对应的任务。

机灵***

Yang.*** 发表于 2024-5-31 09:07
发现一个小问题，提醒一下大家

本来我需要2000毫秒采集一次数据，到时考虑到各种误差，我就这么写了一下

uDelay_ms((2000 + 100));  
这样写出错了,以我的经验，我觉得是 宏定义 不严密所导致的，不是调用者的问题！

记得以前书籍上就有例子：   
#define  Get_Max(x,y)   return( (x)>=(y)?(x):(y) )
这样才是严密规范的写法。