4

ARM7プロセッサで組み込みアプリケーションを作成していますが、シリアルリンクを介して送信するデータと、フラッシュに保存するデータに対して、何らかの形式のチェックサムが必要です。2つのCRCのどちらが目的に適しているのか疑問に思いました。主なトレードオフは、コードの速度と堅牢性です。別のCRCを検討する必要がありますか？ARMの効率的な実装へのリンクはありますか？

4

5 に答える 5

3

CRC32 は比較的安価で、すぐに実装できます。W3C の Web サイトにある PNG サンプル コードには、評判の良い効率的な実装があります(コスト = テーブル用の 1K バイト RAM & EEPROM リソースを必要とせずに簡単に生成できます)。他の CRC 実装を探している場合は、テーブルのメモリ サイズと計算時間のトレードオフを行うことができます。

于 2009-07-28T16:10:47.783 に答える
3

RFC1071 は、バイトのペアの単純な 16 ビットの合計です。そのため、2 つのエラーが「キャンセル」されても、チェックサムが「パス」になる可能性があります。たとえば、ビット エラーはビットを 1 から 0 に反転します。次に、16 ビット後に別のビット エラーがビットを 0 から 1 に反転します。RFC1071 はこれを検出しません。ただし、CRC でチェックすると、同じダブル ビット フリップ エラーが検出されます。

この種のダブル ビット フリップ エラーは、シリアル伝送で発生する可能性があります。(特に 1 本のワイヤが「ノイズが多い」場合はパラレル ケーブルで発生する可能性がはるかに高くなりますが、最近ではパラレルを使用する人はいますか?) 特に PCB のマイクロ チップとフラッシュ チップの間のはんだ接合が悪い場合、フラッシュ チップでも発生する可能性があります。全体として、CRC は、入力の 1 つのビットの変化が CRC シフト レジスタの複数のビットに影響するため、エラーの検出において統計的により堅牢です。

実際には、検出したい可能性が高いもう 1 つのことは、不完全な Flash アップロードであるため、コードの大部分が単純に欠落しています。そのためには、統計的にチェックサムはおそらく問題ありませんが、私が取り組んできたプロジェクトでは常に CRC を好んでいました。テーブルベースの CRC アルゴリズムにより、必要な計算速度を得ることができました。

于 2009-07-31T01:20:23.397 に答える
2

フラッシュ データは、破損したくないものである可能性が高いため、crc が適しています。もう 1 つの部分はシリアル プロトコルです。シリアル リンクの速度が遅いことを考えると、crc を使用する必要があります。ARM7 チップは、シリアル リンクの速度よりもはるかに速い速度でイーサネット チェックサムを処理できるため、コード速度は問題にならず、堅牢性が大幅に向上します。

于 2009-07-28T16:27:52.023 に答える
2

その状況で余裕のある最高のチェックサムを取ります。フラッシュは頻繁に行われない可能性があるため、フラッシュ チェックサムはシリアル通信用のものよりも洗練されたものになる可能性があります。

私が念頭に置いている追加のチェックサム：

  • CRC32
  • MD5
  • SHA1

ただし、これは実行しているアプリケーションと、エラーを検出しない場合に発生する可能性のある害に完全に依存します。

詳細については、こちらをご覧ください: http://en.wikipedia.org/wiki/List_of_checksum_algorithms

于 2009-07-28T14:56:22.927 に答える
0

フラッシュメモリや（特に）OTPのようなものの場合、エラーのランダムな組み合わせをうまくキャッチするCRCのようなものと、オーバーフローしないように十分な長さの1の補数チェックサムの両方を持っているとよいことがよくあります。後者には、誤って設定されたビットのみを含む、または誤ってクリアされたビットのみを含むエラーの任意の組み合わせが検出されるという利点があります。

于 2010-08-23T23:21:35.083 に答える