STC 原生RTOS PK 移植RTOS

Cos***

还是杨老师厉害

我在启动文件中把STACK的大小改为了128，所以编译后data比较大。

CosyOS还有些模块未支持可裁剪，如Taskmgr、Debugger、信号量等，还有时间片轮转调度算法等，代码量比较大应该与这些方面有关。

杨老师的示例中，任务栈定义为1024，我改成了128，所以xdata小了很多。

现在任务为静态创建，如果改为动态创建，编译后xdata又会小很多。

总之，随着各种配置方案的不同，资源占用情况都会发生改变。

杨***

CosyOS 发表于 2023-5-20 21:37
还是杨老师厉害

我在启动文件中把STACK的大小改为了128，所以编译后data比较大。

（1）系统堆栈位于IDATA空间的顶部，SP是向上增长的，大小由可以由用户指定，因此在计算RTOS所占用的/DATA/IDATA空间时，应该减去系统堆栈的大小，这里CosyOS为128字节，uC/OS-II为65字节。
（2）用户任务堆栈是用于任务被切换下来时保存任务现场和任务数据的，就像古代盛金币的盒子，只能比实际拥有的大，不能小。在单片机XRAM给定后，笔者习惯将任务堆栈空间开的大一些。因此在计算RTOS系统所占用的XDATA空间时，应该减去用户任务堆栈的大小。这里CosyOS为128x4=512字节，uC/OS-II为1024x3=3072字节。
（3）因此RTOS系统所占的存储空间为：
CosyOS:   data = 249-128=121,  xdata = 1665-512=1153,  code = 16019
uCOS-II:  data = 75-65    =10,    xdata = 4026-3072=954,  code = 10767

（4）说明：uC/OS-II采用大模式，所以占用DATA空间极小。这10个字节的DATA空间为：“R0-R7”这8个寄存器占用了8个字节（第0页），函数重入指针“?C_XBP”占用2个字节。
（5）说明：由于此次移植的uC/OS-II系统，所有系统函数和用户任务均被指定为“可函数重入的”，因此所有的函数的“局部变量”皆是随函数访问动态生成的，不会被计入编译器给出的是“静态变量”空间，这应该是编译器给出的uC/OS-II占用XDATA空间比CosyOS少的原因。

神***

建议杨老师开一贴：
【uCOS-II for STC32 无错误内核源码】
这样RTOS版块就大成的趋势：
FreeRTOS for STC32
uCOS-II    for STC32
CosyOS     for STC32

杨***

神农鼎 发表于 2023-5-21 10:40
建议杨老师开一贴：
【uCOS-II for STC32 无错误内核源码】
这样RTOS版块就大成的趋势：

（1）目前已经给出的uC/OS-II for STC8H的移植仍有一些错误和不完美的地方，等完美后就会移植到STC32的。

（2）我个人认为作为用户软件平台的RTOS，安全性是第一位的，任何已经看到的隐患和瑕疵都应该被改正，这就是完美的标准。
（3）我希望将这个完美的过程奉献给大家，使用户知道自己使用的这个RTOS的边界在哪里，这样将来应用时就不会翻车。

Cos***

CosyOS - 系统全局变量

CosyOS的系统全局变量，在定义时指定了存储域，如  _SYS_MEM_  等，不受内存模型影响。


还有一部分系统变量的存储域可由用户灵活配置（mcu配置头文件），以达到最佳的内存利用率和尽可能的提高性能。


以上是CosyOS的一个特点，好坏不论。当然，这样设计的目的还是为了性能，把系统关键变量定义到data中，以提高性能。

所以，我通常的做法是，先定义STACK的大小，再把剩余的data空间做“内存优化”，进一步提高data的利用率。


任务创建模式的不同，也会对编译后的内存（xdata）占用有着明显的影响。

神***

建议1，永远不要用 pdata, 这是 P2口结合使用的，不要哪个版本的编译器搞乱了 pdata/xdata
===== xdata的速度 》= pdata的速度 ？


思考2，data 只有128给用户，现在 idata 是 256， 用 idata 代替 data  ?

Cos***

