crystal
crystal

注册于 3 months ago

回答
5
文章
0
关注者
0

感谢楼主分享,昨天也是突然遇到了这种情况,不过和楼主触发的原因稍有不同,楼主同时触发 EV_MASTER_FRAME_RECEIVED 和 EV_MASTER_ERROR_RESPOND_TIMEOUT两个事件,而我是同时触发了EV_MASTER_FRAME_RECEIVED 和 EV_MASTER_FRAME_SENT两个事件,正如楼主所说,正常情况下不可能同时出现两种事件的
分析一下发现:poll线程和send线程都包含有互相需要等待的事件,当send线程在post(post(EV_MASTER_FRAME_SENT)后等待挂起,直到poll线程释放send线程等待的事件,在这个过程中,poll线程是事件处理和调度的核心,同一时刻一旦有某个事件需要poll线程处理,其最好能够被立即唤醒并处理,我们发现例程中poll线程中有一个延时,这个延时会带来事件的堆积后果,一旦事件产生了堆积,poll线程无法处理,也就形成了死锁。
楼主的解决方法是相当于给了一个默认的事件,而不会出现不确定的事件,避免多个事件同时发生。
还有个方法就是在不修改协议栈的基础上,去掉poll线程中的延时,增大响应超时时间(MB_MASTER_TIMEOUT_MS_RESPOND),目的也就是尽可能避免事件产生堆积。

不是你这么理解的,首先这个tick计数器是递减的,其次假如你延时10个us对应的tick数是10,那么从现在开始,delta就是获取当前开始的tick数记录下来假如是50,由于tick是递减的,也就是减到40就退出了,40怎么来的?就是不停的判断delta-当前tick是否大于10,大了就退出,小了就循环判断。之所以不超出一个OStick是因为可能存在tick计数器递减溢出的情况

你使用超级终端或者putty测试就没有问题,串口助手发送的是连续的字符串,绝对比你手动输入字符,finsh组件一个一个捕获解析快的多,你是每隔10ms查询有没有收到字符(rt_thread_mdelay(10)),串口助手发送一串字符串很快的,所以你的finsh组件只捕获到了一个字符

这个已经添加过了但是还是不行,输入上下左右返回ABCD,还是这个错误

发布
问题