Ckecksum Berechnung mit Startwert

chisna schrieb:
> Was ich nicht verstehe
> ist, wie man den Startwert mit in die Berechnung einbringt.

Dann schau dir mal die Funktion an, die den CRC berechnet. Garantiert 
findet sich dazu ein Beispiel in C. Und dann weißt du auch, wie der 
Startwert verarbeitet wird.

Einen guter Überblick über CRC & Co. enthält das Dokument im Anhang 
(Author: Ross N. Williams).

Diese Seite hat mir geholfen:

http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

Yalu X. schrieb:
> chisna schrieb:
>> Muss es echt dringend verstehen.
>
> Warum? Sitzt du gerade in einer Prüfung?
>
> Wenn nicht: In Wikipedia und gefühlten 1000 weiteren Webseiten ist doch
> alles (einschließlich dem Startwert) haarklein erklärt. Was konkret
> verstehst du daran nicht?

Ich habe mir die Seiten schon alle angeguckt so ist es  nicht. Habe die 
Berechnung mit Startwert= 0 auch verstanden. Mir fehlt das Verständnis, 
wie berechnet wird wenn der Startwert nicht gleich 0 ist sondern einen 
bestimmen Wert hat. Also wie in dem Beispiel oben. Vielleicht kann es 
jemand Handschriftlich lösen für ein besseres Verständnis. Das würde mir 
echt sehr weiterhelfen.

und nein bin in keiner Prüfung haha
Ist nur wichtig damit ich weiter komme in einem Projekt in der Uni

chisna schrieb:
> Habe die Berechnung mit Startwert= 0 auch verstanden.

Dann setz halt für 0 den Wert xFF ein, und versteh es genauso.

> Hier findest du eine einfach zu verstehende ...

Besser ist es er versteht wie & warum der CRC funktioniert.

Joe F. schrieb:
> verständlicher wäre: return (crc ^ 0xFF);

Es ist dabei verwirrend, dass 0xFF nun 3 verschiedene Bedeutungen hat:
Startwert
Int zu 8 Bit abschneiden
Invertiermaske

Just saying

Joe F. schrieb:

> Die letzte Zeile in crc8() finde ich etwas unglücklich:
>
>

1

> return (~crc)&0xFF;

2

>

>
> verständlicher wäre:
>

1

> return (crc ^ 0xFF);

2

>

Verständlicher vielleicht. Aber u.U. auch schlicht falsch...

Kommt drauf an, wie im Kern der Sache genau gerechnet wird. Da gibt es 
viele Implementierungen, die zugunsten der Performance im Kern nur 
sicherstellen, das die unteren Bits korrekt sind. Dann muss am Ende 
maskiert werden und genau das ist, was deine bevorzugte Variante eben 
nicht tut, die von dir beanstandete aber schon.

Joe F. schrieb:

> Die Funktion
> unsigned char crc8()
> kann nur die unteren 8 Bit zurückgeben.

Das ist richtig. Richtig ist aber auch: richtige Programmiersprachen 
würden meckern, wenn du einfach was wegschneidest, ohne explizit 
hinzuschreiben, dass das deine Absicht ist.

Genau deswegen, weil C solch einen Programmierer-Schmutz zuläßt, ist es 
so hassenswert.

Trügerische Sicherheit eines de facto nicht wirklich vorhandenen 
Typsystems.

Da nimmt man besser gleich Assembler.

Aber: zumindest eine klitzekleine Warnung sollten heutige C-Compiler 
doch zumindest auch werfen?

c-hater schrieb:
> Genau deswegen, weil C solch einen Programmierer-Schmutz zuläßt, ist es
> so hassenswert.

Das Problem ist eher, dass die Leute kein lint hernehmen wollen, und 
dass sie über K&R nicht rausgekommen sind.
Wenn ich unsigned char oder long int lese, dreht's mir die Zehennägel 
auf. Das heißt uint8_t und uint32_t. Sonst nix.


Nick