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

WangC***

谢谢

WangC***

老哥有没有考虑创个网站一类的把OS放上去

WangC***

WangC*** 发表于 2023-11-13 23:47
老哥有没有考虑创个网站一类的把OS放上去

找到了gitee上有

WangC***

WangC*** 发表于 2023-11-13 23:47
老哥有没有考虑创个网站一类的把OS放上去

最近一直在看RTOS的,一直苦于不知道怎么移植,API使用都可以看官网来实现.

Cos***

CosyOS-II 已升级至 V1.1.3，除  API用户参考手册外，其它说明文档基本更新完毕。

CosyOS-II V1.1.3 新增及调整功能如下：
1、调整了进入、退出任务临界区函数的形式及功能，
原为两套函数，一套返回void，一套返回bool；
现为只有一套函数，并返回void，当需要返回bool时，用函数类型强制转换。
此法无论哪种内核，均可实现最小的代码量，最佳的性能。

2、系统配置文件中，取消了临界区相关设置，任务临界区与全局临界区都固定支持嵌套功能，最大嵌套深度255。

3、MCU配置文件中，新增配置项：任务栈配置、自定义任务切换现场保护。

4、新增报警：
rts：任务栈重分配发生，虽然成功了，但仍要提醒用户任务栈定义小了。
任务栈重分配机制被设计用来在正式的产品中抵御任务栈溢出的风险，用户在开发测试阶段应避免这种情况的发生。
ots：在概率上、在未来必然会发生的任务栈溢出（虽然现在可能并未发生）。

5、调整了部分API，具体包括：
互斥信号量、计数信号量、二值信号量相关。

互斥信号量仅用于任务中实现互斥访问：
互斥访问：“获取” 与 “归还” 需配对使用，实现互斥访问：
获取：uTakeMut(mut, tc)；
归还：uBackMut(mut)。

二值信号量用于线程同步及互斥访问：
线程同步：“上锁”、“给予” -> “查询”、“等待”、“获取”；
互斥访问：“获取” 与 “归还” 需配对使用，实现互斥访问。

计数信号量用于线程同步及互斥访问：
线程同步：“给予” -> “获取”；
互斥访问：“获取” 与 “归还” 需配对使用，实现互斥访问。
不支持在中断中“获取”。

其实，“给予”、“归还” 本质上做的是一件事，就是释放、发送信号量，但由于CosyOS不关总中断，必须针对“线程同步”与“互斥访问”分别处理。



再补充两个重要说明：

CosyOS-II 在临界区中或关闭总中断时调用服务注意事项

一、在任务中，以下服务不支持在临界区中（包括任务临界区和全局临界区）或关闭总中断时调用：
启动任务：uStartTask(task, status)、uStartTask_Ready(task)、uStartTask_Suspend(task)。
互斥信号量获取：uTakeMut(mut, tc)。
二值信号量等待：uWaitBin(bin, tc)。
二值信号量获取：uTakeBin(bin, tc)。
计数信号量获取：uTakeSem(sem, tc)。
接收飞信：uRecvFetion(tbox, tc)。
接收私信：uRecvTaskMsg(tc)。
接收邮件：uRecvMail(mail, mbox, tc)。
接收消息：uRecvMsg(que, tc)。
等待标志组：uWaitFlagGroup(group, tc)。

二、其它会导致任务调度/切换的服务，虽支持在临界区中或关闭总中断时调用，但也必须等到最终退出临界区或开启总中断后才能切换任务。

CosyOS-II 中断服务调用注意事项

凡事都是辩证的，有一利必有一弊。CosyOS-II 在实现零中断延迟的同时，在服务的调用上，也必然会存在一些限制条件。

• 一、用户中断中写全局变量
  当用户在中断中调用iWriteGVar(gv, lp)、iWriteGAry(gp, lp, size)、iWriteGStr(gs, ls)写一个全局变量时，lp、ls所指向的局部变量要做为专用。
  1、当服务调用以后，该局部变量不可以被改变；
  2、如果某次进入中断以后，该局部变量被更新，必须再次调用相同的服务写同一个全局变量（gv）。
• 二、用户中断中发送邮件
  当用户在中断中调用iSendMail(mbox, mail)发送邮件时，mail所指向的局部邮箱要做为专用。
  1、当服务调用以后，该局部邮箱不可以被改变；
  2、如果某次进入中断以后，该局部邮箱被更新，必须再次调用相同的服务发送邮件至同一个邮箱（mbox）。
• 三、用户中断中读全局变量
  当用户在中断中调用iReadGVar(gv)、iReadGVar(gv, type)读一个全局变量时，
  如果在某个与该中断优先级不同的非最低优先级的中断中会写同一个全局变量，那么仅在下面两种情况下会确保万无一失：
  1、在那个中断中，用于写该全局变量的局部变量为常量（不会改变）；
  2、那个中断的发生频率足够低，可保证在PendSV中最终完成服务（写全局变量）以后，那个中断才会再次发生。
• 四、用户中断中接收邮件
  当用户在中断中调用iRecvMail(mail, mbox)接收邮件时，不同优先级的中断，不可接收来自同一个邮箱中的邮件；
  如果在某个与该中断优先级不同的非最低优先级的中断中会发送邮件至同一个邮箱，那么仅在下面两种情况下会确保万无一失：
  1、在那个中断中，用于发送邮件的局部邮箱为常量（不会改变）；
  2、那个中断的发生频率足够低，可保证在PendSV中最终完成服务（发送邮件）以后，那个中断才会再次发生。
• 五、用户中断中接收飞信
  当用户在中断中调用iRecvFetion(tbox)接收飞信时，不同优先级的中断，不可接收来自同一个信箱中的飞信。
