armink
commented
7 years ago 应该是因为 T35 定时器初始化还没有完成，此时发起主机请求，导致状态机混乱，最终形成死锁。T35 本身时间很短，所以之前一直没有注意到这个细节。
不过出于可靠性角度考虑，我觉得问题还是要修复的，只通过让用户延时规避问题，有点不太妥。你有没有相关建议？
Open ericQiang opened 7 years ago
armink
commented
7 years ago 应该是因为 T35 定时器初始化还没有完成，此时发起主机请求，导致状态机混乱，最终形成死锁。T35 本身时间很短，所以之前一直没有注意到这个细节。
不过出于可靠性角度考虑，我觉得问题还是要修复的，只通过让用户延时规避问题，有点不太妥。你有没有相关建议？
ericQiang
commented
6 years ago 有个提议，在eMBMasterPoll函数中swith修改如下：
switch ( eEvent ) { case EV_MASTER_READY: //flag eMBMasterPoll, eg. add another state ESTABLISHED break; }
经测试可行。全部修改diff如下：
diff3.txt
armink
commented
6 years ago 多个状态确实可以解决问题。本地多测试下，可以提交 pr
仓主，SystemMonitor线程在调用eMBMasterReqxxx函数前，必须要调用 rt_thread_delay吗？我在测试时，遇到的问题时，如果没有调用rt_thread_delay的话，线程就卡死了。不知道仓主有没有测试到这个问题。
仓主回答： @ericQiang 你要等待 Modbus Poll 线程里面 MB_init 初始化成功，才能调用 modbus 相关的 API。
但目前masterPoll线程优先级最高，不存在MB_init初始化失败的情况。并且，我在初始化SystemMonitor线程时将延时设置为200.但问题依然会复现。仓主可否将你提交的工程中，SystemMonitor线程中的几个与rt_thread_delay屏蔽掉测试一下？ 谢谢。