通过串行 (RS485) 传输 ASCII 的简单稳健纠错
我有一个非常低速的串行数据连接(RS485): 9600波特率 实际数据传输率约为25%。
串行线路正在穿过 EMR 极高的区域。峰值波动可达3000KV。
我(还)还不能强制改变物理介质,但可以很容易地提供一个简单的、鲁棒的前向纠错方案。该方案需要易于在 PIC18 系列微控制器上实现。
有想法吗?
I have a very low speed data connection over serial (RS485):
9600 baud
actual data transmission rate is about 25% of that.
The serial line is going through an area of extremely high EMR. Peak fluctuations can reach 3000 KV.
I am not in the position (yet) to force a change in the physical medium, but could easily offer to put in a simple robust forward error correction scheme. The scheme needs to be easy to implement on a PIC18 series micro.
Ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
此网站声称在 PIC18 上实施 Reed-Solomon。我自己从未使用过它,但也许它可以是一个有用的参考?
This site claims to implement Reed-Solomon on the PIC18. I've never used it myself, but perhaps it could be a helpful reference?
搜索MODBUS ASCII协议中使用的CRC算法。
Search for CRC algorithm used in MODBUS ASCII protocol.
我使用 PIC18 器件进行开发,目前使用 MCC18 和 PICC18 编译器。几周前我注意到 PICC18 的外设标头错误地将 Busy2USART() 宏映射到 TRMT 位而不是 TRMT2 位。在我发现问题之前,这让我在短时间内感到非常头痛。例如,一个简单的传输:
当 Busy2USART() 宏被错误地映射到 TRMT 位时,我从不等待字节离开移位寄存器,因为我正在监视错误的位。在我意识到头文件不准确之前,我能够成功传输超过 485 个字节的唯一方法是在字节之间等待 1 毫秒。我的波特率为 91912,字节之间的延迟影响了我的吞吐量。
我还建议实施冲突检测和校验和的方法。即使在 PIC18 上,校验和也很便宜。如果您能够收听自己的传输,请这样做,这样您就可以意识到同一循环上的重复地址和不正确的计时可能导致的冲突。
I develop with PIC18 devices and currently use the MCC18 and PICC18 compilers. I noticed a few weeks ago that the peripheral headers for PICC18 incorrectly map the Busy2USART() macro to the TRMT bit instead of the TRMT2 bit. This caused me major headaches for short time before I discovered the problem. Example, a simple transmission:
When the Busy2USART() macro was incorrectly mapped to the TRMT bit, I was never waiting for bytes to leave the shift register because I was monitoring the wrong bit. Before I realized the inaccurate header file, the only way I was able to successfully transmit a byte over 485 was to wait 1 ms between bytes. My baud rate was 91912 and the delays between bytes killed my throughput.
I also suggest implementing a means of collision detection and checksums. Checksums are cheap, even on a PIC18. If you are able to listen to your own transmissions, do so, it will allow you to be aware of collisions that may result from duplicate addresses on the same loop and incorrect timings.