crc8 Tabelle Ich versteh es einfach nicht :(

[Hans (Gast)]

Hallo,

ich hab ein Problem.
Wenn ich von einem 0xff die crc Summe berechne bekomme ich 0xff.
Das kann noch nicht sein...

Soweit ich da verstehe wird die crc Tabelle richtig gebildet.
Aber die crc Summe wird falsch gebildet.

Ich find den Fehler einfach nicht. Steh grade auf dem Schlauch.

[Gustav (Gast)]

Standardantwort für CRC-Berechnungen: http://www.zlib.net/crc_v3.txt

[Hans (Gast)]

Hab ich schon gelesen.
Trotzdem bleibt die Birne dunkel...

[Erich (Gast)]

http://www.barrgroup.com/Embedded-Systems/How-To/CRC-Calculation-C-Code

[Karl H. (kbuchegg)]

unsigned char p[] =
    { 0, 4, 5, 8 };   //
    unsigned int n, k;

    // make exclusive-or pattern from polynomial
    poly = 0;
    for ( n = 0; n < sizeof( p ) / sizeof(unsigned char) ; n++ )
        poly |= 1 << ( 7 - p[n] );

? Im 4. Durchlauf durch die Schleife
7 - 8 ergibt -1

was ergibt 1 << (-1)?
Gute Frage. Bin ich ehrlich gesagt überfragt, ob das definiert ist.

[Marc V. (Firma: Vescomp) (logarithmus)]

Karl Heinz schrieb:
> was ergibt 1 << (-1)?
> Gute Frage. Bin ich ehrlich gesagt überfragt, ob das definiert ist.

 0.
 Es sei denn, du arbeitest mit 256-bit uC.

[Tiramisu (Gast)]

>> { 0, 4, 5, 8 }
Das "oberste" Bit ist immer implzit "1" in einem CRC Polynom,
das kann man in einem Byte mit den Bits 0-7 schlecht setzen,
IMHO mit sehr hoher Wahrscheinlichkeit falsch.

Die Polynomdarstellung ist ungewoehnlich "andersrum", aber das muss
nicht inkorrekt sein, massgeblich waere wie die Daten serialisiert
sind.

[Jasch (Gast)]

Marc Vesely schrieb:
> Karl Heinz schrieb:
>> was ergibt 1 << (-1)?
>> Gute Frage. Bin ich ehrlich gesagt überfragt, ob das definiert ist.
>
>  0.
>  Es sei denn, du arbeitest mit 256-bit uC.

Unwahrscheinlich, 256 Bits oder nicht.

C99 sagt dazu: "If the value of the right operand is negative or is
greater than or equal to the width of the promoted left operand, the 
behavior is undefined."

Was immer konkret passiert, passiert, für den C-Standard ist's OK. Was 
in der wirklichen Welt passiert kann sich ganz real z.B. zwischen 
Compilerversionen, Compileroptionen usw. usf. unterscheiden. Hab ich 
schon gesehen sowas...

[Marc V. (Firma: Vescomp) (logarithmus)]

Jasch schrieb:
>>  0.
>>  Es sei denn, du arbeitest mit 256-bit uC.
>
> Unwahrscheinlich, 256 Bits oder nicht.

 War ja auch nicht ernst gemeint.
 Aber ein guter Compiler sollte sich schon darüber beschweren, vor
 allem da es definiert ist, dass nach so einer Operation das resultat
 undefiniert ist...

 EDIT:
 Oops, keine Konstante, sondern Ergebnis, sorry.

[Hans (Gast)]

unsigned char p[] =
    { 0, 4, 5, 8 };   //
    unsigned int n, k;

    // make exclusive-or pattern from polynomial
    poly = 0;
    for ( n = 0; n < sizeof( p ) / sizeof(unsigned char) ; n++ )
        poly |= 1 << ( 7 - p[n] );

Den Inhalt des Array habe ich auch mit anderen crc8 mit Polynom 0x8c 
verglichen.
Die Arrays waren gleich. Deswegen gehe ich davon aus dass zumindest 
dieser Teil richtig funktioniert.

Ich verstehe nur nicht wieso ich für 0xff die checksumme oxff bekomme.

[Hans (Gast)]

PS:
Wer sich über die Definition unterhalten will soll bitte einen anderen 
Thread öffnen.

Ich hab den Code geändert und poly = 0x8c gesetzt.

[Karl H. (kbuchegg)]

Hans schrieb:
>

unsigned char p[] =
>     { 0, 4, 5, 8 };   //
>     unsigned int n, k;
> 
>     // make exclusive-or pattern from polynomial
>     poly = 0;
>     for ( n = 0; n < sizeof( p ) / sizeof(unsigned char) ; n++ )
>         poly |= 1 << ( 7 - p[n] );

>
> Den Inhalt des Array habe ich auch mit anderen crc8 mit Polynom 0x8c
> verglichen.
> Die Arrays waren gleich. Deswegen gehe ich davon aus dass zumindest
> dieser Teil richtig funktioniert.


Das ändert nichts daran, dass 7 minus 8 zu einem Ergebnis von -1 führt 
und ein -1 in einer << Operation zu einem undefiniertem Eregbnis führt. 
Sorry, aber darüber brauchen wir wirklich nicht diskutieren.

Was hast du denn als Vorbild genommen? (Link)

[Karl H. (kbuchegg)]

Hans schrieb:
> PS:
> Wer sich über die Definition unterhalten will soll bitte einen anderen
> Thread öffnen.

Ich glaub, dir ist die Bedeutung von 'undefiniertem Verhalten' nicht 
klar!
undefiniertes Verhalten bedeutet schlicht und ergreifend, dass es kein 
gesichertes Ergebnis gibt. Jedes Ergebnis ist aus Sicht des Compilers 
richtig. Daher brauchst du dich nicht zu wundern, dass du 'es einfach 
nicht verstehst'. Dein Code könnte genausogut würfeln und das Ergebnis 
wäre als richtig anzusehen.
Dieses undefinierte Verhalten muss erst mal aus deinem Code raus. Vorher 
ist es müssig, sich über irgendwelche Ergebnisse und wie sie zustande 
kommen zu unterhalten.

[Hans (Gast)]

Was beim undefinierten verhalten alles passieren kann ist mit klar!

Nichts destotrotz.
Ich hab diese Schleife aus dem Code gelöscht!!! Und poly = 0x8c gesetzt.
Also ist da kein undefiniertes verhalten mehr!

Trotzdem hab ich für 0xff ein crc von 0xff.
Denn link selbst hab ich nicht mehr.

Habe aber die erstelle Tabelle unter anderem mit dem hier abgeglichen.

http://www.bidib.org/support/crc_code.html

Sie sind gleich!
Ich gehe davon aus dass ich hier ein Fehler hab.

uint8_t crc_8( uint8_t crc, void *buffer, uint8_t len )
{
    unsigned char *buf = (uint8_t *) buffer;
    crc = crc ^ 0xff;

//    uint8_t x = ( crc ^ ( *buf++ ) ) & 0xff;
//    uint8_t z = (x ^ ( crc >> 8 ));


    if ( len )
        do
        {
            crc = _crcTable[( crc ^ ( *buf++ ) ) & 0xff] ^ ( crc >> 8 );
        } while ( --len );

    return crc ^ 0xFF;
}

[Stefan E. (sternst)]

 crc = _crcTable[( crc ^ ( *buf++ ) ) & 0xff] ^ ( crc >> 8 );

"^ ( crc >> 8 )"ist ein NOP. Was war der ursprüngliche Gedanke dahinter?

    unsigned char *buf = (uint8_t *) buffer;

Warum einmal unsigned char und einmal uint8_t?

    if ( len )
        do
        {
        ...
        } while ( --len );

Interessante Konstruktion.
War dir ein "while (len--) {}" zu langweilig?

Aber das sind alles Nebensächlichkeiten.
Dein eigentliches Problem dürfte hier liegen:
> Wenn ich von einem 0xff die crc Summe berechne bekomme ich 0xff.
> Das kann noch nicht sein...
Wieso kann das nicht sein? Was ist dein Problem damit?

[Hans (Gast)]

Nun ja ich hab meinen Code mit dem Ergebnis hier kontrollieren wollen.

http://www.zorc.breitbandkatze.de/crc.html
CRC order  8
CRC polynom 8c
Initial value 0 oder ff hab beide probiert.
Final XOR value ff

reverse data bytes  AN & AUS gemacht
reverse CRC result before Final XOR

Data sequence 0xff

Ich komme einfach nicht auf 0xff als crc für 0xff.

Aber vielleicht sollte ich mich dem Thema noch mal widmen wenn die 
Erkältung überstanden ist...

[Felix P. (fixxl)]

Wie hast du die Data Sequence eingegeben? Wenn du dez 255, also ff als 
ein Datenbyte als Eingabewert willst, musst du %ff eingeben. Bei 0xff 
schiebt er die vier Chars '0', 'x', 'f', 'f' durch und es ergibt sich 
ein anderes Ergebnis bei Groß- und Kleinschreibung.

Einstellungen für die Dallas/Maxim-CRC8 (x^8+x^5+x^4+1) sind:

CRC order: 8
CRC polynom: 31
Initial value: 0
Final XOR value: 0

Reverse data bytes und reverse CRC result before Final XOR sind beide 
angeklickt.

[Rolf M. (rmagnus)]

Hans schrieb:
> Ich hab diese Schleife aus dem Code gelöscht!!!

BRÜLL NICHT SO RUM!!! Außerdem hättest du das ja gleich sagen können. Du 
hattest ja nur erwähnt, daß du "den Code geändert" hättest. Was du 
geändert hast, kann ja keiner riechen.

>             crc = _crcTable[( crc ^ ( *buf++ ) ) & 0xff] ^ ( crc >> 8 );

crc >> 8 ist immer 0, da crc nur 8 Bit breit ist.