新RTOS层出不穷
DJYOS,RT-thread,CoOS不过感觉像CoOS这样运作不错,http://www.coocox.com/
网站也比较清爽
CoOS源码ourdev_511871.zip(文件大小:75K) (原文件名:CoOS.zip)
User Guideourdev_511872.pdf(文件大小:730K) (原文件名:CooCox_CoOS_User's_Guide.pdf)
STM32F103RB上的移植-IAR版本ourdev_511873.zip(文件大小:197K) (原文件名:STM32F103RB_IAR5.30.zip)
STM32F103RB上的移植-MDK版本ourdev_511874.zip(文件大小:158K) (原文件名:STM32F103RB_MDK3.70.zip) 这个OS不错,尤其是它的timer.c
不要自己写回调函数了,
在此补上基于LM3S系列的移植,官方暂时没有做移植
点击此处下载 ourdev_512037.rar(文件大小:273K) (原文件名:CoOS_LM3S_MDK.rar) 建了2个任务,点了一个灯LED3-PB6, bug report:
line594 in task.c of CoOS
修改前:
if(ptcb->mutexID != INVALID_VALUE)
{
if(MutexTbl.taskID == ptcb->taskID)
{ /* Yes,leave the mutex */
CoLeaveMutexSection(ptcb->mutexID);
}
}
修改后:
if(ptcb->mutexID != INVALID_ID)
{
if(MutexTbl.taskID == ptcb->taskID)
{ /* Yes,leave the mutex */
CoLeaveMutexSection(ptcb->mutexID);
}
}
还有两处是仅仅是类型不匹配,影响不大; Good.
先来看看手册,是怎么实现的。 mark 我觉得这个os是有问题的,很多应该原子操作的变量都没有得到保护,例如kernel\queue.c文件:
void* CoPendQueueMail(OS_EventID id,U32 timeout,StatusType* perr)
{
...
pqcb->qSize--; /* Update the number of messages in the queue */
....
}
StatusType CoPostQueueMail(OS_EventID id,void* pmail)
{
...
pqcb->qSize++;
...
}
在CoPendQueueMail函数中,qSize++ 语句操作必须是原子,对于某些cisc处理器可能一条指令就可以做到,但对于risc处理器,这就要分三步完成:
1、读qSize变量到寄存器
2、寄存器 - 1
3、写寄存器到qSize变量
而我并没有看到os对这个变量有任何保护,如果程序执行到第2步,此时中断发生,假如在中断处理中调用了CoPostQueueMail函数,而该函数使qSize + 1,但中断返回后,程序回到qSize++的第2步并往下执行,qSize变量会被寄存器中的值替代,这意味着丢失了一个mail!
像这样的问题,coos中还可以找到一些。
也许我没有看完整,而出现的理解偏差,愿与coos的作者共同探讨。 路过,学习中 学习了,好资料啊 MAKE 标记 谁能同RT-Thread Ucos-ii FreeROST作个比较呀,到底各有什么优缺点? mark,hehe{:smile:} 好好学习
页:
[1]