Sollte ich CRC-16 oder IP-Prüfsumme (RFC1071) für eine eingebettete Anwendung verwenden?

Question

Ich schreibe eine eingebettete Anwendung auf einen ARM7-Prozessor, und ich brauche eine Form der Prüfsumme für Daten, die ich über eine serielle Verbindung auch für Daten, die ich im Flash speichern, senden. Ich habe mich gefragt, welcher der beiden CRCs für diesen Zweck besser geeignet wäre. Der Hauptkonflikt ist die Codegeschwindigkeit gegenüber der Robustheit. Sollte ich ein anderes CRC in Erwägung ziehen? Haben Sie eine Verbindung zu einer effizienten Implementierung für ARM?

Answer 1

RFC1071 ist eine einfache 16-Bit-Summe von Bytepaaren. Daher ist es möglich, dass sich zwei Fehler "ausgleichen" und immer noch eine "bestandene" Prüfsumme ergeben. Z.B. Ein Bitfehler dreht ein Bit von 1 auf 0. Ein weiterer Bitfehler von 16 Bits dreht später ein Bit von 0 auf 1. RFC1071 wird dies nicht erkennen. Aber derselbe Doppel-Bit-Flip-Fehler würde, wenn er mit einem CRC überprüft wird, erkannt werden.

Diese Art von Doppel-Bit-Flip-Fehler ist in einer seriellen Übertragung möglich. (Es ist viel wahrscheinlicher auf einem parallelen Kabel, besonders wenn eine Leitung "laut" ist, wer aber heutzutage parallel verwendet?) Es ist auch in einem Flash-Chip möglich, besonders wenn die Platine eine schlechte Lötstelle zwischen Mikro- und Flash-Chip hat. Insgesamt ist ein CRC beim Erkennen von Fehlern statistisch robuster, da eine einzelne Bitänderung im Eingang mehrere Bits im CRC-Schieberegister beeinflusst.

In der Praxis ist die andere Sache, die Sie wahrscheinlich erkennen möchten, ein unvollständiger Flash-Upload, so dass ein großer Teil des Codes einfach fehlt. Dafür ist statistisch eine Prüfsumme wahrscheinlich in Ordnung, aber ich habe immer einen CRC in Projekten bevorzugt, an denen ich gearbeitet habe. Mit einem Tabellen-basierten CRC-Algorithmus konnten wir die erforderlichen Berechnungsgeschwindigkeiten erzielen.

Answer 2

Nehmen Sie die beste Prüfsumme, die Sie sich in dieser Situation leisten können. Blinken wird möglicherweise nicht oft durchgeführt, daher kann die Flash-Prüfsumme komplexer sein als die für die serielle Kommunikation.

Zusätzliche Prüfsummen Ich denke dabei an:

• CRC32
• MD5
• SHA1

aber dies hängt ganz von der Anwendung, die Sie tun, und der Schaden, die getan werden kann, wenn Sie erkennen keinen Fehler.

Schauen Sie hier für weitere Eingabe: http://en.wikipedia.org/wiki/List_of_checksum_algorithms

Answer 3

CRC32 relativ billig und schnell zu implementieren. Es gibt eine seriöse und effiziente Implementierung in der PNG sample code on W3C's website (Kosten = 1Kbyte RAM für Tabelle & es kann leicht generiert werden, ohne EEPROM-Ressourcen benötigen). Sie können die Tabellenspeichergröße für die Berechnungszeit abwägen, wenn Sie nach anderen CRC-Implementierungen Ausschau halten.

Answer 4

Flash-Daten sind wahrscheinlich etwas, das Sie nicht beschädigt werden wollen, also crc ist gut. Der andere Teil ist ein serielles Protokoll. Angesichts der langsamen Geschwindigkeit der seriellen Verbindung sollten Sie mit einem CRC gehen. ARM7-Chip kann mit Ethernet-Checksuring mit Geschwindigkeit viel höher als die Geschwindigkeit einer seriellen Verbindung umgehen, so Code-Geschwindigkeit sollte kein Problem sein, und Sie werden eine enorme Steigerung der Robustheit bekommen.

Answer 5

Für Dinge wie Flash-Speicher oder (besonders) OTP, ist es oft gut, sowohl eine CRC, die eine gute Kombination von Fehlern zu fangen, und eine Einerkomplement-Prüfsumme, die lang genug ist nicht zu haben Überlauf. Letzteres hat den Vorteil, dass jede Kombination von Fehlern, die nur fehlerhaft gesetzte Bits enthält oder nur fehlerhaft gelöschte Bits enthält, erkannt wird.