Hallo Zusammen Ich weis, das Thema wurde hier schon X-1000-mal behandelt, ich komme trotzdem nicht ganz nach wie man von einem Datenpacket, das CRC16 berechnet. Soviel hab ich verstanden: Das Generatorpolynom ist sozusagen der Schlüssel. Folgendes Beispiel hab ich soweit auch verstanden: http://de.wikipedia.org/wiki/Zyklische_Redundanzprüfung Im Beispiel wird als Nutzdaten nur ein Byte verwendet, aber wie schaut es aus, wenn man ein ganzes Datenpaket mit mehreren Bytes hat ? Wie funktioniert da die Berechnung ? Als einfaches Beispiel möchte ich aus folgenden Bytes das CRC16 berechnen: Datenpaket (DEZ): 150,23,45,122 Welches Generatorpolynom sollte verwendet werden ? Dies sollte 16bit sein (CRC16) richtig ? Kann da eine willkürliche Zahl verwendet werden ? Wie genau muss man nun vorgehen, um aus den 4 bytes das CRC16 zu erhalten ?
Entschuldige, aber was genau hast Du an dem Wikipedia-Artikel nicht verstanden? Verstehe mich bitte recht. Es ist durchaus legitim, das Du was nicht verstehst. Das geht allen so. Aber in dem Artikel ist jede Deiner Fragen beantwortet. Welche Aussage oder welches Detail verstehst Du nicht? Schreibe das bitte.
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 ... ?
Bei der Wahl des Generatorpolynom sollte man darauf achten, dass die gewünschten Fehlerentdeckungen enthalten sind. Also nicht einfach irgendwas nehmen, sondern am besten ein Polynom, das passt. Je nach Polynom können unterschiedliche Fehlerarten aufgedeckt werden (1 Fehler sicher, 2 Fehler mit x% usw.). Am besten etwas nehmen, was schon anderswo eingesetzt wird, z.B. (aus http://de.wikipedia.org/wiki/Zyklische_Redundanzprüfung#Polynome_und_Typen) CRC-CCITT. Das Ergebnis kann man auch ganz einfach hier prüfen: http://zorc.breitbandkatze.de/crc.html (Hexwerte mit % eingeben, also 0x2F => %2F). Das Ergebnis des ersten Bytes ist der Startwert des nächsten. Man kann sich das wie bei der Polynomdivision oder normaler Division von Hand vorstellen. Man arbeitet sich von vorne nach hinten durch und bestimmt den Rest, das eigentliche Ergebnis ist uninteressant, ähnlich wie bei der Modulo-Rechnung.
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.
Angehängte Dateien:
-
IMG_0058.jpg
110 KB -
IMG_0059.jpg
380 KB -
IMG_0060.jpg
370 KB
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.
:
Bearbeitet durch User
Karl Heinz schrieb: > Ein Byte hat 8 Bit. Was Blödsinn ist. Ein byte ist die kleinste adressierbare Einheit! Auf einem 320C40 ist ein Byte 32bit groß. Und nun?
> 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.
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?
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.
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.