CRC Berechnung

[CRC (Gast)]

Hallo,

ich habe einige Fragen zum Berechnen von CRC Werten.
Ich kann händisch ohne Probleme ein CRC Wert berechnen wenn ich einfach 
den Datensatz durch das Polynom teile. Das ganze auch ohne Probleme 
implementieren.
Jedoch sehe ich bei den ganzen fertigen implementationen, dass erst ein 
Anfangswert (oft 0xFF...) mit dem aktuellen Byte XOR wird und dann der 
CRC berechnet wird. Bei weiteren Bytes dann der aktuelle CRC mit dem 
neuen Byte XOR wird.
Meine Frage ist nun, ist am Ende der CRC der selbe (natürlich mit den 
0xFF... dem Datensatz vorangestellt), oder ist es einfach eine anderer 
Wert aber mit selben Fehlerabstand?
Zweite Frage ist, wie und wo das neue Byte bei einem CRC der größer als 
XOR werden muss. An höchster Stelle oder an niedrigster stelle?


Danke für Hilfe!

[Georg G. (df2au)]

CRC schrieb:
> Meine Frage ist nun, ist am Ende der CRC der selbe (natürlich mit den
> 0xFF... dem Datensatz vorangestellt), oder ist es einfach eine anderer
> Wert aber mit selben Fehlerabstand?
Es kommt ein anderer CRC heraus. Startwert=0 hat den Nachteil, dass 
fehlende oder zusätzliche Nullen am Anfang der Daten nicht erkannt 
werden.

> Zweite Frage ist, wie und wo das neue Byte bei einem CRC der größer als
> XOR werden muss. An höchster Stelle oder an niedrigster stelle?
Diese Frage verstehe ich nicht.

Vor wenigen Tagen war hier ein Thread über CRC. Dort wurde lang und 
breit über das Verfahren erzählt. Hast du dir das einmal durchgelesen?

[CRC (Gast)]

Hallo,

danke für den Tip mit dem Thread, könnte jemand mir den groben Namen 
sagen, das ich weiß wonach ich suchen muss?

Zu meiner zweiten Frage:
Angenommen ein 2 Byte CRC und 1 Byte Daten Blöcke. Muss ich die Daten 
jetzt mit dem High- oder dem Lowbyte des alten CRC XOR vor dem 
weiterrechnen?

[faulty (Gast)]

vielleicht der hier?
Beitrag "CRC-Berechnung für HDLC-Format"

[Georg G. (df2au)]

Da findest du dann auch die Antwort auf die "welches Byte" Frage.

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

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

[CRC (Gast)]

Hallo,

danke für die Hilfe.

Jetzt bin ich aber auch noch auf ein anderes Problem gestoßen.
Eigentlich schiebt man führende 0er ja aus der aktuellen berechnung 
raus:
Bsp:
10010001 11011011 00000000
10001001 00110101
00011000 11101110 00000000
   10001 00100110 101
   01001 11001000 10100000
    1000 10010011 0101
    0001 01011011 11110000
       1 00010010 0110101
         01001001 10011010

Doch eine Routine von Peter Danegger sieht so aus:

URXCint:
        ldi     xh, high(rx_buff)
        in      ia0, UDR
        st      x+, ia0
;                                       calculate CRC
        in      savesreg, sreg
        eor     crc_lo, ia0
        ldi     ia0, 8
_crc1:  lsr     crc_hi
        ror     crc_lo
        brcc    _crc2
        eor     crc_lo, poly_lo
        eor     crc_hi, poly_hi
_crc2:  dec     ia0
        brne    _crc1
        out     sreg, savesreg
;
        reti

Und schiebt sogar noch die Führende 1 mit raus. Ist das der 
Code-Kompakheit geschuldet, oder habe ich was falsch verstanden?