朱天龙 (Armink)
朱天龙 (Armink)
> 我目前按照您的文档改了一个UCOSII版本的,移植成功,但是会出现概率性timeout,大概1%不到,请问您这边是如何解决的,原因是什么?已经困苦好多天了,感谢 你这概率属于正常现象，物理通信不可能不受干扰，做好异常后的重试就行了，本库里面都有对应接口。
裸机的 portevent 接口有呀，但没有裸机的 portevent_m 主机事件移植文件，感觉你需要的好像是主机的
暂时没有，之前想折腾过，后来放弃了，建议使用 RTOS 作为事件机制的基础
在 modbus 协议中，从机回复响应报文完成后，主机方是需要等待 T3.5 超时后，才能开始处理该报文，处理完了，主机才能发送新的报文。这期间时间差不多是毫秒级，所以大家在使用的时候没有出现跟你同样的断言。 建议： - 检查下自己的 T3.5 超时是否准确 - 上面的改法理论上我觉得好像没问题，但毕竟这个库已经经过很多产品的验证，不敢轻易动核心代码，除非你非常了解协议栈。所以也希望，你那边对这个改动先做下充分的验证。
> 检查下自己的 T3.5 超时是否准确 这条检查了吗？
我认为 FreeModbus 从机协议栈的作者原意是想让整个状态机更加可靠，所以增加了一些检查，看似挺合情合理。只是这些非常规临界状态时，针对具体的移植代码，可能会状态紊乱。 先这样改，方便提交 pr 吗？
从机的地址有明显的范围吗？你是想做成类似 DHCP 自动获取 IP 的功能？
现在的主机这边是有记录从机数据的缓冲区，如果范围是 100 ，由于该缓冲区的存储结构为顺序存储的数组，这样会导致很多资源浪费，建议你先评估下这种方式这种的可行性。 另外，类 DHCP 功能必须要有主机配合，可对于 modbus 的通信模型来说，主从模式将会导致从机没法主动与主机发送通信，所以感觉在 modbus 这种主从协议总线上不好实现，在 CAN 之类协议上才可能
> 从机在接收到广播指令之后发送自己的cpuid 这种是没法实现的，主机广播完，此次通信就结束了。同时还有下面的限制 > 可对于 modbus 的通信模型来说，主从模式将会导致从机没法主动与主机发送通信，可对于 modbus 的通信模型来说，主从模式将会导致从机没法主动与主机发送通信，
https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32/blob/master/FreeModbus/port/rtt/portserial.c#L131 see MODBUS_SLAVE_RT_CONTROL_PIN_INDEX definition