本帖最后由 杨为民 于 2023-9-20 13:13 编辑
熊仔 发表于 2023-9-19 18:34
（13）测试2结论：如果对用户程序进行临界区保护，会带来系统崩溃。
你说“结论：目前移植的ucos到STC32上，没惊天大BUG之二。”
（1）你的移植版不接受方法0，是不是你说的？
（2）你的移植版使用方法3，没有通过这个测试，是不是事实？
（3）一个程序在测试时崩溃了，我的语境叫做“存在BUG”，你不承认。
（4）那么请问：如果别人的程序在测试时崩溃了，用你的语言会评价他的程序“存在BUG”吗，如果你的程序在测试时崩溃了，用你的语言你不把评价为“存在BUG”，你评价是什么？是不是我OUT了？、
（5）又或者说对你的崩溃了的程序，你的评价是“结论：目前移植的ucos到STC32上，没惊天大BUG之二。”“只存在一个小小的BUG？”
CosyOS 发表于 2023-9-19 20:43
刚才我的描述有bug，再重新整理一下。。。
CosyOS的现状描述：
（1）一直关注你的方法，如果你继续沿着：提供临界区阻塞检测，提供阻塞区队列，然后在总中断恢复后对阻塞队列再进行处理这条正确的道路上走下去，那么只要你的这些队列处理不是通过中断完成的，那么你的采用替代法软中断的CosyOS是能够通过这个测试的。
（2）对于有优先级队列的处理，比如任务调度的队列的处理，除了你现在（好像是，没仔细看，不确定）按优先级提取队列成员处理的方法外（这符合任务调度的原则），还要不要研究一下另外两种方法：先进先出（FIFO）和后进先出（LIFO），然后比较一下。最后你可以指定一种，或者像临界区保护方法一样，给出三种选择让用户决定？
杨为民 发表于 2023-9-20 13:12
（1）一直关注你的方法，如果你继续沿着：提供临界区阻塞检测，提供阻塞区队列，然后在总中断恢复后对阻 ...
1、现在CosyOS的阻塞服务，除了阻塞延时外，其它九个服务都是要直接返回结果的，如获取信号量：/*|res|*/uTakeSem(sem, tc)。如果采用阻塞队列的方法，除非把返回值改成API参数，由用户输入一个结果变量，而后把结果传给这个变量，如uTakeSem(sem, tc, res)，res为用户定义的结果变量，这样可以实现所有阻塞服务都能够在临界区中执行，实际是入阻塞队列，待最终退出临界区后统一执行。然而即便如此，用户也只能在最终退出临界区后才能查询服务的执行结果。而且如果有多个阻塞服务的话，还有更多的问题需要考虑（略）。
2、CosyOS的任务队列是HPFO+FIFO，高优先级的任务先出+相同优先级的任务先入先出（入指的是任务启动加入任务队列）。这样，不同优先级的任务是按照优先级抢占式调度，相同优先级的任务（已FIFO排队）时间片轮转调度。
CosyOS 发表于 2023-9-20 14:11
1、现在CosyOS的阻塞服务，除了阻塞延时外，其它九个服务都是要直接返回结果的，如获取信号量：/*|res|*/ ...
你要多自我介绍，想要别人自己看懂你的程序是不容易得，你的手册过于精简，恐怕只有写过或者移植过RTOS的读者才能把握
杨为民 发表于 2023-9-20 18:32
你要多自我介绍，想要别人自己看懂你的程序是不容易得，你的手册过于精简，恐怕只有写过或者移植过RTOS的 ...
好的杨老师，未来我在这方面会加强。
杨为民 发表于 2023-9-20 12:55
你说“结论：目前移植的ucos到STC32上，没惊天大BUG之二。”
（1）你的移植版不接受方法0，是不是你说的？ ...
关于这个惊天大BUG之三，我后面修复，嵌套的时候增加一个代码切换任务吧。方法3还是算了吧，改用方法4支持吧。
因为方法3本来不支持同一个函数里面嵌套使用。需要像rtt的方式使用。
代码里面也有介绍
#if OS_CRITICAL_METHOD==3
//如果需要在一个函数内嵌套使用临界区保护，需要用调用函数方法，不能用宏
//例子：
//1层 进入临界区
//cpu_sr1 = OS_CPU_SR_Save()；
// 2层 进入临界区
// cpu_sr2 = OS_CPU_SR_Save()；
//.
// 2层 退出临界区
// OS_CPU_SR_Restore(cpu_sr2)；
//1层 退出临界区
//OS_CPU_SR_Restore(cpu_sr1)；
惊天大BUG之二，到现在我还是懵逼，不知道说的啥bug。
本帖最后由 熊仔 于 2023-9-20 23:33 编辑
*修改版本： V1.02
*修改时间： 2023-09-20
修改： 1.方法3，方法4，支持临界区切换任务
方法3有使用注意事项
//如果需要在一个函数内嵌套使用临界区保护，需要用调用函数方法，不能用宏
//例子：
//1层 进入临界区
//cpu_sr1 = OS_CPU_SR_Save()；
// 2层 进入临界区
// cpu_sr2 = OS_CPU_SR_Save()；
//.
// 2层 退出临界区
// OS_CPU_SR_Restore(cpu_sr2)；
//1层 退出临界区
//OS_CPU_SR_Restore(cpu_sr1)；
这个临界区切换任务移植成功。检测到临界区，使用代码切换方式。
熊仔 发表于 2023-9-20 23:08
*修改版本： V1.02
*修改时间： 2023-09-20
修改： 1.方法3，方法4，支持临界区切换任务
（1）{:4_250:}首先祝贺你新的STC32G移植版V1.02通过了“关闭总中断在临界区保护中进行任务切换的测试”。有图，有程序的证明就是扎实。
（2）今天你成功通过测试了，还会再说测试没有通过前的“本来这个测试方案，真实项目不会存在的”那句话吗？
（3）真实项目会不会存在的，取决于你的世界有多大。你的世界里没有，别人的世界里（比如我的世界里）有没有？那人类的世界有没有？
（4）建议你以后想表达的时候，加个定语“在我的世界里，真实项目不会存在的”。如果青蛙说的是“我的井里没有”，我想谁也不会嘲笑他的。因为他没有否定井外的世界没有，也表示他已经知道井外部还存在一个世界，只是因为他还没有跳出去而已，也许将来有机会他跳出去了，他就会变成王子了。不管一个人有多小的本事，只要他有这样的格局我就会敬重他。
（5）熊仔你将来能不能变成王子我不知道，但是经过你的努力，今天你的STC32G上的uC/OS-II移植版通过了这个测试（在STC8上的你已经通过了），可以向更高的新台阶迈进了。而到今天，我还没有看到已经移植/研制到STC32G单片机上的C251-UCOSII、FreeRTOS和CosyOS这三个RTOS通过这个测试，期望他们有一天也能通过这个测试，迈上新台阶。
（13）测试2结论：如果对用户程序进行临界区保护，会带来系统崩溃。
（14）综合结论：采用方法0不关闭总中断，不进行任何临界区保护，对系统本身和用户程序没有任何影响，都可以正常运行。采用方法3，采用关闭总中断对用户程序进行临界区保护，系统会崩溃。
（15）存在BUG：在采用软中断的uC/OS-II移植版中，向用户提供关闭总中断的临界区方法就是BUG。
老杨, 我对你提到的测试2 , 感兴趣
分析了一下相关程序, 使用了经典老掉牙的 PLC位操作方式, 保护 EA.
对 uCOS-II 来说, 可能属于 非典(非标).
第一次改 , 对 uCOS-II 的框架及程序结构, 理解的不是很透彻, 不知这样改动, 是否可行.
请老杨在百忙之中, 帮忙测试一下.
谢谢!