Small RTOS51中的一个典型问题及其解决方法

时间：09-18 来源：互联网点击：

2 解决方法

问题已经找到，就有解决的办法．以《嵌入式实时操作系统SmallRT0s5l原理与应用》(陈明计，北京航空航天大学出版社，2004)中程序清单7.5为例。书中的代码如下：

#if OS_MAX_TASKS＜9 ／／把当前任务加入到此消息队
  ／／列的等待任务表中
Buf=OSMapTbl[OSRunnmgTasklD()]； (5)
#else
if(OSRunningTasklD()＜8){ (6)
Buf=OSMap Tbl[OSRunningTasklD()]； (7)
else{
Buf |= OSMapTbl[OSRunningTasklD( ) &()x07]； (8)
}
#endif
while(Buf[O]==0) ／／消息队列中暂时投有消息 (9)
{
#ifdef_C51_
SP="SP"+sizeof(Buf)。 (10)
*((uint8 0S_Q_MEM_SEL * data*)(SP+l-slzeof(Buf))=Buf; (11)
#endif{
OSClearSignal(OSRunningTask())；／／当前任务进入休眠
／／状态 (12)
OSSched()；／／调度下一个最高优先级的就绪任务运行(13)
#ifdef_C51_
Buf= *((uint8 OS_Q_MEM SEL*dota*)(SP+1-sizeof(Buf))； (14)
SP="SP-sizeof"(Buf); (15)
#endif
if(OSWaitTick[OSRunningTasklD()]==O)(16)
{
break；／／任务再次运行，如果超时到,退出循环
}
} ／／while(Buf[0]==O)

修改的方法是把(5)"(8)放在(9)后面作为while()循环的第一步，其他不变。即只有在OSQPend()函数检测到没有消息可取的情况下，才把任务添加到对应于此消息队列的等待任务表中。一来，若队列中已经存在消息，这可以加快。SQPend()的执行速度；二来，对于以超时方式申请消息的任务，不会发生如前所述的队列申明明有消息，任务却取不到，只能等待至超时为止的情况。即使IDZ抢先一步取走消息，只要尚未超时，IDX会再一次被OSQPend()添加到消息队列的等待任务表中。这样，以后运行的OSQIntPost()函数就能够知道IDX仍然在等待消息，从而使lDX有机会获得消息。

此法简单易行，但对于以无条件方式申请消息的任务并不凑效。因为无条件等待时，任务被唤醒，其必然满足超时条件。所以无论其能否取到消息，指令都会跳出while(Buf[0]==0)循环，结果就有可能返回让人难以理解的超时代码。这时，需应用程序通过额外检测OSQPend()的返回代码类型来判断任务是否真正取到消息。

另一种方法是仿照uC／OS—II的思路(较复杂，不推荐)。在发送消息的OSQInatPost()函数中，如果检测到有任务正在等待此消息，则并不把消息数(Buf[0])加l，其他部分不变。这样，即使IDZ抢在IDX再次运行前申请消息，也会因为发现队列中没有消息而被迫进入休眠．但对于正在函数OSQPCnd()中等待消息的任务IDX来说，当它再次运行时也会发现消息队列中的消息数为O。这时，OSQPend()就需要另外检测IDX是否仍然在等待任务表中来判断任务到底能否取到消息。若任务还处在消息队列的等待任务表中，则任务必定是由“超时”唤醒的，可直接返回超时代码；否则，说明是有别的任务通过发送消息将其唤醒的，则可以取到消息。这样，以无条件方式等待消息的任务也就不会返回指示其等待超时的代码了。只是此方法也有一个BUG，那就是如果有任务抢在IDX取走此消息之前向队列中又发送了另一个消息，则新入队列的消息存放位置将会重叠前一条消息(uC／OS—II中不存在此问题)。也就是说，首先进入队列的那条消息被覆盖掉了，而谁也不知道它曾经存在过。

同样的问题也会发生在互斥型信号量的操作中，感兴趣的读者可以参看相关代码分析。

结语

需说明一点，以上分析仅仅针对Small RTOS51(V1.12.1)。在本文发表前，本人曾与《嵌入式实时操作系统Smell RTOS61原理与应用》一书的作者陈明计先生就此问题通过E_mail进行过讨论。他指出：“V1.12.1的版本确实有此问题，但在V1.20的版本中不会（尽管代码相似）”。只是笔者在看过V1.20版本后觉得，只有当任务IDX优先级较高时，才有可能不发生此类错误，否则就很难保证了。

上一篇：Keil软件仿真的串口调试技巧
下一篇：FPGA-DSP瞄准目标：用得起的DSP性能

单片机 C语言嵌入式相关文章：

栏目分类