私はARM7プロセッサに組み込みアプリケーションを書いています。私は、フラッシュに格納しているデータのシリアルリンクを介して送信しているデータのチェックサムを必要としています。 2つのCRCのどちらがこの目的に適しているのだろうと思いました。主なトレードオフはコードスピードとロバストネスです。別のCRCを考慮する必要がありますか？ ARMの効率的な実装へのリンクがありますか？組み込みアプリケーション用にCRC-16またはIPチェックサム（RFC1071）を使用する必要がありますか？
RFC1071は、単純な16ビットのペアの合計です。したがって、2つのエラーが「取り消す」可能性があり、引き続き「合格」チェックサムを与える可能性があります。例えば。ビットエラーは1から0にビットを反転させます.16ビット後に別のビットエラーが0から1にビットを反転します。RFC1071はこれを検出しません。しかし、CRCでチェックされている場合、同じダブルビットフリップエラーが検出されます。
この種のダブルビットフリップエラーは、シリアル伝送で可能です。 （特に、1本のワイヤが「ノイズが多い」が、最近ではパラレルを使用している場合は、パラレル・ケーブルの方がはるかに多いでしょうか？）フラッシュ・チップでは、特にPCBにマイクロチップとフラッシュ・チップの間に不良なはんだ接合部がある場合に可能です。全体的に、入力の単一ビット変化がCRCシフトレジスタ内の複数のビットに影響を及ぼすので、CRCは統計的にエラーを検出する際により堅牢です。
実際には、検出したい可能性の高いものは、Flashのアップロードが不完全であるため、コードの大部分が欠けているだけです。そのために、統計的にはチェックサムはおそらく大丈夫ですが、私が取り組んでいるプロジェクトではいつもCRCを好んでいました。テーブルベースのCRCアルゴリズムでは、必要な計算速度を得ることができました。
最高のチェックサムをお持ちください。点滅が頻繁に行われない可能性があるため、フラッシュチェックサムはシリアル通信よりも洗練されています。
追加私が考えているチェックサム：
が、これは、あなたがやっているアプリケーションとあれば行うことができます害に完全に依存しエラーは検出されません。
は、複数の入力のためにここを見てみましょう：http://en.wikipedia.org/wiki/List_of_checksum_algorithms
CRC32は、比較的安価で実現するために迅速です。 PNG sample code on W3C's website（テーブル&のコスト= 1KバイトのRAMは、EEPROMリソースを必要とせずに簡単に生成できます）で、評判が良く効率的な実装です。他のCRC実装を検討する場合は、計算時間にテーブルメモリサイズをトレードオフすることができます。
フラッシュデータが破損したくない可能性が高いので、crcは良好です。他の部分はシリアルプロトコルです。シリアルリンクの速度が遅い場合は、crcを使うべきです。 ARM7チップは、シリアルリンクの速度よりもはるかに高速でイーサネットチェックサムを処理できるため、コードの速度は問題ではないはずであり、堅牢性が大幅に向上します。
フラッシュメモリや（特に）OTPのようなものでは、エラーのランダムな組み合わせをキャッチするのに役立つCRCのようなものと、十分に長くないものの1つの補完チェックサムオーバーフロー。後者は、誤ってセットされたビットのみを含むか、または誤ってクリアされたビットのみを含むエラーの任意の組み合わせが検出されるという利点を有する。
CRCもエラー訂正が可能です。MD5およびSHA1は、エラー訂正ができないように特別に設計されています。また、計算するのがかなり遅くなります（ほとんどのハードウェアで数回）。私は常にストリームデータの完全性チェックにCRCを提案します。中間の攻撃や認証メカニズムで人にコードを書く必要がない場合は、衝突を検出できないことが本当に重要なときに暗号化する必要があります。 USBケーブルでコンピュータ - >デバイス）、CRCが正常であるはずです。 – ewanm89
また、CRC32はイーサネットを含む多くの点で標準です。組み込み機器であっても、最近はかなり高速に処理できます。 – ewanm89
MD5/SHA1 /などは、暗号データの完全性のためのものです。改ざんを検出するCRCは、おそらくOPが望む伝送完全性のためのものです。 –