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

Cos***

CosyOS-III Cube 新版刚刚发布，实现了已经通过Cube配置或转码的配置文件，
当工程再次升级安装时，不会再此配置或转码（因为二次转码会乱码）。
通过Cube配置或转码的配置文件，会有一个显著特征：

Cube 就是通过查找 <CubeSet> 来判断，该文件是否已经通过Cube自动配置或转码。



对于51来说，当使用新版Cube升级安装时，编译器配置会自动配置为 NOOVERLAY。
CosyOS-III for 8051，优先推荐 NOOVERLAY方案，此方案易用性较好，而且可靠性最高。

当内存资源紧张时，用户再考虑 OVERLAY方案（虚拟中断 or 手动修改调用树），以节约内存。
当使用 OVERLAY方案时，用户还需查看内存地图，来判断所有函数指针是否使用了内存？
如果用了内存，会存在一定风险，因为C51对函数指针的调用树及覆盖分析有些是错误的，
这也就是为什么C51只有采用 NOOVERLAY方案 才是最可靠的（对于 CosyOS 来说）。


那么CosyOS内核中都哪里会用到函数指针呢？


sv_int_pend_fifo.c 中的所有函数，都是通过函数指针间接调用的，
但它们的调用关系却是正确的，用户不必理会。

通过内存地图可以看出，OS_PendSV_Handler（PendSV中断）调用了 sPendSV_Handler，
而 sPendSV_Handler 调用了 mPendSV_FIFOHandler，
而 mPendSV_FIFOHandler 调用了 _fifo_0_、_fifo_1_，
而 _fifo_0_、_fifo_1_ 调用了 SV_INT_PEND_FIFO，也就是 中断挂起服务_FIFO - 执行函数。
可见，虽然这些函数都是通过函数指针间接调用的，但它们的调用关系却是正确的，覆盖分析不会有错。


但是，所有定时中断钩子、定时查询钩子、定时查询事件，也都是通过函数指针间接调用的，
但它们的调用关系却是错误的（内存地图中 被 ?C_INITSEG 调用），用户需通过内存地图
查看它们是否使用了内存。所以这些钩子的内容要尽量简单一些，以避免用到内存，而且
只有简单了才能高效运行，才符合钩子的意义，因为它们都是在 SysTick中断 中被真实调用的。


再补充一点，通过服务 iPendSVC(fp) 调用的函数，最终是在PendSV中断中通过函数指针间接调用的，
调用关系也是错误的，需格外注意。



- END -

me45***

有RTOS加持后的STC单片机，非常强大

mlkp***

Cos*** 发表于 2023-5-6 13:04
关于内存的占用，我现在还不能提供一个准确的数字，一般情况下，8K内存跑十多个任务还是绰绰有余的。然而 ...

我看STC8H8K64U芯片模版，启动文件配置堆栈为“?STACK          SEGMENT   IDATA”是在IDATA中，IDATA最大256字节，可是IDATA空间很小，担心任务嵌套使用多了空间占用太多，楼主可否出优化任务堆栈放到XDATA空间的版本呢？XDATA空间有8K。

Kevin***

为啥我移植到STC8上会卡死？调试的时候发现会卡死在一个标志判断语句上，移植的是最新的CosyOS III

13***

大家拿到版本3的stc8h案例之后可以运行吗，为什么我的会报错，是因为这个工程需要二次改写才能使用吗

我的项目会报这个错误

Cos***

Kevin*** 发表于 2025-8-3 21:45
为啥我移植到STC8上会卡死？调试的时候发现会卡死在一个标志判断语句上，移植的是最新的CosyOS III ...

可能会有各种原因，可以先检查一下各任务栈size，可以先大一些避免溢出，最大不可超过255.
而后先使用 NOOVERLAY方案。
再检查 系统配置、MCU配置。

Cos***

mlkp*** 发表于 2025-7-29 17:22
我看STC8H8K64U芯片模版，启动文件配置堆栈为“?STACK          SEGMENT   IDATA”是在IDATA中，IDATA最 ...