神农鼎 发表于 2023-5-21 16:26
建议1，永远不要用 pdata, 这是 P2口结合使用的，不要哪个版本的编译器搞乱了 pdata/xdata
===== xdata的速 ...

下一版升级时，可以取消MCU配置头文件中的所有pdata选项，以后一律不允许使用pdata。
_SYS_MEM_，对于51/251来说，都是data，一般会占用几十个字节。
CosyOS的设计理念是，既然引入了RTOS，那么RTOS将优先占用更高性能的内存（data），
把一部分系统关键变量直接定义到data中，以提高系统性能。
而后，又提供了内存配置选项，允许用户灵活配置一部分系统变量的内存。

如杨老师的测试程序中，进行如下配置后的内存占用情况：




data为182.1，再减去STACK 128，系统关键变量共占用了54.1。
这54.1里面还有两个寄存器库：

Cos***

如果大家认为CosyOS现有设计哪里有不妥之处，请尽管提出来，好在日后改正！

杨***

原生的RTOS与移植的RTOS所占储存空间的比较

（1）CosyOS是原生的RTOS，FreeRTOS移植的RTOS，两者皆有STC32G的版本，下面对两者用C251编译后所占的存储空间进行比较。

下图是CosyOS V1.04版本编译后的截屏图：

下图是FreeRTOS V1.02版本编译后的截屏图：

上面编译结果为：

CosyOS:   data=53.3 edata=1573  xdata=1096  const=860 code=31534

FreeRTOS:  data=15.3  edata=3684 xdata=0    const=255 code=14857

（2）FreeRTOS采取了XSmall模式，没有做额外的声明，全部静态变量和任务堆栈存储在EDATA空间。CosyOS也采取了XSmall模式，但其采用特殊的技术将部分静态变量和任务堆栈存储在XDATA空间。如果比较总RAM空间，二者相差不大，但是考虑到片上EDATA空间成本是XDATA空间的若干倍，因此CosyOS的RAM存储方案有很大的可取之处。

（3）比较CODE空间的大小，CosyOS是FreeRTOS的2倍还多。由于差别巨大，我比较了两者的C251优化等级，FreeRTOS是4级，CosyOS是8级，因此这个差别应该不是优化的原因。

我个人猜测这是两者技术路线上的差别，是CosyOS过分追求“至此，CosyOS又一次完成了突破，使51彻底摆脱可重入栈”造成的。

（4）将FreeRTOS移植到STC32G/F单片机上有两种技术方案（FreeRTOS本身就提供了多种选择），一种是将任务堆栈定义在EDATA空间，对于STC32G/F单片机这是一种“极速方案”，优点是不但整个RTOS程序运行速度快，而且任务切换速度极高，这就是STC主页说的“任务切换时间2.5us/24MHz”的技术原因。这种“极速方案”的缺点是EDATA空间的最多64KB，限制了所有任务的大小。

另一种是将任务堆栈定义在XDATA中的“正常方案”，由于STC32G/F的运行速度很高，任务切换时间也增加不了多少，但是不仅是换用XDATA成本正常，而且每个任务的堆栈空间都可以高达64KB，是未来STC32F8M8M的唯一可选择方案。

建议：STC应同步推出使用XDATA作为任务堆栈空间的FreeRTOS系统。

（5）FreeRTOS是一个很有价值的RTOS，作为移植的STC单片机RTOS，FreeRTOS与uC/OS-II相比有一个巨大优势是其使用授权方式。uC/OS-II的授权方法比较严格，原则上要申报审批，但是FreeRTOS不需要。下图是FreeRTOS的授权方法（其中OpenRTOS是FreeRTOS的付费版本）：

（6）在STC获得OpenRTOS授权之前，可以参考目前FreeRTOS的授权范围：

直接推出上面两种方案的FreeRTOS系统平台，直接命名为“STC-FRTOS”。

Cos***

这个code空间占用大的主要原因找到了：


把“NOOVERLAY”去掉，code立即就小多了。
今天我再好好研究一下这个问题，看怎么处理才好。

另外，由于CosyOS有很多模块未支持可裁剪，所以还是会大一些的。