STC单片机 uC/OS-II核心技术（3）：任务切换用软中断时RTOS系统不需要任何关闭总中断

杨***

熊仔 发表于 2023-9-20 11:06
方法0测试不成功的例子杨老师已经提供了。
不需要再提供了。
两个移植版本内核基本是一样的。

看来该讲点道理了：

（1）软装也是中断，当一个软中断正在进行且没有退出（没有执行RETI指令前）的时候，CPU会禁止这个中断再次发生，不会有谁再进入这个软中断的。当你用一个最高优先级的软中断统一进行任务切换时，就相当于这个软中断ISR里面的程序已经被CPU中断机制保护了，不会再有其他中断产生了，因此也不需要在ISR里面关闭总中断或者再做什么保护措施了。
（2）由于这种用在一个最高优先级的软中断统一进行任务切换时的ISR不会被另外的任务切换要求的同一个软中断打断，肯定会连续执行，这种机制在我的语境里也称为“临界区保护”。
（3）通常最高优先级的软中断是专门的“TRAP”指令，我上个世纪学习、移植和研制RTOS时，全部都使用这种类型的软中断指令。但是STC32G/F目前没有开放80251的“TRAP”指令。因此各位只能使用硬中断代替软中断的替代法。
（4）CosyOS将任务切换放在INT0中断中，如果再把INT0中断的优先级设置为最高，按照STC单片机的中断结构，这个“INT0软中断”的优先级最高了，这时“任务切换就被中断机制这个临界区保护了”，换言之，“任务切换的核心已经在CPU临界区保护下进行了”。
（5）熊仔的移植版是用TIMER4的中断，优先级不能设置且处于最低，用方法0当然不行（要不熊仔也换个INT0试试？）。因此熊仔的移植版必须加一个关闭总中断和打开总中断的方法来对那几行关键语句进行保护，这样“任务切换的核心已经在关闭/打开总中断的临界区保护下进行了”。
（6）说了这些道理，大家认可我的“任务切换的核心必须在临界区保护下进行”和“已经有了在临界区保护下进行任务切换的需要”这两个论断吗？

熊***

杨为民 发表于 2023-9-20 11:48
看来该讲点道理了：

（1）软装也是中断，当一个软中断正在进行且没有退出（没有执行RETI指令前）的时候 ...

第六点的结论我是认可的，我一直没有推翻这个。



只是关于实时性要求。不推荐把整个切换过程临界保护。我在在12#有分析。
这里再复制过来吧
一，我昨晚也想到了你说的中断触发切换方式不用关中断的情况，是因为这个触发的中断属于高优先级，其他中断不能打断。这种高优先级的中断切换实时性稍微差点。

二，一个实时抢占式操作系统的重要指标是“实时抢占”，这个“实时抢占”主要表现在中断抢占，也就是说高优先级的中断优先，才能执行紧急事件。比如一个外部信号触发中断，必须先紧急处理。
举一个例子，常用的串口中断，比如通讯波特率是10M，也就是一个字节1us，如果系统关闭中断时间超过1us，肯定出错。导致数据丢失。
移植到stc32的ucos，上下文切换部分是1us多点。这个软中断优先级设为最低，仅仅是在保护系统重要的2条变量中关闭中断的。关闭中断的这个时间也就不到1us。如果串口总的优先级设为更高，就可以实时抢占cpu，处理串口接收数据。

当然还有一个 解决方案是降低波特率。这里只是举例说明实时抢占的重要性。


三，移植到STC8和STC32的ucos对比，STC8的ucos实时性差太多了。后期再研究下，提高这个实时性。



主流的RTOS在ARM-CortexM上面运行，基本都是把切换任务pendSV中断的优先级弄最低，不受系统管理的中断，不会被屏蔽的，切换任务过程照样执行。就是考虑实时响应性能。


结论：目前移植的ucos到STC32上，没惊天大BUG之二。

杨***

熊仔 发表于 2023-9-20 11:28
（3）“方法0不行”这个结论成立，就意味着我的“任务切换的核心必须在临界区保护下进行”这个论断成立，也 ...

（1）如果白切鸡必须用水煮，那么算不算“已经有了用水煮鸡的需要”了，如果有了这个需要，要不要先用温度计测测水温需要多少度？

