LM3S_RTOS之RTX(keil自带)的邮箱使用问题

2019-03-24 16:00发布

      首先想说一句别把麻烦管理员我的帖子转到其他地方,因为这里的人群旺!!高手多!!       进来发现keil自带的实时操作系统RTX(由于ARM,RTX-51是针对51的)的资源非常丰富,集成了TCP/IP、CAN、USB、FS等协议栈。       因为我以前有UCOS-II的基础,所以很快就看完了,比较而言: 1、RTX在调度方式上增加了 时间片轮转的方式 2、RTX的邮箱集成了UCOS的邮箱和消息队列的功能,但是没有“广播”的功能 3、RTX的软件定时器功能一般般。可能是用的不多的原因。 4、UCOS的用户群庞大,资料丰富  ,但是需要自己移植其他协议栈,如LwIP等,RTX资源丰富。          我在调试RTX的邮箱(KeilARMRLRTXExamplesMailbox)这个例子的时候遇到不解的问题: 这个例子非常简单,由于演示邮箱的基本用法,具体是这样的:        建立的两个任务:一个是邮箱发送任务,发送三条消息,然后删除自己。另一个是邮箱接收任务,在无限循环中等待邮箱消息并处理(即调用os_dly_wait()函数挂起任务直到消息到来),两个任务都是同样的优先级,使能了时间片轮转的功能,在邮箱发送任务中,每调用一次 os_mbx_send(邮箱发送函数) 之后都会调用 os_dly_wait(系统延时函数)来调度任务,以便让邮箱接收任务处理发送任务发送的消息。这个没问题。 我在单步执行的时候观察,在任务发送任务中切换到接收的任务的时候是在执行os_dly_wait(系统延时函数) 时, 不是在执行完os_mbx_send(邮箱发送函数) ,这是正确的因为两个任务是同样的优先级。刚刚发送完消息之后接收任务只是处于“就绪态”当调用os_mbx_send()后交出了执行权。       然后我就想,那我要是改变两个任务的优先级,让接收任务的优先级比发送任务邮箱级高,那么现象应该是:在发送任务执行完  os_mbx_send(邮箱发送函数) 后就应该发生调度,在ucos中是这样的,因为这就是优先级抢占的基本思想。但是奇怪的是:这样改变优先级后,无论是执行os_mbx_send()还是os_dly_wait()都不会产生任务调度,也就是说发送消息“丢失了”。               然后我尝试改变两者优先级为:发送任务高,接收任务低,现象正确。       请教各路高手 这是为什么?发送任务优先级低,接收任务优先级高,就不会产生任务调度。。。。。。。                         此帖出自小平头技术问答
友情提示: 此问题已得到解决,问题已经关闭,关闭后问题禁止继续编辑,回答。
4条回答
ddllxxrr
2019-03-25 14:35
 精彩回答 2  元偷偷看……0人看过

一周热门 更多>

相关问题

    相关文章