UCOSII - STC32G12K128 移植

tzz1***

嗯 你说的方法可以, 各人选择而已, 我还是会选择用先保存一下EA, 前面和后面都允许中断. 之所以这样做, 是因为, 高优先级中断可能会有更要紧的事情要做, OS的响应速度, 本身就是OS最关键的指标之一, 这里不是行不行的问题 ,而是一种理念, 如果认真去读OS代码, 就会发现, 只要是涉及临界段, 都会及尽所能的想办法尽快结束.  我印象中有这样一段代码, 是改变优先级还是哪个段程序, 具体在哪说不上了, 大体意思就是作者在执行一段较长的临界段时, 为了减少单片临界段的执行时间, 暂时退出了临界段, 然后调用了一个空函数, 接着又再次进入临界段. 这样做的目的就是为了在调用空函数的时候可以响应别的请求. 人家都做成这样了, 我们在这添一小点代码又算什么呢

熊***

能执行紧急中断，返回还是在PendSvIsr里面，没法切换到最高优先级的任务先执行。所以任务切换还是正确的。
看下面分析：

1，PendSvIsr执行__asm   { POP   PSW     } 的时候，高优先级ISR发生
2，执行高优先级ISR，中断退出前有更高的任务需要切换TF4=1，然后RETI返回
3，返回到PendSvIsr 的 __asm   { POP   DR0     }继续剩余的。最后RETI退出
4，再次进入PendSvIsr，执行更高优先级的任务切换。


确实是执行了紧急中断。也就不到1us的时间。                          
                    

tzz1***

那么可不可以有这么一种假设呢, 假设有一个十万火急的事件触发了高优先级中断, 收到事件后, 你必须在可控的时间内抬高某个IO的电平, 才能满足时序的要求, 这个处理代码很简单, 只是时序有要求,代码本身就可以包含在中断里面, 当中断返回时事件已经处理完了. 此时开着中断和关着中断是不是有区别? 具体是延长了多少us不是本质, 代码也不一定只会在任务中, 任务的优先级绐终低于硬件中断. 实时OS是要求延时可控, 而不是没有延时, 而临界段就是影响整个系统响应的关键
再说另外一个: 即便是代码在任务级, 把EA=0放到最后也不能提高效率, 是的, 程序是在RETI后又重新进入中断, 开始了任务切换, 看似有些多余. 实则:如果你此时是关闭中断的, 那不过是推迟了中断的响应时间, 等临界段运行完后, 产生中断, 然后任务切换, 这个过程和之前有节省时间吗? 该做的还是都做了,一点也没有节省时间.

熊***

tzz1983 发表于 2023-9-14 12:49
那么可不可以有这么一种假设呢, 假设有一个十万火急的事件触发了高优先级中断, 收到事件后, 你必须在可控的 ...

应该是说EA=1放最后吧.笔误？

通过我上一楼的分析，确实是没问题的，优先处理了紧急中断。确保了临界时间最短。实时要求更强了。

要是STC以后设计芯片能单独搞一个pendSV中断就好了.这样就不用占用其他中断。

tzz1***

熊*** 发表于 2023-9-14 13:34
应该是说EA=1放最后吧.笔误？

通过我上一楼的分析，确实是没问题的，优先处理了紧急中断。确保了临界时 ...

对, 是笔误
"要是STC以后设计芯片能单独搞一个pendSV中断就好了.这样就不用占用其他中断。"
是的, 去年年底的时候我浏览FREERTOS的时候, 就想过提这个想法, 但是人微言轻, 就不提了.
其实搞这个中断硬件上的开支应该是很少的, 不用开发什么新的指令, 额外做一个中断标志就可以了, 也不用什么优级级, 直接最低

熊***

还有对于在临界区里面嵌套切换任务的，这种也算是是无聊的例子吧。本来这样做就已经影响了系统的实时性了。这样的例子本来就是没有意义。
只能说通过解决这个问题彻底的完善了移植的版本。更加适合不同需求吧。

总之代码是用户自己使用的，该注意什么？自己要知道。

tzz1***

熊*** 发表于 2023-9-14 13:47
还有对于在临界区里面嵌套切换任务的，这种也算是是无聊的例子吧。本来这样做就已经影响了系统的实时性了。 ...