你的想法很好，但那是不可能实现的。
51先天的架构就决定了，硬件栈必须在IDATA中，硬件栈的最大SIZE 一定会小于 248 Bytes，
这一点是任何人都无法改变的。
但是任务栈却是可以放在XDATA中，事实上CosyOS的任务栈从古至今也一直都是在XDATA中。
任务切换时要保护现场、恢复现场。保护现场时，硬件栈中的内容保存至任务栈；恢复现场时，任务栈中的内容再搬回硬件栈。
默认情况下，CosyOS不使用C51的XBP栈，所以，任务栈中仅保存硬件栈中的内容和可能的极少数的用户自定义的任务切换现场保护寄存器，所以，任务栈最大SIZE为255已经足够用了，所以，任务栈SIZE相关数据类型默认被定义为 uint8_t，也就是任务栈SIZE的最大值为255.

CosyOS-III 新版过几日即将推出，届时，如果用户启用了C51的XBPSTACK的任务切换现场保护，任务栈SIZE相关数据类型将被定义为 uint16_t，也就是任务栈SIZE的最大值可为65535.
原因是，当启用了C51的XBPSTACK的任务切换现场保护时，XBP栈就在当前任务的任务栈中，XBP栈顶指针指向了各个任务栈的末尾处，此时，任务栈中保存的除了硬件栈中的内容外，还包括了XBP栈中的内容，所以，任务栈SIZE有必要允许其大于255，以防任务栈中硬件栈的内容与XBP栈的内容相互覆盖。

总结：
CosyOS-III for 8051，如果不启用XBPSTACK的任务切换现场保护，任务栈SIZE最大可为255.
CosyOS-III 新版即将推出，届时如果启用了XBPSTACK的任务切换现场保护，任务栈SIZE最大可为65535.

Cos***

13*** 发表于 2025-8-3 23:17
大家拿到版本3的stc8h案例之后可以运行吗，为什么我的会报错，是因为这个工程需要二次改写才能使用吗

我的 ...

标准头文件中，屏蔽掉
#include "stdio.h"
#include "intrins.h"
这两个包含，
哪个C文件中需要它们时再单独包含，问题就解决了。

13***

Cos*** 发表于 2025-8-4 01:25
标准头文件中，屏蔽掉
#include "stdio.h"
#include "intrins.h"

好的，感谢，我来试试，这个不关中断还挺神奇的，想学一学

Cos***

CosyOS-III V2.0.0 发布！


1、部分关键字重命名。

2、所有C文件中，条件编译加上了括号。

3、删除了内核文件 sv_int_pend_flag.c、sv_int_pend_flag.h。

4、新增了内核文件 sv_int_pend.h，前缀为“p”的中断挂起服务，均在 sv_int_pend.h 中定义，
     并允许通过挂起服务调用（iPendSVC）间接调用、或在挂起服务钩子（pendsv_hook）中调用。
     当通过挂起服务调用（iPendSVC）间接调用时，仍为中断挂起服务_FIFO；
     当在挂起服务钩子（pendsv_hook）中调用时，为中断挂起服务_FLAG。
     部分服务调整为支持返回，具体包括 PendSV中（p）恢复任务、挂起任务、删除任务、清除阻塞、设置阻塞、设置任务优先级，均返回错误码。

5、部分 中断挂起服务_FIFO 支持错误调用返回，便于用户实现错误处理。
     具体包括 中断中（i）恢复任务、挂起任务、删除任务、清除阻塞、设置阻塞、设置任务优先级、发送消息，均返回错误码。
     系统配置文件中可控制该功能的开启或关闭，默认为关闭。
     回调函数均在 sv_int_pend_fifo.c 中弱定义，并在 ur_api.h 中声明。




6、for 8051，如果启用了XBPSTACK的任务切换现场保护，任务栈SIZE允许大于255，最大可为65535。

7、创建定时中断钩子、定时查询钩子 时，不用再输入钩子名称，由系统自动生成。
     定时中断钩子、定时查询钩子、定时查询事件 函数，在新版中的自动命名规则：
     定时中断钩子：u_timint_##tmid
     定时查询钩子：u_timqry_##tmid
     定时查询事件：u_timqryevent_##tmid