• 总结
  条件一和条件二其实算不上什么条件，只要注意局部变量或邮箱做为专用就可以了。
  条件三和条件四则需要反复揣摩一番，深刻理解其含义，并在实际应用中加以关注。
  

专业版测试程序待过几日再发布新版。

Cos***

CosyOS - 任务管理器 中的 “RAM” 项


示例1：32B/m49B，系统采用每调度监控（假定入栈）计算出的在概率上必然存在的最大任务栈占用为32Bytes，任务栈已 malloc 分配了49Bytes。
示例2：32B/r40B，系统采用每调度监控（假定入栈）计算出的在概率上必然存在的最大任务栈占用为32Bytes，任务栈已 realloc 分配了40Bytes。
示例3：32B/s64B，系统采用每调度监控（假定入栈）计算出的在概率上必然存在的最大任务栈占用为32Bytes，任务栈已 静态 创建了64Bytes。

每调度监控，是每次任务调度时都会监控，并假定本次会切换任务、需要现场保护，计算当前任务需要多大的任务栈。
这种假定在概率上必然早晚都会发生，但不一定是什么时候（也许是即将发生、也许是一万年以后、也许是时间的尽头），
从而提前预判任务栈溢出的风险。

每调度包括定时调度与临时调度，对于定时调度来说，就是系统滴答中断触发的，
所以，用户在开发测试阶段可适当定义一个较小的“系统滴答周期”，可提升“每调度监控”提前预判任务栈溢出风险的机率。

1、当任务栈重分配发生时，就需要重新调整任务栈的size了。
如：32B/r40B，此时就需要重新调整任务栈的大小为至少32个字节。
当这种情况发生时，还会有相应的报警提示用户，rts：任务栈重分配发生，虽然成功了，但仍要提醒用户任务栈定义小了。

2、当 “前面的字节数” 大于 “后面的字节数” 时，就需要重新调整任务栈的size了。
如：56B/m32B，此时就需要重新调整任务栈的大小为至少56个字节。
当这种情况发生时，还会有相应的报警提示用户，ots：在概率上、在未来必然会发生的任务栈溢出（虽然现在可能并未发生）。


任务栈的初始定义

1、对于51及251的MSP模式，当任务创建模式非静态创建时，任务栈的初始定义可以小一些（因为有重分配机制），而后根据监控及报警情况再调整（增大）；
2、对于251的PSP模式及Arm的MSP+PSP模式，任务栈的初始定义一定要够大，否则可能会运行不起来或死机，而后再根据测试情况重新调整任务栈。
3、对于251的PSP模式，由于中断入栈也入任务栈，所以需要用户自己根据中断的使用情况来计算一个中断嵌套入栈的最大size（不必包括最低优先级的中断入栈），
      累加到“前面的字节数”中，看是否会大于 “后面的字节数”，再行调整。


任务栈重分配机制

1、对于8051，当任务创建模式非静态创建时，CosyOS将自动启用任务栈重分配机制，以抵御任务栈溢出的风险。
2、对于80251，当任务栈模式为MSP模式、任务创建模式非静态创建时，CosyOS将自动启用任务栈重分配机制，以抵御任务栈溢出的风险。
3、任务栈重分配机制，在正式的产品中可有效抵御任务栈溢出的风险，但在开发测试阶段建议不要依赖，
      当发现有 任务栈重分配发生 时，就应该及时的重新调整任务栈。


以上所述，对于其它的RTOS来说，未必总是会提供这样的功能，如能善加利用，必然能发挥难以估量的作用。

就简单介绍到这。。。

gzl***

下载学习下，谢谢

Cos***

CosyOS-II 关于 “任务栈size” 的不完整补充说明

1、在开发测试阶段，用户应尽量设法模拟各种情况的发生，最好是频繁发生，包括中断的发生。只要你的产品支持的功能、情况，都要设法模拟到。
2、通过足够时间的测试，统计出各任务在任务管理器当中的“RAM”项中，系统采用每调度监控（假定入栈）计算出的在概率上必然存在的最大任务栈占用，
而后在此值的基础上，再累加一个补偿增量，再重新定义任务栈size。

例如：经过长期的测试以后，某任务的任务栈情况如下：
56B/m64B，
此时，可重新定义任务栈的size为：56 + X；X为补偿增量。
原因是无论 每调度监控 如何的假定入栈，也可能会存在着更大的任务栈需求，只是未能测试到。所以必须增加一定的补偿。
而这个补偿量的大小，每个任务都可根据剩余内存的大小而灵活配置，最好能尽量大一些，尤其是对于没有任务栈重分配机制的情况来说。

没有任务栈重分配机制的情况：
1、任务创建模式为静态创建。
2、251的PSP模式。
3、ARM。


这个补偿增量对于51来说可描述为2的整数倍：2 x N，N为每调度监控未能监测到的N次的函数嵌套调用。
对于251、ARM来说则无法描述。


再有，CosyOS启用“每调度监控”的充分必要条件是：启用任务管理器，即系统配置中，“DEBUG接口设置”必须打勾。
“每调度监控”属于“任务栈监控”，是CosyOS任务管理器的标配选项。

tzz1***

@COsyOS  我记得人好像说过可以用IO中断来做PendSv , 刚才我去试了一下, 结果发现IO中断标志软件写不了, 只能清零, 不能写1, 是不是我哪个环节出错了, 还是本来设定就是这样的  (型号:STC32G12K128  说明一下, 是IO中断, 不是外中断)

tzz1***

tzz1*** 发表于 2023-11-15 15:51
@COsyOS  我记得人好像说过可以用IO中断来做PendSv , 刚才我去试了一下, 结果发现IO中断标志软件写不了, 只 ...

可能我自己的问题, 晚上再看看, 不过我知道有些中断标志是不能写1的, 比如UART3的 S3TI , 清零可以, 写1却没有作用