（2）你已经承认了“任务切换的核心必须在临界区保护下进行”，那么你继续承认“已经有了在临界区保护下进行任务切换的需要”的论断吗？
（3）如果你继续承认“已经有了在临界区保护下进行任务切换的需要”的论断，那么你觉得“惊天大BUG之三”文章里的“在临界区保护中进行任务切换的测试”有这个需要吗？
（4）一开始你是第一个怀疑这个测试方法的必要性的，后来我说服你在将uC/OS-II移植到STC8的时候接受这个在“在临界区保护中进行任务切换”的测试，并且最后你的STC8移植版已经成功通过了这个测试。我觉得这一切正常。下一步你就可以将成果移植到STC32了，同一个移植者，你的移植版肯定也通得过这个测试。
（5）当网友“lzz1983”推出他的STC32G移植版时，我告诉他通不过这个测试，他也知道通不过，因为总中断被关了，任务切换不了了。所以他质疑“有在临界区保护中进行任务切换的这个需要/必要吗？”。这让我很吃惊。
（6）后来又有网友第三次第四次问我在实际情况中有这个需要吗？要我举实际例子说明有“在临界区保护下进行任务切换的需要”。我觉得应该这是大家都存在的一个误区了，我应该出来举例子，讲道理来说清楚这个问题。
（7）刚好，STC32G没有开放TRAP指令，刚好你移植版的软中断是TIMER4，那么就有了这三篇“惊天大BUG”的文章和讨论。其实BUG不是问题，方法0不要临界区保护当然不成立，要不RTOS为什么要言必称临界区保护呢？问题是通过这些质疑、讨论、辩论和争论，你们这些为大家提供和维护RTOS的技术人员接不接受“在临界区保护下进行任务切换是有必要的和是需要”这个论断，如果接受，你们的RTOS接不接受“在临界区保护下进行任务切换”这个测试。
（7）接受“在临界区保护下进行任务切换”这个测试是要有勇气的，因为你的RTOS有可能通不过，比如你的STC32移植版。
（8）其实第一个版本通不过很正常，接着改进不就行了。考不及格接着考呗。如果考不及格就质疑考试的必要性，就不再考了，那就被历史永远定格在不及格了。
（9）“行必至”，就看你熊仔愿不愿意继续改进你的STC32G移植版，让新的版本通过这个测试？

熊***

STC32要是支持TRAP指令，这个很好处理。
因为这个不受EA影响。入口地址FF007B,但是STC已经把这个指令改成了NOP,也就是无效语句。



当然也可以参考stc8这个方案。还要考虑large和huge,因为这两个模式函数调用压栈不一样。跟中断也不一样。所以才有了stc32的Freertos那种方法。
现在我好不容易想到一个入口标号的方法,把编译模式宏定义去掉了。

为了支持杨老师那个临界区嵌套里面切换函数。又需要加上编译模式的宏。我是真感觉没必要。

本来这个测试方案，真实项目不会存在的。

熊***

移植到x86的uCOS,是用软中断80H,
初始化的时候把80H中断入口跳转到普通任务切换函数里面执行。
他这个软中断，是不能被打断的，所以不需要临界保护。其他中断时间要求必须要大于这个切换任务的时间。实时性稍微差一点点。

所以说支持软中断指令就很好解决。

Cos***

关于“任务切换的核心必须在临界区保护下进行”，我认为是这样的：

首先，大家对临界区概念的认知可能有所不同。
其实，大家的根本认知还是相同的：
1、内核服务中对内核对象的访问过程要有整体性、连贯性，不可被打断。
      因为在同一个服务中，各个内核对象是要紧密配合来完成同一个功能的，必须做为一个整体来处理，不可分割。
在最高优先级的软中断中做任务切换，也是以此为依据的。


我的认知：
2、实际上也不是完全不能被打断，如果打断后仅执行用户自己的代码，不会再访问相关的内核对象就不会出问题。
正因如此（2），FreeRTOS才支持用BASEPRI屏蔽指定的低优先级中断，从而实现高优先级中断的0中断延迟，缺点是高优先级中断中不能再调用系统服务，原因正是如果调用的话将有可能会打断其它正在执行的服务，可能会访问到相关的内核对象。
同理，Keil RTX4/5、CosyOS都是以（2）为基本原则，从而实现全局不关（总）中断的。
不同的是，Keil RTX4/5、CosyOS 在中断中都可以随意调用服务，没有FreeRTOS那样的限制。

tzz***

你们还是一如即往的聊得很HI呀, 哈哈, 今天开心, 找了5天的BUG, 总算找出来了, 哈哈. 累死我了.
朗里格朗,来冒个泡

Cos***

tzz1983 发表于 2023-9-20 15:38
你们还是一如即往的聊得很HI呀, 哈哈, 今天开心, 找了5天的BUG, 总算找出来了, 哈哈. 累死我了.
朗里格朗, ...

通过辩论可以相互学习、相互探讨、自我反省、追求真理。

熊***

方法1，利用最高优先级的软中断做任务切换，全程不用关中断。

方法2，利用最低优先级的软中断做任务切换。仅保护核心部分代码，比如OSTCBCur = OSTCBHighRdy，OSPrioCur = OSPrioHighRdy两条核心代码。


我是推荐方法2，因为更加实时。高优先级中断可以打断除2条保护的核心代码外的其他部分，及时响应紧急中断处理。
移植到STC32的ucos就是用方法2

Cos***

现在，我已经想明白了一件事，不要再称CosyOS是全局不关总中断的RTOS了，全局不关中断的RTOS有很多，
应称为“零中断延迟的RTOS / CosyOS”，*只要您的硬件中断不是最低优先级就可实现零中断延迟*，这才是CosyOS的根本特征。