UCOSII - STC32G12K128 移植

杨***

神*** 发表于 2023-9-14 18:16
我请教个其他问题：
我们STC8H8K64U/STC32G12K128的【定时器0的模式3】，
是不可屏蔽的16位自动重装载定时 ...

在RTOS/DOS中应该是必须的，只是目前我们还在基础研究普及阶段，没有上升到高端应用产品阶段：

（1）用于RTOS的定时器。最近在讨论的关闭中断的临界区保护和中断嵌套保护，一旦停了中断，那些软件定时器就漏计数了，严重影响系统时基精确性。因此FREERTOS和UCOS都把相关部分独立为“TIMER.C”，相关函数应该在不可屏蔽中断运行。
（2）目前我们的RTOS没有像软件狗一样的出错处理机制，发生严重故障时没有软件接口去处理，未来的RTOS我会把这部分加进去的。
（3）本来操作系统是需要这种中断来进行任务调度的，但是目前前面讨论的两种类型任务切换方法都还不适合在不可屏蔽中断中应用，但是以后还会出第三种任务切换方法的RTOS，到时候这个中断就有用武之地了。
（4）这个功能先这样保留着，遥遥领先的硬件肯定会配上遥遥领先的软件的

tzz1***

杨*** 发表于 2023-9-14 15:01
“杨老师, 这是为何呢? ”——你的意思其实是：我为什么盯着你不停地说，口气又不好，而且经常说的还不对 ...

下班了, 休息一会了, 想着杨老师的 “临界区保护嵌套测试程序”  , 于是又认真回顾了一下前面的几贴, 本以为杨老师发了测试代码被我疏忽了, 然而并没有可运行的代码, 只是几张代码截图, 并且大多数话题前面都已经说过.

熊仔是一个做事很认真的人, 像是个孩子, 他说他在嵌套时遇到了问题, 然后杨老师也来了个"估计你那个程序测试通不过, STM32的例子也不一定能通过" . 现在我真的怀疑了, 难道你们手上真的憋了什么大招, 我完全够不着的那种大招? 如果真的有, 那就直接说出来吧, 也不用吊着我了,

还是一件一件的来说吧:


一. 我是认为任务切换是不会嵌套的, 但你们说任务切换会嵌套, 我认真想了一下, 就按照你们的思维来, 切换方式也用你们那种代码方式, 从而又可分为两种情况: 1.任务级的主动做任务切换, 用的一般是OSCtxSw()函数,  而一旦进入OSCtxSw(), 就是进入了切换序列, 在没有执行完本函数之前不会返回, 怎么可能会有别的任务级代码嵌套调用OSCtxSw()呢, 根本不可能发生嘛. 这时你肯定会说了, 任务级不行, 那中断行啊, 开玩笑, 用这种方一旦进入切换序列, 必须得关中断. 原因是中断肯定不知道任务级的切换. 所以必须屏蔽中断, 否则就起飞了. 最后得出结论, 中断也不能使任务切换发生嵌套. 2, 中断级的主动任务切换, 对于大多数OS, 其实本身都已经考虑到了中断嵌套, UCOS 也是如此, 比如说那个中断嵌套计数器,(是一个8位的全局变量) 就是为了防止嵌套中断时, 直接返回任务级, (当然他还有一些别的作用,这里不说) . 所以说, 中断主动任务切换也不会发生任务切换嵌套 . 即如此, 那你们的任务切换嵌套又从何而来呢. 这本身就是个伪命题 ,没什么好研究的, 当然, 也期盼你能真正的驳倒我,才能共同进步. (这里又多说一点, 用你们这个方法切换任务的确是要全程临界段的, 但是不代表别的方法也需要全程开临界段,这点放到最后来说)



二. 临界区保护嵌套. 这个应该是和进出临界段的方式有关的, UCOS定义了三个模式, 其中模式三是支持临界区嵌套的, 那即然如此, 怎么又会通不过了呢. 是我有未想到的大疏忽 , 还是你测试的出发点本来就有问题, 其实我大至已经估算到了,你所说的问题, 可能只会出现在你那个特定的方法上. 然而我并不十分了解你的方法, 所以不再各说各话了吧. 如果你说的是个普适性问题, 那么你用实例来说明, 不要闹乌龙. 也不要用你特定的格局来说明问题, 所举的例子也需要是普适性的例子. 你说UCOS有重大BUG, 并且是从娘胎里就带来的, 但光UCOSII就有那么多版本, 并延续了那么多年, 难道这么明显的东西就只能你发现? 又或者说有别的人已经发现了, 但是就是不说, 也不改, 直到等着你来揭开迷底. 是个人认知的局限还是盲目自信?