兄弟, 你又说这个话题了, 我以为翻编了呢.
首先: 已经说明, 临界段是不会去切换任务的. 这个之前已以说明白了.  打个比方, 除OS外, 你会主动在临界段调用另一个函数, 而另个函数可能会引任务切换, 会存在这种可能吗?   如果有, 那说明你的编程思维是有问题的.
其次: 也已说明, 用代码切换任务, 虽然发生在临界段, 但这涉及OS的底层逻辑, 后面会通过一些特殊的手法来纠正或维持底层的正常运行逻辑, 这里算是一个特列, 不能以点概面.  不能改变临界段的定义. 也不足以说明任务是在临界段内切换的

我想了一下, 杨老师要表达了意思应该是: "为了保证OS正常切换任务, 需要适当的对部分或全部切换任务代码用临界段保护起来". 如果这句话表达正确, 此时你会发现, 临界段变成了切换任务的一部分了, 而不是任务切换被包含在临界段中. 是不是有些绕?
其实临界段和任务切换根本就是两回事, 各有各的定义, 没必要纠结的

杨***

tzz1*** 发表于 2023-9-14 09:22
杨老师, 这是为何呢?  不怪我说话比较刻薄啊. 讲个故事吧, 我初学51单片机的时候, 书上说中断函数后加上关 ...

“杨老师, 这是为何呢? ”——你的意思其实是：我为什么盯着你不停地说，口气又不好，而且经常说的还不对。首先点赞你的好脾气，然后我来解释一下。
（1）RTOS是下一步STC单片机应用的重点方向，但是对RTOS，了解的人少，能够在实际应用的人更少，因此本版块应该成为普及RTOS知识，推广RTOS应用的交流平台。
（2）我观察论坛，一是移植者和研制者将成果推荐到论坛后就很少继续系统第介绍自己的作品，二是我写了9篇FreeRTOS入门，看不到有什么效果，因此我觉得让创作者自己来说话很有必要。
（3）熊仔是我第一个盯上的坛友，从STC-FreeRTOS开始移植时就盯上了。你是我第二个盯上的，你在你的第一个贴子问如何在FreeRTOS的中断里切换任务时被盯上的。当时ZHP给了你在FreeRTOS中解决这个问题的正统方法。不过你却用你自己的方法去解决了：“谢谢大家的关心,这个问题现在我已经解决了,其实UCOS2的代码我还是认真读过的, 都能理解,但出于时间的关系,现在不想用太多的时间去研究FREE的原码.    我在这里也把我是怎么解决这个问题的思路说一下,就当是交流经验,大神路过就不要喷,”。不过你对你的方法只是做了简单的介绍，然后就没有了更多的了。
（4）重点：当时我想，如果你的那个方法可以实现任务调度，那么对于STC单片机，FreeRTOS就存在与目前STC-FreeRTOS不同的第二种移植方法。
（5）现在你亮出了你的方法，并且成功应用到uC/OS移植上，所以我不盯你，不盯你的这个方法盯谁？我甚至希望你能用你的方法给出STC单片机上本质不同的第二个FreeRTOS移植版。
（6）我看了你的移植部分，我一直坚持操作系统理论里“任务切换不可被打断”原则，所以换做我，我会像熊仔说的那样在“PendSvIsr”的第一行放“EA=0”，然后在“RETI”之前放“EA=1”，这样整个任务切换过程本质上就作为“临界区”被保护起来了，在任何意义上都不会被打断了。
如果这样做既满足了操作系统理论里的要求，又为你自己提供了一个“在临界区中进行任务切换”实际例子，可以通过这个例子来纠正大家潜意识中的“在临界区中不会进行任务切换”的先入为主的看法。
（7）看了你的移植代码，我意识到你现在的新方法通不过我设计的“临界区保护嵌套测试程序”，不但你的通不过，我猜ARM单片机上基于“PendSvIsr”的UCOS、FREERTOS和RTT也通不过。但年轻人的潜力是很大的，我在想，如果你像熊仔一样接受这个测试，然后又改进你的方法，说不定也能通过测试呢？那这样你的移植版的技术水平不是就比那些高了呢？你还可以反过来改进它们现在的版本去。
（8）公开地在论坛上争论，就像公开地在教室上课中答辩，其实最大的受益者吃瓜者。因此我先盯着CosyOS去PK，然后盯了熊仔，现在在这里盖高楼了，这里先向你说抱歉，希望你能继续地把你的成果和思路介绍给大家，尤其希望你能介绍解密版的你的RTOS产品实际应用。
（9）我也有知识短板，比如这次在STC单片机的中断过程的理解上是存在错误的，你的认识是正确的，而我的认识局限在80/90年代我用过的CPU外接中断控制器的水平上了，我现在发现我看STC单片机手册时对那句话“中断标志在中断过程中清除”直接忽视了。
（10）话说到这里了，先说大结论吧：我也在STC32上移植和开发了RTOS了，我的传统方法与你的新方法本质上是不一样的。我专门写了一些测试程序来测试我的RTOS，但这些测试程序未必适合你新方法。所以不必纠结这些测试条件在实际中是否存在，只要通过对测试的讨论和碰撞，认识到每种任务切换方法都不是万能的，都有自己的特点和适用范围，只要争论清楚哪些是一致的，哪些是有差异的就行了，就可以让用户针对不同需求选择不同类型的RTOS了。
加油站要不要与充电站PK？要！但最终得益的汽车使用者，可以购买到自己适合的车型。
（11）现在STC32单片机上有了两种不同类型的UCOS，是移植者的功劳，是STC32位8051单片机的幸事（一般单片机上的RTOS只有一种类型），更是广大STC单片机用户的幸事。希望将来STC32单片机上也有两种不同类型的FreeRTOS

