Prüfsumme CRC16: HCS08 vs. Kermit vs. XMODEM
Ich versuche, fügen Sie CRC16-Fehler-Erkennung, um ein Motorola HCS08 mikrocontroller-Anwendung. Meine Prüfsummen nicht übereinstimmen, obwohl. Eine online CRC Rechner bietet sowohl das Ergebnis sehe ich in meiner PC-Programm und das Ergebnis sehe ich auf der micro.
Ruft es die micro-Ergebnis "XModem" und die PC ' s Ergebnis "Kermit."
Was ist der Unterschied zwischen der Art, wie diese zwei alten Protokolle angeben, die Verwendung von CRC16?
InformationsquelleAutor Potatoswatter | 2010-12-15
Du musst angemeldet sein, um einen Kommentar abzugeben.
implementieren Sie können 16-bit-IBM -, CCITT -, XModem, Kermit und CCITT 1D0F mit der gleichen code-Basis. sehen http://www.acooke.org/cute/16bitCRCAl0.html, die verwendet code von http://www.barrgroup.com/Embedded-Systems/How-To/CRC-Calculation-C-Code
die folgende Tabelle zeigt, wie Sie sich unterscheiden:
wo 'reverse byte' bedeutet, dass jedes byte ist bit-reversed vor der Verarbeitung; 'umgekehrte Ergebnis" bedeutet, dass das 16 bit-Ergebnis ist bit-reversed nach der Verarbeitung; 'swap-Ergebnis" bedeutet, dass die beiden bytes in der Folge werden vertauscht nach der Verarbeitung.
alle oben wurde überprüft mit test-Vektoren gegen http://www.lammertbies.nl/comm/info/crc-calculation.html (wenn das falsch ist, wir sind alle verloren...).
so, in Ihrem Fall, können Sie konvertieren code für XModem, Kermit durch bit-Umkehr jedes byte, bit-Umkehrung der letzten Folge, und dann tauschen die beiden bytes des Ergebnisses.
[glaube ich, aber noch nicht überprüft, oder die Einzelheiten ausgearbeitet, dass die Umkehrung jedes byte entspricht der Umkehrung des Polynoms (plus einige zusätzliche details). das ist, warum Sie werden sehen, sehr unterschiedliche Erklärungen in verschiedenen Orten für was ist im Grunde der gleiche Algorithmus.
auch, der Ansatz oben ist nicht effizient, aber ist gut für Tests. wenn Sie wollen effizient das beste, was zu tun ist, übersetzen die oben genannten lookup-Tabellen.]
Bearbeiten, was ich genannt habe, CCITT oben ist dokumentiert in der RevEng-Katalog als CCITT-FALSCH. für mehr info, siehe das update meiner blog-Beitrag unter dem link oben.
In Ihrem link, die Sie erwähnen zu können, generiert die lookup-Tabelle auf der Basis der oben genannten Informationen. Wie kann das getan werden? Auch gibt es keine Korrelation zwischen der Art, bist du mit dem Satz "reverse" und die Art und Weise dieses Artikels ist es zu benutzen? danielvik.com/2010/10/calculating-reverse-crc.html Seine sind alle implementiert, mit der look-up-table-Ansatz, also bin ich kämpfen, um die Unterschiede/Gemeinsamkeiten, wenn es Sie gibt. Danke.
NEIN, der Artikel ist etwas ganz komisch, das ist sehr sehr unwahrscheinlich zu sein, was Sie wollen. es ist die Berechnung, was der text sollte Hinzugefügt werden, zu etwas, so dass der CRC kommt mit einem bestimmten Wert. // verwenden Sie den obigen code zum erzeugen einer Nachschlagetabelle, die durch umschreiben es so, dass die gleiche Logik angewendet wird, in einer Schleife die Werte von 0 bis 255, und dann werden diese Werte gespeichert und später verwendet, um zu ersetzen, die "innere Schleife" des crc-Algorithmus.
ps wenn Sie sich nicht sicher sind, wie Sie eine Tabelle konvertieren, sind Sie sicher, dass Sie müssen? ich benutze den code gab ich in eine bereitgestellte Produkt - es funktioniert einwandfrei. Sie wahrscheinlich nur brauchen, um über Effizienz, wenn Sie auf embedded-hardware-oder-Verarbeitung einen viel von Daten.
gut, der Artikel beschreibt genau, was ich tun müssen, außer für seltsame Einschränkungen kann ich nicht mein patch am Ende. ich hatte gehofft, ich könnte konvertieren meiner aktuellen crc-Implementierung in form einer Tabelle, und verwenden Sie dann eine ähnliche Technik beschrieben, in der Artikel, den ich mochte...
InformationsquelleAutor andrew cooke
Meiner Erinnerung (ich habe modem-Zeug Weg zurück, wenn) ist, dass Kermit verarbeitet die bits in jedem byte der Daten mit dem niederwertigsten bit zuerst.
Meisten software-CRC-Implementierungen (Xmodem, wahrscheinlich) ausgeführt, durch das Daten-Byte most significant bit zuerst.
Beim Blick auf die Quelle Bibliothek (download von http://www.lammertbies.nl/comm/software/index.html) verwendet für die CRC-Berechnung Seite, die Sie verlinkt, Sie werden sehen, dass XModem verwendet, CRC16-CCITT, das Polynom für die:
Das Polynom wird vertreten durch den bitmap - (beachten Sie, dass bit 16 wird implizit)
Kermit-Implementierung verwendet:
welche die gleiche bitmap wie XModem, nur Umgekehrt.
Den text-Datei, die Sie begleitet, die Bibliothek erwähnt auch den folgenden Unterschied für Kermit:
So sollte es wohl leicht zu ändern Sie Ihre CRC-routine entsprechend der PC führen. Beachten Sie, dass die Quelle in die SFB-Bibliothek zu haben scheint, eine ziemlich liberale Lizenz, könnte es Sinn machen, es zu benutzen mehr oder weniger (zumindest die Teile, die für Ihre Anwendung).
Die Notiz in der text-Datei über die Durchführung einer-Komplement des SFB für den SFB-Kermit und CRC-KRANK zu sein scheint eine "Kopie Tippfehler". In der gleichen text-Datei, dort ist eine Notiz, die oben für die CRC-DNP bespricht das notwendige Komplement-operation (die unterstützt, die "Kopie typo' - Theorie). Die Prüfung der source-code wird angezeigt, um zu bestätigen, dass die Einerkomplement-Betrieb gilt nur für CRC-DNP und nicht CRC-Kermit und CRC-KRANKEN.
InformationsquelleAutor Michael Burr
X-Modem-1K CRC16.
Prozess für Byte für Byte untersucht CRC-16 Verwendung der input data {0x01, 0x02} und dem Polynom 0x1021
Griff ersten Eingangs-byte 0x01:
2.1 'Xor' erste Eingabe-byte 0x01 in MSB(!) der crc:
0000 0000 0000 0000 (crc)
0000 0001 0000 0000 (Eingabe byte 0x01 Links-verschoben von 8)
0000 0001 0000 0000 = 0x0100
Das MSB dieses Ergebnis ist unsere aktuelle Dividend: MSB(0x100) = 0x01.
2.2 So 0x01 ist der Dividend. Holen Sie sich den Rest für Dividend aus unserer Tabelle: crctable16[0x01] = 0x1021. (Auch dieser Wert ist famila aus der manuellen Berechnung oben).
Denken Sie daran die aktuellen crc-Wert ist 0x0000. Verschiebung aus dem MSB des aktuellen crc xor mit dem aktuellen Rest zu Holen Sie sich die neuen CRC:
0001 0000 0010 0001 (0x1021)
0000 0000 0000 0000 (CRC 0x0000 Links-verschoben von 8 = 0x0000)
0001 0000 0010 0001 = 0x1021 = fortgeschrittene crc.
Griff neben input-byte 0x02:
Aktuell haben wir fortgeschrittene crc = 0x1021 = 0001 0000 0010 0001.
3.1 'Xor' input byte 0x02 in MSB(!) der crc:
0001 0000 0010 0001 crc (0x1021)
0000 0010 0000 0000 (Eingabe-byte 0x02 Links-verschoben von 8)
0001 0010 0010 0001 = 0x1221
Das MSB dieses Ergebnis ist unsere aktuelle Dividend: MSB(0x1221) = 0x12.
3.2 So 0x12 ist der Dividend. Holen Sie sich den Rest für Dividend aus unserer Tabelle: crctable16[0x12] = 0x3273.
Denken Sie daran die aktuellen crc-Wert ist 0x1021. Verschiebung aus dem MSB des aktuellen crc xor mit dem aktuellen Rest zu Holen Sie sich die neuen CRC:
0011 0010 0111 0011 (0x3273)
0010 0001 0000 0000 (CRC 0x1021 Links-verschoben von 8 = 0x2100)
0001 0011 0111 0011 = 0x1373 = endgültige crc.
InformationsquelleAutor Thomas