定制RS485协议
我正在编写一个简单的多点 RS485 协议，用于分布式系统中的串行通信。我使用的是可寻址模型，其中从设备有 20 毫秒的响应时间窗口。主 uC 轮询连接的设备以获取更新，并做出相应响应。我使用了校验和并采取了必要的溢出预防措施，以确保连接的设备不会响应格式错误的消息。事实证明，此方法在大约 99% 的情况下有效，但如果在通信会话期间引入新设备，我会丢失数据包。 “热”插入新设备将对从属设备正在监视的信号产生负面影响，即使时间极短。我从事工程软件方面的工作，但如何在不尝试重新创建 TCP 的情况下缓解这种情况呢？我们使用轮询模型是因为它速度快并且适合我们的应用程序，不需要 RTOS 功能。从基本角度来看，我的每个 cpu 上都有大量的周期。
I am writing a simple multi-drop RS485 protocol for serial communications within a distributed system. I am using an addressable model where slave devices are given a window of 20ms to respond. The master uC polls the connected devices for updates and they respond accordingly. I've employed checksums and take the necessary overrun precautions to ensure that connected devices will not respond to malformed messages. This method has proved effective in approximately 99% of situations, but I lose the packet if a new device is introduced during a communication session. Plugging in a new device "hot" will have negative effects on the signal being monitored by the slave devices, if only for an extremely short time. I'm on the software side of engineering, but how I can mitigate this situation without trying to recreate TCP? We use a polling model because it is fast and does the job well for our application, no need for RTOS functionality. I have an abundance of cycles on each cpu, think in basic terms.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通过 RS485 发送数据包并不是可靠的通信。无论如何，您都必须处理数据包丢失的情况。当然，您不必重新发明 TCP。但是您必须通过超时监控和序列号来检测丢失的数据包。在简单的应用程序中，这可以在应用程序级别完成，这使您远离 TCP 的复杂性。当您的轮询模型丢弃所有具有无效校验和的数据包时，这可能会更轻松地进行集成。
如果您想检查可能由热插拔或行为不当的设备引起的冲突，可能需要进行一些改进。有些硬件允许读回自己的传输。如果您发现发送的数据和接收的数据之间存在差异，则可以假定存在冲突并重复该数据包。这还需要一种序列编号。
Sending packets over the RS485 is not a reliable communication. You will have to handle the lost of packets anyway. Of course, you won't have to reinvent TCP. But you will have to detect lost packets by means of timeout monitoring and sequence numbers. In simple applications this can be done at application level, what keeps you far off from the complexity of TCP. When your polling model discards all packets with invalid checksum this might be integrated with less effort.
If you want to check for collisions, that can be caused by hot plugs or misbehaving devices there are probably some improvements. Some hardware allows to read back the own transmissing. If you find a difference between sent data and receive data, you can assume a collision and repeat the packet. This will also require a kind of sequence numbering.
也许我在你的问题中遗漏了一些东西，但是你不能只写主程序，以便如果在允许的时间内没有从设备看到响应，它会重新轮询该设备吗？
Perhaps I've missed something in your question, but can't you just write the master so that if a response isn't seen from a device within the allowed time, it re-polls that device?