三, 再说任务切换, 上面第一点已经说了, 用你们那个方法切换任务是不会发生嵌套的, 那用中断的方法就更不用担心了, 甚至中断嵌套计数器都可以不用, 自身的中断代码又怎么可能打断自身执行顺序呢, 无非是在执行过程中, 中断标志又被重新置位了,退出后又重新来了一次. 又或者被高优级中断打断, 回来以后继续工作. 特别说明一下, 用这种方法, 如果正在任务切换, 并且发生了中断嵌套, 高优先级中断是不会直接返回到任务级的, 他遵循的是, 从哪来的, 回到哪去, 除了占用了一此执行时间以外(栈也会有额外使用), 别的都没变. 所以这种方法并不需要全程开临界段. 你也不用担心他会切换任务, 或都说他调用的代码间接的,隐性的切换任务, 不管怎么样, 它要切换任务(其实只是做了个标志, 表明了它的需求), 最终的切换还是那个最低级的, 任务切换中断函数, 你们都是高级中断, 苦活累活就让我这个最低级的来干吧^^
杨老师比较认死理, "一直坚持操作系统理论里“任务切换不可被打断”原则"  , 这个话题呢, 虽小, 并且实际上全程临界段也不会有太多的开销, 所以各人玩各人的吧, 喜欢怎样就怎样. 当然了, 熊仔和杨老师的例子肯定不能开着中断切换任务, 这是由于他们的切换机制造成的.
但是, 你有没有发现FREERTOS那个不受OS控制的高优先级中断这个理念, 虽然说不适用51核, 也不能用到251核上. 但是, 不受OS控制这个概念, 是不是可以反面映证任务切换是可以被打断的(还是那句话,你可以打断我,但返时不要改变我什么,就不会有问题), 当然为了不和OS产生冲突, 相应的代价是不能直接或间接调用OS系统函数或应用. 中国文字博大精深, 一不小心就说错话, 与其说任务切换不可被打断,  不如说, 大多数情况下是不可以被打断的,  但条件成熟了呢, 还是可以被打断.

杨***

tzz1*** 发表于 2023-9-14 22:28
下班了, 休息一会了, 想着杨老师的 “临界区保护嵌套测试程序”  , 于是又认真回顾了一下前面的几贴, 本 ...

怀疑人生是新人生的开始，发现问题是解决问题的开始，看到不一样的风景是驱动探索者的永恒的动力

熊***

由于是第一个任务入口，DR4~DR28没使用到传参，堆栈初始化的时候初始化是0，其实影响也不大，任何值都可以。
对于第1个任务，直接RETI中断返回就好了，问题都不大。

tzz1***

熊*** 发表于 2023-9-16 12:29
由于是第一个任务入口，DR4~DR28没使用到传参，堆栈初始化的时候初始化是0，其实影响也不大，任何值都可 ...

这个我知道 , 没关系的, 只有第一个参数 R0-R3是有效的, 其它都是在OSTaskStkInit()处清零, 你就是随变改成任何数据都没关系.
另外用ERET返回是为了规范行为, 是有必要的. 此处不需要效率. 多几行代码, 利大于弊

杨***

（1）这是对楼主的C251-UCOSII的任务切换速度的测试介绍，为了让更多的坛友看到，所以另开了主题介绍

https://www.stcaimcu.com/forum.php?mod=viewthread&tid=4289&extra=page%3D1

（2）楼主目前版本的替代法的软中断程序非常简明，正好包括了RTOS任务切换的六个部分，可算教科书级别的了。
（3）楼主目前版本的任务切换速度应该是接近极限了，配合STC32的64KB的EDATA，相信在很多需要高时间响应的RTOS应用可以大大施展拳脚了。这里点个赞
（4）建议楼主对自己移植版给个版本编号，相信经过楼主不断地改进，C251-UCOSII的性能和可靠性会不断地提高，会有更多的网友关注和投入到应用。
（5）建议楼主从技术和应用两个方面来介绍自己的移植和应用经验。交流技术经验时建议用这次我提供的测试范例，介绍应用时可以用原来的范例。
下面是C251-UCOSII测试范例：
Demo_0101_C251 - UCOSII.rar (703.36 KB, 下载次数: 91)

2023-9-16 21:44 上传

点击文件名下载附件

下面是我的对比范例：
Demo_0101_uCx51_uCOSII_STC32G.rar (80.72 KB, 下载次数: 94)

2023-9-16 21:45 上传

点击文件名下载附件

tzz1***

