www.mikrocontroller.net

Forum: Compiler & IDEs crc_ccitt_update


Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich stelle mich schon länger die Frage wie die Ergebnisse der 
crc_ccitt_update Funktion zustande kommen.

Zum Testen nehme ich immer folgendes Datenpaket:
  uint8_t data[] = {1, 2, 3, 4, 5, 6, 7, 8};

Lasse ich dieses Paket von der o.g. Funktion berechnen, kommt als 
Ergebniss 0x922b heraus (Startwert 0xFFFF). Lasse ich das gleiche 
Datenpaket von div. Hexeditoren oder CRC Rechnern berechnen, geben diese 
(übereinstimmend) 0x4792 aus. Z.b. hier:

http://www.lammertbies.nl/comm/info/crc-calculatio...

Warum unterscheiden sich die Ergebnisse ?
Desweiteren habe ich irgendwo mal gelesen, dass die CRC 0x0000 ergibt, 
wenn man die CRC eines Blockes hinten mit anhängt. So ergibt das 
Datenpaket
  uint8_t data[] = {1, 2, 3, 4, 5, 6, 7, 8, 0x2b, 0x92};
mit der WinAVR Funktion brav 0x0000 aus, was auch bei den anderen 
Rechnern (mit der jeweiligen CRC) funktioniert. Allerdings ist mir 
aufgefallen dass man die CRC bei der WinAVR Funktion LSB anhängen muss 
(0x922b -> 0x2b, 0x92), bei den anderen Rechnern funktioniert das ganze 
nur wenn man die CRC MSB anhängt (0x4792 -> 0x47, 0x92).

Wo liegt also der Unterschied begraben ?

Gruß
Stefan

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, genau die ganze Konfusion um Bit- und Byteorder ist das Problem
der CRC-Routinen: selbst bei gleichem Polynom und gleichem Anfangs-
wert gibt es X verschiedene Varianten.  Tauschst du beispielsweise mal
die Bitorder deines Bitstrings um, d. h. nimmst du
  uint8_t data[] = {0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, 0x10};
dann erhälst du 0x49e2 als CRC.  Tauschst du dessen Bitorder wieder,
dann ist die CRC 0x4792 -- die von dir erwartete.

Der Algorithmus in _crc_ccitt_update() passt auf die tatsächlichen
CCITT-Übertragungen, ebenfalls auf die IEEE-Übertragungen, wobei
letztere (zumindest ist mir das in IEEE 802.15.4 so übern Weg
gelaufen) als Startwert 0 und nicht 0xffff nehmen.  All diesen
Übertragungen ist gemein, dass Bit 0 des LSB als erstes übertragen
wird (das beginnt bei einer simplen V.24-Übertragung).  Damit wird
bei einer übertragenen 0x01 lediglich das erste übertragenen Bit
gesetzt, alle anderen sind gelöscht.

Da die CRC selbst eine 16-bit-CRC ist, hast du dann auch noch das
Problem der Byteorder.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.