http://www.amobbs.com/archiver/tid-4939669.html
——————————————————————————————————————————————————————————
发现UC/OS-III源码有一处不明白！会不会是BUG.高手过来看看！
费话不多说，上源码！
void OS_IntQTask (void *p_arg)
{
while (DEF_ON) {
done = DEF_FALSE;
while (done == DEF_FALSE) {
if (OSIntQNbrEntries == (OS_OBJ_QTY)0u) {
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 此处如果发生了中断，并且在中断中调用了OSSemPost
// OSSemPost 会使用这个任务进入就绪状态，但当返回到这个任务时
// 这个任务执行下面的代码，又自己移除了！！！！！！！
// 我想应该在查看OSIntQNbrEntries 变量前关中断，因为这个变量的访问和下面
// 的操作应该是一个临界段的代码。
//////////////////////////////////////////////////////////////////////////////////////////////////////
CPU_CRITICAL_ENTER();
OSRdyList.NbrEntries = (OS_OBJ_QTY)0u; /* Remove from ready list */
OSRdyList.HeadPtr = (OS_TCB *)0;
OSRdyList.TailPtr = (OS_TCB *)0;
OS_PrioRemove(0u); /* Remove from the priority table */
CPU_CRITICAL_EXIT();
OSSched();
done = DEF_TRUE; /* No more entries in the queue, we are done */
} else {
ts_start = OS_TS_GET();
OS_IntQRePost();
ts_end = OS_TS_GET() - ts_start; /* Measure execution time of tick task */
if (ts_end > OSIntQTaskTimeMax) {
OSIntQTaskTimeMax = ts_end;
}
CPU_CRITICAL_ENTER();
OSIntQNbrEntries--;
CPU_CRITICAL_EXIT();
}
}
}
}
clingos 发表于 2011-8-6 09:42:15
自己顶起来！
clingos 发表于 2011-8-6 09:43:29
希望喜欢OS的朋友一起来读读源码！
现在觉得有好多地方觉得不合适！
linfeng5945
发表于 2011-8-6 16:08:40
我记得，if那里应该不会产生中断把？
因为在进行调试的时候，if下面第一条指令，好像才可以设置断点。
不知道我说的对不对，楼主可以试一下
9509238
发表于 2011-8-6 17:17:48
分析得好！的确是一处bug，有楼主这个认真劲，别研究有版权争议的ucosiii了，来加入rt-thread吧！
SailJune
发表于 2011-8-6 17:24:00
说实话，我觉得ucos-ii用于一般的嵌入式开发，绰绰有余；
3我觉得主要是时间片的添加，同一优先级多个任务，没啥必要我感觉。
clingos
发表于 2011-8-8 08:34:16
回复【4楼】9509238
-----------------------------------------------------------------------
呵呵，RT-THREAD是个好东西，也在闲暇时间看过，有机会一定会仔细看看！
只不过相对UCOS来说，我是从它开始接触嵌入OS的，有一种说不出的感觉！
唉，都是邵贝贝惹的祸！
clingos
发表于 2011-8-8 08:38:58
回复【5楼】SailJune
-----------------------------------------------------------------------
我和你的看法正好相反，我觉得支持时间片和同一优先级多个任务非常好，
当有多个任务时，我觉得优先级的分配比较麻烦！
ljt8015
发表于 2011-8-8 08:41:03
ucosiii 除了时间片调度 好像没有增加别的功能啊！~
clingos
发表于 2011-8-8 09:05:41
呵呵，是的！但是目前UCOS-III的各种服务差不多挺健全的，
嵌入OS该有的基本上都有了！
不过我觉得UCOS-III在实现以上功能方面没有什么新颖之处，
目前我觉得在TICK处理这块的方法还不错，值得借荐！
但是也正是这个TICK的让我觉得有点火，如果OS_TICK的数据
类型为32位的，而OS内部的所有超时处理都直接使用OSTickCtr加
上Dly的这种方法，如果系统的时钟频率为1000HZ那么这个系统运行
差不多49天后就会溢出，延时的一些服务就会出错！而UCOS-III却是
说可以使用64位的数据类型，但是查了下long long 好像是C99标准新
加的！
其它的OS也有同样的问题，但处理的方法不相同，个人觉得最好的一种
处理方法是FREERTOS，它使用了两个指针，一个正常的TICK列表指针，
一个溢出的TICK列表指针，当溢出时就放入溢出列表中，最后当然TICK
计数溢出时，此时交换下两个列表即可。而并没有依赖数据的长度！
也许是我还没有理解UCOS-III的真正用意，高手勿拍！
ljt8015
发表于 2011-8-8 09:19:19
驱动程序框架，ucos怎么一直都不增加呢！~
ffxz
发表于 2011-8-8 09:20:03
回复【9楼】clingos
呵呵，是的！但是目前ucos-iii的各种服务差不多挺健全的，
嵌入os该有的基本上都有了！
不过我觉得ucos-iii在实现以上功能方面没有什么新颖之处，
目前我觉得在tick处理这块的方法还不错，值得借荐！
但是也正是这个tick的让我觉得有点火，如果os_tick的数据
类型为32位的，而os内部的所有超时处理都直接使用ostickctr加
上dly的这种方法，如果系统的时钟频率为1000hz那么这个系统运行
差不多49天后就会溢出，延时的一些服务就会出错！而ucos-iii却是
说可以使用64位的数据类型，但是查了下long long 好像是c99标准新
加的！
其它的os也有同样的问题，但处理的方法不相同，个人觉得最好的一种
处理方法是freertos，它使用了两个指针，一个正常的tick列表指针，
一个溢出的tick列表指针，当溢出时就放入溢出列表中，最后当然tick
计数溢出......
-----------------------------------------------------------------------
看RT-Thread的实现
clingos
发表于 2011-8-9 10:39:52
各位帮忙看看如何理解这段！
Any time delay (or timeout) on µC/OS-III is computed as a delta of the current time (OSTickCtr) and requested delay.
Therefore, as long as the input delay does not overflow the delta, it should be no artifact on the system.
In fact, the only potential function that could cause such overflow of the delta is OSTimeDlyHMSM().
To prevent that, enable OS_CFG_ARG_CHK_EN which is going to check for the appropriate range of the parameters,
since OS_OPT_TIME_HMSM_STRICT is the default option.
hiberhe
发表于 2011-8-14 10:16:33
标记一下,等看III代码时好注意
xrwgy
发表于 2011-8-15 17:07:37
回复【楼主位】clingos
-----------------------------------------------------------------------
自己读了一下代码，楼主说的有道理，确实是bug。
jeffeggs
发表于 2011-8-17 22:41:09
标记下慢慢分析
aprogramer
发表于 2011-9-17 20:45:45
Any time delay (or timeout) on µC/OS-III is computed as a delta of the current time (OSTickCtr) and requested delay.
UCOS中，任何的时间延迟或者超时 都是基于请求的延迟与当前时间(OSTickCtr)的delta计算得来的。
Therefore, as long as the input delay does not overflow the delta, it should be no artifact on the system.
因此，只要输入的延迟没有令delta溢出，it should be no artifact on the system（系统中应该就没有与事实不符的错误）
In fact, the only potential function that could cause such overflow of the delta is OSTimeDlyHMSM().
事实上，唯一可能引起delta溢出的潜在的函数是 OSTimeDlyHMSM().
To prevent that, enable OS_CFG_ARG_CHK_EN which is going to check for the appropriate range of the parameters,
since OS_OPT_TIME_HMSM_STRICT is the default option.
为了阻止它发生，可以使能 OS_CFG_ARG_CHK_EN ，它会对参数的大小范围是否合适进行检查，因为OS_OPT_TIME_HMSM_STRICT 是默认的选项。
wwomee
发表于 2013-4-1 10:51:12
仔细想了下,确实存在.但是影响很小,不会导致严重问题,因为其实最坏的影响也就是."在那时候触发中断提交的内容在下一个时基执行!"
本人最近在学些ucos-iii源码,由于权限不够不能加楼主为好友,
希望楼主家我QQ316645339 讨教下ucos-iii的问题!
谢谢!