|
Anzeige
|
crc8 Tabelle Ich versteh es einfach nicht :(
Gast
#3785572
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.
Gast
#3785575
Standardantwort für CRC-Berechnungen: http://www.zlib.net/crc_v3.txt
Gast
#3785586
Hab ich schon gelesen. Trotzdem bleibt die Birne dunkel...
Gast
#3785628
? 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. 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.
Gast
#3786338
>> { 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.
Gast
#3786530
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... 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.
Gast
#3786696
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.
Gast
#3786699
PS: Wer sich über die Definition unterhalten will soll bitte einen anderen Thread öffnen. Ich hab den Code geändert und poly = 0x8c gesetzt. Hans schrieb: >
> > 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) 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.
Gast
#3786768
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.
"^ ( crc >> 8 )"ist ein NOP. Was war der ursprüngliche Gedanke dahinter?
Warum einmal unsigned char und einmal uint8_t?
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?
Gast
#3787035
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... 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. 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. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