我最近手上突发几件工作上的任务，自己手上那个用UCOS的小项目也要暂停一段时间了。我想把本贴现有的所有代码全部转移到各位版主手上，以后你们另开一贴，自己做主，版本什么的你们安排。以后我有什么想法也通过你们来更改或表达。争取有个统一的形式。
就像你说的，OS不是一推出就立刻能用，需要经得起各技术手段和时间的检测，才能正式推出。各种细节也要不断的完善。甚至是书写规范等等，这些活很多，我个人的能力肯定不够，也不允许。
像下午熊仔指出我那两个明显错误，我自己都笑了。
这个版本我个人觉得大体框架没有问题.因为接近原版本的转换思维，所以省去了很多“麻烦”。（就像我和熊仔聊天说的那样，直接套娃，一不小心就成功了）中断嵌套的处理也比“程序转移〞那种更具有优势。临界段的问题直接避开。目前大框架已发现的缺陷就是占用了一个中断号，并且是要求能软件写标志的中断号，最好是再附加硬件自动清中断标志的中断号。
现在的机型片上资源比较多，左右衡量，还是觉得“中断切换〞比较有优势，希望你们往此方向发力。
以前言语不当之处望老师多包函

杨***

tzz1*** 发表于 2023-9-11 15:58
临界区切换任务? 这个确实没想过, 不过我很好奇的是, 什么时候需要在临界区切换任务.   ...

“临界区切换任务? 这个确实没想过, 不过我很好奇的是, 什么时候需要在临界区切换任务. ”

看来这个问题不说清楚不行了：
（1）这是uC/OS-III




这个“OSSCHED()”函数中开头就是“Disable interrupts;”，结束时是“Enable interrupts”，这算不算是uC/OS-III关闭中断在临界区切换任务？
（3）下面这个是uC-OS3的




这个第449行的“CPU_INT_DIS();”，到第482行的“OS_TASK_SW(); ”，再到第483行的“CPU_INT_EN();”，这算不算是uC OS3关闭中断在临界区切换任务？
（4）这是FreeRTOS







这些文字算不算是FreeRTOS关闭中断在临界区切换任务？

（5）下面是RT-Thread




这些文字算不算是RT-Thread关闭中断在临界区切换任务？

（6）说明：在我的认知里，任务切换的核心过程是不能被打断的，对于单片机RTOS而言，任务切换的核心过程都应该用关闭总中断的方式来保护它。我一般称这种过程为“临界过程”，把这段程序称为“临界区”，把这种方法也称为“临界区保护方法”。我除了1981年在大学旁听了数学系的一门“ALGOL60程序设计”的课程，其他的计算机知识全部是自学的。我已经注意到了我的很多词汇的语义与大家的不太一样，常常会产生误会，希望大家谅解。
通过这个回复，希望大家认可我的这个观点，如果我解释的不够清楚，大家也可以提出来讨论。毕竟任务切换就是RTOS最核心的功能，保护好它，就为RTOS提供了安全性的保证

tzz1***

杨*** 发表于 2023-9-17 13:21
“临界区切换任务? 这个确实没想过, 不过我很好奇的是, 什么时候需要在临界区切换任务. ”

看来这个问题 ...

最好是不争这个事情了吧, 在这一点我比较固执, 我知道全程关中断切换任务也不会增加太多开销. 为了保守, 如果是作为一个版本推出, 是应该选择保守一点的. 我也承认这个做法是我自己想出来的, 目前没有出现问题, 不代表没有问题, 我就是经过反复理论推断, (用我那种方法切换任务时,不必全程关中断是可行的). 至少目前没有站得住脚的证据证明不行. 如果长时间没有站得住脚的理论可以证明它是不行的, 而在实际运行过程中也没出现问题, 它将可以成为一个新的理论支撑点. 杨老师, 你不是也说过, "正统" 就是用来推翻的. 你叫我挑战者, 无论胜败, 我都来挑战一下. 杨老师请放心, 我多次提醒, 代码是刚做出来, 没有过多的测试, 不会误人子弟. 再者我这也不算是什么发行版本, 激进一点, 不破不立, 再调皮一下

Cos***

杨老师充分展示了主流RTOS都是在（全局）临界区中切换任务，即便是采用PendSV方式也是如此，这绝对是正统方法，可靠性毋庸置疑。
tzz1983所用的方法，在原理上和CosyOS和Keil RTX4/5是有些类似的，都是在一个最低优先级中断（PendSV）中切换任务，
并且不会进入临界区（tzz1983仅是在访问内核对象时进入临界区），虽然任务切换过程会被高优先级的中断所打断，
但却不会影响最终结果的正确性（前提是如果没有bug的话）。