0

シリアル (RS485) 経由で非常に低速のデータ接続を使用しています。9600 ボーの実際のデータ転送速度は、その約 25% です。

シリアル回線は、非常に高い EMR の領域を通過しています。ピーク変動は 3000 KV に達することがあります。

私は (まだ) 物理媒体の変更を強制する立場にはありませんが、単純で堅牢な前方誤り訂正スキームを導入することは容易に提案できます。この方式は、PIC18 シリーズ マイクロに簡単に実装できる必要があります。

アイデア？

4

3 に答える 3

1

MODBUS ASCII プロトコルで使用される CRC アルゴリズムを検索します。

于 2010-09-02T13:00:37.067 に答える
1

このサイトは、PIC18 に Reed-Solomon を実装すると主張しています。自分では使ったことがないのですが、参考にならないでしょうか？

于 2010-07-15T16:08:06.217 に答える
0

私は PIC18 デバイスで開発を行っており、現在は MCC18 および PICC18 コンパイラを使用しています。数週間前、PICC18 のペリフェラル ヘッダーが Busy2USART() マクロを TRMT2 ビットではなく TRMT ビットに誤ってマップしていることに気付きました。これにより、問題を発見する前に、しばらくの間、大きな頭痛の種になりました。例、単純な送信:

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

Busy2USART() マクロが間違って TRMT ビットにマップされたとき、間違ったビットを監視していたため、バイトがシフト レジスタから出るのをまったく待ちませんでした。不正確なヘッダー ファイルに気付く前に、485 を超えるバイトを正常に送信できた唯一の方法は、バイト間で 1 ミリ秒待機することでした。私のボーレートは 91912 で、バイト間の遅延によりスループットが低下しました。また、衝突検出とチェックサムの手段を実装することをお勧めします。PIC18 でも、チェックサムは安価です。自分の送信を聞くことができる場合は、そうすることで、同じループでアドレスが重複し、タイミングが正しくないために発生する可能性のある衝突に気付くことができます。

于 2010-09-24T03:10:22.987 に答える