用于通过串行 (RS485) 传输 ascii 的简单稳健的纠错答案

【问题标题】：Simple robust error correction for transmission of ascii over serial (RS485)用于通过串行 (RS485) 传输 ascii 的简单稳健的纠错
【发布时间】：2010-07-15 15:40:53
【问题描述】：

我通过串行 (RS485) 的数据连接速度非常低： 9600 波特实际数据传输率约为其中的 25%。

串行线路正在通过一个具有极高 EMR 的区域。峰值波动可达3000 KV。

我（目前）还不能强制改变物理介质，但可以很容易地提出一个简单的、健壮的前向纠错方案。该方案需要在 PIC18 系列微控制器上易于实现。

想法？

【问题讨论】：

我使用 PIC18 器件进行开发，目前同时使用 MCC18 和 PICC18 编译器。几周前我注意到 PICC18 的外围头文件错误地将 Busy2USART() 库宏映射到 TRMT 位而不是 TRMT2 位。在我发现问题之前，这让我很头疼了很短的时间。简单代码：

标签： error-handling data-transfer rs485

【解决方案1】：

This site 声称在 PIC18 上实现了 Reed-Solomon。我自己从未使用过它，但也许它可以成为有用的参考？

【讨论】：

【解决方案2】：

搜索 MODBUS ASCII 协议中使用的 CRC 算法。

【讨论】：

【解决方案3】：

我使用 PIC18 器件进行开发，目前使用 MCC18 和 PICC18 编译器。几周前我注意到 PICC18 的外设标头错误地将 Busy2USART() 宏映射到 TRMT 位而不是 TRMT2 位。在我发现问题之前，这让我在短时间内感到头疼。例子，一个简单的传输：

putc2USART(*p_value++);
while Busy2USART();
putc2USART(*p_value);

当 Busy2USART() 宏被错误地映射到 TRMT 位时，我从不等待字节离开移位寄存器，因为我正在监视错误的位。在我意识到头文件不准确之前，我能够通过 485 成功传输一个字节的唯一方法是在字节之间等待 1 毫秒。我的波特率为 91912，字节之间的延迟扼杀了我的吞吐量。我还建议实施一种碰撞检测和校验和的方法。校验和很便宜，即使在 PIC18 上也是如此。如果您能够收听自己的传输，那么这样做可以让您了解可能由同一循环上的重复地址和不正确的时间导致的冲突。

【讨论】：