CRC-Berechnung für HDLC-Format

Hallo Narf,

vielen Dank für deine Antwort.

Hab da mal rein geschaut, aber im Detail wird das leider auch nicht 
erklärt. Da steht eigentlich nur das, was ich schon wusste. Dennoch 
vielen Dank!

Bei CRC gibt es n+1 Möglichkeiten. "HDLC" sagt erst einmal nicht viel. 
Es gibt unterschiedliche Anfangswerte und unterschiedliche Polynome. Und 
man kann erst das LSB oder das MSB senden. Genormt ist da nichts. Es 
hilft dir nur probieren (oder den Autor der Software befragen, die das 
sendet).

Hallo Georg,

vielen Dank für deine Antwort.

Georg G. schrieb:
> Es gibt unterschiedliche Anfangswerte und unterschiedliche Polynome. Und
> man kann erst das LSB oder das MSB senden.

- Das Polynom ist ja bekannt.
- In der Spezifikation des Busses steht, dass man zu erst das MSB 
sendet.
- der Anfangwert ist 0xFFFF ( was auch immer der Anfangswert sein soll 
... )

Reicht das aus, um den CRC-Wert zu bestimmen?

_________________________________
Ergänzung:

Georg G. schrieb:
> "HDLC" sagt erst einmal nicht viel

Ist im HDLC-Format nicht festgelegt wie die CRC-Wert/Berechnung aussehen 
soll?

Moe Espunkt schrieb:
> Ist im HDLC-Format nicht festgelegt wie die CRC-Wert/Berechnung aussehen
> soll?

Leider nein, HDLC beschreibt, wie Frames aussehen (Flag, Daten, CRC, 
Flag) und wie zB. Bitstuffing gemacht wird.

Übrigens, Norm... dein Polynom ist eigentlich typisch für HDLC. Bei 
Herrn IBM nahm man aber X16 + X15 + X2 + 1.

Die CRC-Prüfsumme wird üblicherweise mit 0xffff initialisiert.

Wenn ich das ganz theorethisch betrachte, dann müsste doch die 
CRC-Berechnung folgende sein:

Daten+16 Nullen dran       FA010000 (hex)
--------------------   =   -----------------
Generatorpolynom           10001000000100001 (binär)

Der Rest dieser Division müsste ja der CRC-Wert sein. Das ganze hab ich 
mal in Wolfram Alpha eingegeben und es kommt nicht der gewünschte wert 
von "B69F" raus!! Dabei habe ich mich ganz genau an die Literatur 
gehalten !!

Wolfram Alpha liefert nämlich "BEF1":
http://www.wolframalpha.com/input/?i=%28FA010000+base+16%29+mod+%2810001000000100001+base+2%29

Aber wo ist bloß mein Denkfehler? Was mache ich Falsch? Das kann doch 
unmöglich so schwer sein?

_______________________________
Ergänzung:

Verwende ich den folgenden Online CRC-Rechner, kommt das richtige raus 
unter folgender Eingabe:

http://www.zorc.breitbandkatze.de/crc.html

CRC-Order: 16
CRC-Polynom: 1021
Inital Value : FFFF
Final XOR value: FFFF
reverse data bytes :ON
reverse CRC result before Final XOR: ON

Eingabe : %FA%01

Moe Espunkt schrieb:
> Der Rest dieser Division müsste ja der CRC-Wert sein. Das ganze hab ich
> mal in Wolfram Alpha eingegeben und es kommt nicht der gewünschte wert
> von "B69F" raus!! Dabei habe ich mich ganz genau an die Literatur
> gehalten !!

Naja, fast... Du hast den Startwert 0xffff ignoriert (der bei HDLC 
üblich ist).

Georg G. schrieb:
> Naja, fast... Du hast den Startwert 0xffff ignoriert (der bei HDLC
> üblich ist).

Wie lasse ich denn den Startwert 0xFFFF in die Rechnung mit einfließen? 
Weiß ehrlich gesag nicht, was ich mit diesem Startwert anfangen soll ...

Aus Wikipedia:


Schieberegister := Startwert
solange Bits im Datenstrom verbleiben:
  falls  das am weitesten links stehende Bit vom Schieberegister
        ungleich dem nächsten Bit aus dem Datenstrom ist:
    Schieberegister := (Schieberegister linksschieben um 1, rechtes Bit 
0)
                       xor CRC-Polynom
  andernfalls:
    Schieberegister := Schieberegister linksschieben um 1, rechtes Bit 0
  nächstes Bit im Datenstrom
Schieberegister enthält das Ergebnis.

Oft findet man andere Startwerte, etwa 1111…. Dies entspricht einer 
Polynomdivision, wenn die ersten n Bits des Datenstroms invertiert 
werden.

Ende Wikipedia

Sieh dir mal die CRC-Lib aus dem Atmel Studio an.
Wenn CRC Erzeugung oder Check schnell gehen muss, macht man das mit 
Tabellen.

Beispiel (mit falscher und deshalb gekürzter Tabelle). crc wird vor dem 
ersten Aufruf mit dem Startwert initialisiert. Funktion wird für jedes 
Byte des Datenstromes aufgerufen. crc enthält den zu übertragenden 
CRC-Wert.

static void calc_crc(WORD *crc, BYTE c)
{
  static const WORD Crc_table[] = {
    0x0f87, 0x1e0e, 0x2c95, 0x3d1c, 0x49a3, 0x582a, 0x6ab1, 0x7b38,
...
    0xf808, 0xe981, 0xdb1a, 0xca93, 0xbe2c, 0xafa5, 0x9d3e, 0x8cb7,
    0x7440, 0x65c9, 0x5752, 0x46db, 0x3264, 0x23ed, 0x1176, 0x00ff
  };

  *crc = (*crc << 8) ^ Crc_table[(*crc >> 8) ^ c];
}

Hallo Tiramisu,

vielen Dank für deine sehr hilfreiche Antwort.

Ich habe das jetzt ebenfalls mit Python (Pycrc) gemacht. Als Ergebnis 
erhalte ich jedoch folgendes:

C:\Python27>python pycrc.py --model x-25 --check-string="FA01"
0x6bf1

Irgendwie schon kurios oder? Eine Vermutung voran es liegen könnte?
Ich überlege langsam einfach die CRC-Berechnung selber zu programmieren 
in dem ich einfach ein Schieberegister mit XOR-Verknüpfungen realisiere.
Kann ja "eigentlich" nicht so schwer sein den CRC-Code zu implementieren 
...
Geht wahrscheinlich schneller als, wenn ich mich jetzt in andere Codes 
einarbeite.

Wer lesen kann ist klar im Vorteil :

es heißt "HEXSTRING"  und nicht "STRING" !

also : C:\Python27>python pycrc.py --model x-25 --check-hexstring="FA01"
0x9fb6