CRC16 berechnen

Also im beispiel wird aus 1 byte (Nutzdaten) das CRC berechnet. Soweit 
klar.

Hab ich nun meherer bytes als nutzdaten, wie muss ich nun vorgehen ? Aus 
dem ersten byte crc berechnen, das zweite byte zum crc dazu addieren, 
wieder crc berechen, drittes bytes zum crc addieren, wieder crc 
berechnen, usw ... ?

Michael L. schrieb:
> Also im beispiel wird aus 1 byte (Nutzdaten) das CRC berechnet. Soweit
> klar.

Nicht wirklich.
Denn wenn man genau liest, dann steht da nicht 1 Byte. Das da genau 8 
Bits verrechnet werden ist mehr oder weniger zufällig so.

Wenn du das Array 'datastream' entsprechend größer machst und anstelle 
von 8 in databits die korrekte Zahl einträgst, dann geht das auch mit 
mehr als nur 1 Byte.

> Hab ich nun meherer bytes als nutzdaten, wie muss ich nun vorgehen ?

Die gezeigte Implementierung in Wikipedia ist da etwas unglücklich 
gewählt. In der Praxis hat man eine CRC Funktion, der man 1 Byte samt 
bisheriger CRC reingibt und die dieses eine Byte auf die CRC aufrechnet. 
Man kriegt dann die modifizierte CRC zurück, die man dann zum Beispiel 
weiter behandelt, indem man sie mit dem nächsten Byte und eben diese CRC 
erneut in die CRC Funktion steckt, woraufhin man dann die nächste 
modifizierte CRC bekommt.
Das ganze ist also meistens ein schleifenartiger Prozess

1

  crc = Startwert;

2

3

  for( i = 0; i < Anzahl der Bytes; i++ )

4

    crc = berechne_crc( byte[i], crc );

5

6

  mach was mit der über alle Bytes berechneten crc

Es gibt genug frei verfügbare Implementierungen im Web. Schau dir ein 
paar an. Meist wirst du auf so einen oder einen ähnlichen Mechanismus 
stossen. Nicht gegen Wikipedia. Aber in Punkte "Darstellung von 
Algorithmen" ist es nicht das Non-Plus-Ultra. Da fährt man besser, wenn 
man sich auf ein paar unterschiedlichen Web-Seiten ein paar 
Implementierungen ansieht und sich die Gemeinsamkeiten und Unterschiede 
ansieht.

Ist das so richtig, wenn ich einfach alle bytes aneinander hänge ?

Auf dem Papier funktionierts.

Das kann nicht richtig sein.
Denn 10111 ist kein Byte. Ein Byte hat 8 Bit. Immer. Selbst wenn da 
einige Bits als führende 0-en zu bezeichnen sind.


Logisch funktioniert das bei dir.
CRC ist ja so gebaut, dass man beliebige Bitzahlen reinstecken kann.
Aber: mit den Vorgaben steckst du andere Bits in dein Verfahren rein, 
als es jeder andere auf diesem Planeten tun würde.
D.h. mit deinen Zahlen kriegt jemand anderer einen anderen CRC Wert 
raus. Der natürlich so gemacht ist, dass sich bei ihm auch wieder alles 
am Ende aus geht.

> Ein Byte hat 8 Bit.

Ist mir schon klar

Ich dachte, ich könnte die führenden nullen weglassen.


> als es jeder andere auf diesem Planeten tun würde

Aber wie genau muss ich denn das machen ? Die ganzen bytes inkl. nullen 
aneinander hängen ? Oder alles total falsch ??

Mr.T schrieb:
> Karl Heinz schrieb:
>> Ein Byte hat 8 Bit.
>
> Was Blödsinn ist. Ein byte ist die kleinste adressierbare Einheit!

Auf deiner Architektur vielleicht. In der Programmiersprache in de rdu 
arbeitest.

> Auf
> einem 320C40 ist ein Byte 32bit groß. Und nun?

Dann nennt man das ein Double-Word. Niemand hat ein Problem damit, dass 
auf dieser Architektur die kleinste adressierbare EInheit ein DWord ist.

Fred schrieb:
> Karl Heinz schrieb:
>>> Auf
>>> einem 320C40 ist ein Byte 32bit groß. Und nun?
>>
>> Dann nennt man das ein Double-Word. Niemand hat ein Problem damit, dass
>> auf dieser Architektur die kleinste adressierbare EInheit ein DWord ist.
>
> Und C nennt diese kleinste Einheit eben "Byte". Aber das weißt du doch?

Hier gehts aber nicht um C. Hier geht es um die Berechnung einer CRC 
ganz allgemein.

Die Kapazität eines Bytes auf deiner Festplatte ist 8 Bit.
Ein Grafikspeicher mit 1024 Bytes, besteht aus 1024*8 Bits.
Wenn 3 Nutzbytes über eine Schnittstelle übertragen werden, dann sind 
das 3 mal 8 gleich 24 Bit.
...

Völlig unabhängig davon, wieviele Bits dein µC zu einer addressierbaren 
Einheit zusammenfasst.

> Und C nennt diese kleinste Einheit eben "Byte". Aber das weißt du doch?

C nennt die kleinste Einheit "char" und das ist definiert mit 1 Char = 1 
Byte. Was dazu führt, dass auf Architekturen mit 16 oder 32 Bit 
minimaler Wortbreite das char und damit das Byte eben 16 oder 32 Bit 
breit ist.

Phantomix Ximotnahp schrieb:
>> Und C nennt diese kleinste Einheit eben "Byte". Aber das weißt du doch?
>
> C nennt die kleinste Einheit "char" und das ist definiert mit 1 Char = 1
> Byte.

Was darauf hinausläuft, das C seine eigene Vorstellung davon hat, was 
ein Byte ist.
Die kann, muss aber nicht, mit dem übereinstimmen, was landläufig unter 
einem Byte verstanden wird.

Wenn mir aber jemand eine händische CRC Berechnung auf Papier 
unterjubelt auf der der Begriff 'Byte' vorkommt, dann wende ich die 
landläufige Sichtweise an, was ein Byte ist und sicher nicht das was C 
darunter versteht. Abgesehen davon, dass auf dem Papier der 
konzeptionell gleiche Fehler gemacht wird, egal ob man nun 1 Byte mit 8 
Bit annimmt oder mit mehr.

So gesehen kann man sich an der Verwendung des Wortes 'immer' stossen. 
Man hätte es aber auch damit gut sein lassen können, denn ein C-Byte ist 
nicht dasselbe, was der Rest der EDV Welt unter einem Byte versteht. Und 
hier war ganz klar erst mal nicht von C die Rede.

Karl Heinz schrieb:
> Was darauf hinausläuft, das C seine eigene Vorstellung davon hat, was
> ein Byte ist.
> Die kann, muss aber nicht, mit dem übereinstimmen, was landläufig unter
> einem Byte verstanden wird.

Ack.

> So gesehen kann man sich an der Verwendung des Wortes 'immer' stossen.

Hab ich hiermit getan. Andere Leute stoßen sich an Worten wie "Byte" ;-) 
Egal also.

Der Übersicht halber würde ich aber die führenden Nullen immer mit 
hinschreiben, sonst führt das nur zu Verwirrungen (siehe oben)

Mit http://zorc.breitbandkatze.de/crc.html wurde ja schon der wichtigste 
Link genannt der dem Threadersteller helfen könnte...