CRC16 Prüfsumme: HCS08 vs Kermit vs. XMODEM

StackOverflow https://stackoverflow.com/questions/4455257

Frage

Ich versuche, CRC16 Fehlererkennung an einen Motorola HCS08 Mikrocontroller Anwendung hinzuzufügen. Meine Prüfsummen nicht übereinstimmen, though. Ein Online-CRC-Rechner bietet sowohl das Ergebnis, das ich in meinem PC-Programm zu sehen und das Ergebnis sehe ich auf dem Mikro.

Es ruft das Ergebnis der micro "XModem" und die PC-Ergebnis "Kermit."

Was ist der Unterschied zwischen der Art, wie diese zwei alten Protokollen, um die Verwendung von CRC16 angeben?

War es hilfreich?

Lösung

Sie können 16-Bit-IBM, CCITT, XModem, Kermit implementieren und CCITT 1D0F die gleiche grundlegende Codebasis verwenden. finden Sie unter http://www.acooke.org/cute/16bitCRCAl0.html die verwendet Code von http://www.barrgroup.com/Embedded- System / How-To / CRC-Berechnung-C-Code-

Die Tabelle zeigt folgende wie sie sich unterscheiden: 

name    polynomial  initial val  reverse byte?  reverse result?  swap result?
CCITT         1021         ffff             no               no            no
XModem        1021         0000             no               no            no
Kermit        1021         0000            yes              yes           yes
CCITT 1D0F    1021         1d0f             no               no            no
IBM           8005         0000            yes              yes            no

Dabei steht 'reverse byte' bedeutet, dass jedes Byte Bit-umgekehrt wird vor der Verarbeitung; ‚Umgekehrte Ergebnis‘ bedeutet, dass das 16-Bit-Ergebnis wird nach der Verarbeitung bit-umgekehrt; ‚Swap-Ergebnis‘ bedeutet, dass die beiden Bytes im Ergebnis vertauscht nach der Verarbeitung.

alle oben wurde validiert mit Testvektoren gegen http: //www.lammertbies .nl / comm / info / crc-calculation.html (wenn das nicht stimmt, sind wir alle verloren ...).

so, in Ihrem speziellen Fall, können Sie Code für XModem zu Kermit durch Bit-Umkehr jedes Byte, Bit Umkehren des Endergebnisses, konvertieren und dann in der Folge die beiden Bytes tauschen.

[i glauben, aber noch nicht überprüft oder bearbeitet die Details aus, dass jedes Byte Umkehren entspricht das Polynom zur Umkehr (plus einige zusätzliche Details). weshalb man sehr unterschiedliche Erklärungen an verschiedenen Orten sehen wird für das, was ist im Grunde der gleiche Algorithmus.

auch vor dem Ansatz ist nicht effizient, aber es ist gut für die Prüfung. wenn Sie das Beste, was effizient zu tun möchte, ist die oben zu übersetzen Lookup-Tabellen.]

Bearbeiten , was ich CCITT oben genannt haben, ist in der RevEng Katalog als CCITT-FALSCH. siehe für weitere Informationen, um das Update zu meiner Blog-Post auf dem Link oben.

Andere Tipps

Meine Erinnerung (ich verwendetes Modem Sachen Weg zurück, wenn zu tun) ist, dass Kermit die Bits in jedem Byte der Daten verarbeitet zuerst das niedrigstwertige Bit verwendet wird.

Die meisten Software-CRC-Implementierungen (Xmodem, wahrscheinlich) durch die Daten laufen Bytes höchstwertigen Bit zuerst.

Wenn in der Bibliothek Quelle suchen (Download von http: //www.lammertbies. nl / comm / software / index.html ) für die CRC-Berechnung Seite verwendet Sie verknüpft, werden Sie sehen, dass XModem CRC16-CCITT verwendet, das Polynom, für die: 

x^16 + x^12 + x^5 + 1  /* the '^' character here represents exponentition, not xor */

Das Polynom wird durch die Bitmap (Note, die 16-Bit wird angedeutet) dargestellt 

0x1021 == 0001 0000 0010 0001  binary

Die Kermit Implementierung verwendet: 

0x8408 == 1000 0100 0000 1000  binary

, die die gleiche Bitmap wie XModem der ist, nur umgekehrt.

Die Textdatei, die die Bibliothek begleitet auch erwähnt die folgende Differenz für Kermit:

Nur für CRC-Kermit und CRC-SICK. Nachdem alle Eingangsverarbeitung, das Einerkomplement der CRC berechnet wird, und die beiden Bytes des CRC vertauscht

So sollte es wohl einfach Ihre CRC-Routine zu modifizieren, um das PC-Ergebnis übereinstimmen. Beachten Sie, dass die Quelle in der CRC-Bibliothek scheint eine ziemlich liberale Lizenz zu haben - es könnte Sinn es zu bedienen oder weniger als (zumindest die Teile, die für Ihre Anwendung gelten) ist

.

X-Modem 1K CRC16.

Prozess für byteweise CRC-16 Eingangsdaten mit {0x01, 0x02} und Polynom 0x1021

  1. Init crc = 0

  2. Handeln ersten Eingangs-Byte 0x01: 2.1 'Xor-in' ersten Eingang-Byte 0x01 in MSB von crc (!): 0000 0000 0000 0000 (CRC) 0000 0001 0000 0000 (Eingangsbyte 0x01 links verschoben um 8)

    0000 0001 0000 0000 = 0x0100 Das MSB dieses Ergebnisses ist in unserem aktuellen divident: MSB (0x100) = 0x01. 2.2 So 0x01 ist die divident. Erhalten Sie den Rest für divident aus unserer Tabelle: crctable16 [0x01] = 0x1021. (Nun ist dieser Wert famila von der manuellen Berechnung oben.) Denken Sie daran, die aktuelle CRC-Wert 0x0000 ist. Verschieben sich die MSB des aktuellen crc und xor es mit dem aktuellen Rest der neuen CRC zu erhalten: 0001 0000 0010 0001 (0x1021) 0000 0000 0000 0000 (CRC 0x0000 links verschoben um 8 = 0x0000)

    0001 0000 0010 0001 = 0x1021 = Zwischen crc.

  3. Griff nächste Eingangsbyte 0x02: Derzeit haben wir Zwischen crc = 0x1021 = 0001 0000 0010 0001. 3.1 'Xor-in' Eingangs-Byte 0x02 in MSB von crc (!): 0001 0000 0010 0001 (crc 0x1021) 0000 0010 0000 0000 (Eingangsbyte 0x02 links verschoben um 8)

    0001 0010 0010 0001 = 0x1221 Das MSB dieses Ergebnisses ist in unserem aktuellen divident: MSB (0x1221) = 0x12. 3.2 So 0x12 ist die divident. Erhalten Sie den Rest für divident aus unserer Tabelle: crctable16 [0x12] = 0x3273. Denken Sie daran, die aktuelle CRC-Wert 0x1021 ist. Verschieben sich die MSB des aktuellen crc und xor es mit dem aktuellen Rest der neuen CRC zu erhalten: 0011 0010 0111 0011 (0x3273) 0010 0001 0000 0000 (CRC 0x1021 links verschoben um 8 = 0x2100)

    0001 0011 0111 0011 = 0x1373 = letzter crc.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top