杨***

tzz1*** 发表于 2023-9-14 14:17
兄弟, 你又说这个话题了, 我以为翻编了呢.
首先: 已经说明, 临界段是不会去切换任务的. 这个之前已以说 ...

“我想了一下, 杨老师要表达了意思应该是: "为了保证OS正常切换任务, 需要适当的对部分或全部切换任务代码用临界段保护起来". 如果这句话表达正确, 此时你会发现, 临界段变成了切换任务的一部分了, 而不是任务切换被包含在临界段中. 是不是有些绕?”

是的，是这个意思。“绕”是好事，说明达到了我们自身认知的边界。什么时候“绕过去了”，那就达到了一个新境界了

tzz1***

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

没时间了, 我有工作任务了, 以前再聊吧

关于你说的几点, 我回应一下:
1.刚开始我就说过, 我发的这个东西出来, 主要的目的就是为了抛砖引玉, 让大家共同来讨论这个话题 , 我想在这方面杨老师你应该是赞同的, 当然我也有自己的私心, 如果大家齐心协力做得更好了, 我是不是就可以用现成的了呢, 呵呵. 这里并没有代表我的代码有多牛B的, 也不会说一定没有BUG,毕竞才几天时间,我还没那么傲
2.关于FREERTOS那个事情, 我确实改了一个移植, 并尝试了一段时间, 虽说自己测试了一段时间, 没发现什么大问题, 但是我对FREE原代码不熟, 也没有精力深入了解. 我有自己的工作, 并没有太多的闲瑕时间来做这些. 相对来说, UCOS的码我更熟一点, 所以如果用于项目, 我会首选UCOS. FREERTOS那个代码没有用到实际项目,但底稿还有保存, 现在不能直接发出来, 有时间的话,我剔除一些和工作相关的内容, 再发出来, 如果你们感兴趣的话
3.关于任务切换不可被打断这个说法我目前还不完全认同,后续我花些精力来缕一缕. 这么说吧, 我认为用中断切换任务, 无非就是多设置了一次标志, 又不会把寄存器给写坏, 不会有什么问题的. 当然的, 不包括你们那种方法, 你们要从中断直接返回到任务级, 不一样的. 而我的中断就只是中断, 没有别的东西渗和进来
4.前面你是否发了那个"临界区保护嵌套测试程序", 我没有留意, 现在我对这个有些兴趣了, 虽然我还不知道你说的具体内容是什么, 但是我始终认为临界段是不会主动去切换任务的. 本着谦虚的态度, 我回头去缕缕. 还有一点可能性就是, 虽然不会主动在临界区去切换任务, 但OS要考虑代码本身健壮, 就是说要要考虑到当不小心这样使用到时, 将会发生什么.这也是要考虑的一部分.
5.STC32G12K128之前有人发过UCOS的版本吗, 我为什么看不到呢, 早知道有现成的, 两天的时间我也不想去浪费的, 哈哈