hallo, ich habe einen Sender und Empfänger. der Sender überträgt ein array von bytes. die übertragung möchte ich mit einer CRC überprüfen. kann ich jetzt die CRC vom sender berechnen lassen und dem empfänger mitteilen und der berechnet ebenfalls die CRC und vergleicht die beiden? oder kommt da immer was unterschiedliches raus und der empfänger muss nur seine CRC ermitteln und durch das generatorpolynom teilen und wenn der Rest 0 ist ist die übertragung ok. kann dazu jemand kurz was sagen? danke
CRC ist eher für den Empfänger gedacht. Er Prüft damit ob das was er bekommen hat valid ist. Soweit ich das noch in Erinnerung habe, muss man ja (bei einem Byte) noch ein Paritätsbit mitsenden und ein zusätzliches Byte nach dem Ende des Arrays. Somit kann ja der Empfänger ohne Kommunikation gleich Prüfen, ob was nicht stimmt... Wenn also der Empfänger das CRC gemacht hat und einen Fehler erkannt hat, kann er den Datenblock nochmal anfordern. Gruß Steven
ok danke. also lass ich den empfänger das crc berechnen wenn alle bytes empfangen wurden und teile das durchs polynom und wenn nicht 0 raus kommt forder ich die daten neu an. danke
also das funktioniert soweit, aber ab einem bestimmten telegram erhalte ich immer den rest 1 obwohl alles gleich ist wie bei den anderen telegrammen, also außer der inhalt des telegrammes. aber die daten sind korrekt
Hast Du das Paritätsbit für das Paritätsbyte mitgesendet?
ich denk doch mal. ich schick des über den serial1 Port eines visual basic programmes
Die einfachste Variante ist folgende: Der Sender berechnet die CRC über die Daten, versendet die Daten und die CRC. Der Empfänger empfängt die Daten und die CRC. Der Empfänger berechnet auch die CRC über die Daten und vergleicht sie mit der empfangenen CRC. Falls beide gleich sind: Übertragung hat wunderbar funktioniert :-) Falls sie nicht gleich sind: Bei der Übertragung gab es Fehler :-(
Der schrieb: > Der Empfänger empfängt die Daten und die CRC. > Der Empfänger berechnet auch die CRC über die Daten und vergleicht sie > mit der empfangenen CRC. ich glaube der Trick ist, das der Emfpfänger über alles (Daten+CRC) die CRC berechnet und wenn man ende 0 rauskommt, dann stimmt alles. Es muss also nicht beide CRCs vergleichen.
Also soweit ich das noch im Kopf habe wird einfach folgendes gemacht: Für jedes Byte das gesendet wird wird die Anzahl der 1en in diesem Byte genommen und ermittelt ob diese Anzahl gerade oder ungerade ist. Ist sie gerade wird eine 1 zusätzlich übermittelt ansonsten eine 0. Das passiert für jedes Byte. Das sind in der Regel Even-Bits Ganz am Ende wird ein Byte gesendet welches Even-Bits enthalten, die für die 8 Spalten aller Bytes gedacht sind. Wenn ich mich nicht irre hat dieses letzte Byte dann aber kein 9. Evenbit. Oder doch? Muss man halt mal googlen. Es reicht, wie Peter II schon schrieb, dass der Empfägner das CRC durchführt bzw. berechnet. Gruß Steven
Steven () schrieb: > Für jedes Byte das gesendet wird wird die Anzahl der 1en in diesem Byte > genommen und ermittelt ob diese Anzahl gerade oder ungerade ist. Ist sie > gerade wird eine 1 zusätzlich übermittelt ansonsten eine 0. > Das passiert für jedes Byte. Das sind in der Regel Even-Bits Das sind Parität-Bits, und die haben rein gar nichts mit CRC zu tun. Das sind zwei komplett unterschiedliche Konzepte.
Oh sorry, da hab ich was durcheiandergebracht. CRC ist ja das mit den Polynomen... Gruß Steven
Peter II schrieb: > Der schrieb: >> Der Empfänger empfängt die Daten und die CRC. >> Der Empfänger berechnet auch die CRC über die Daten und vergleicht sie >> mit der empfangenen CRC. > > ich glaube der Trick ist, das der Emfpfänger über alles (Daten+CRC) die > CRC berechnet und wenn man ende 0 rauskommt, dann stimmt alles. Es muss > also nicht beide CRCs vergleichen. Es geht beides.
ahhhhh ihr bringt mich noch mehr durcheinander. also zuerst habe ich versucht von sender und empfänger die CRCs berechnen zu lassen und dann vergleichen. aber die bekommen irgendwie immer was unterschiedliches raus, obwohl das Polynom genau gleich ist. weis nicht woran das liegt.
>also zuerst habe ich versucht von sender und empfänger die CRCs >berechnen zu lassen und dann vergleichen. Dann zeig mal wie du das machst.
crcler schrieb: > aber die bekommen irgendwie > immer was unterschiedliches raus, obwohl das Polynom genau gleich ist. > weis nicht woran das liegt. Um welches CRC-Verfahren handelt es sich denn? Es geht nicht nur um das Generatorpolynom, der Startwert des Registers und die Reihenfolge der Übermittlung durch den Sender ist ebenfalls wichtig. Am Beispiel des CCITT-CRC (Link-Layer von X.25): Sender: Der Initialwert ist 0xFFFF. Der CRC wird über über alle Bytes der Nachricht berechnet, das Ergebnis wird invertiert (Einerkomplement!) und in der Reihenfolge low byte, high byte übertragen. Der Empfänger initialisiert ebenfalls mit 0xFFFF, berechnet den CRC über alle empfangenen Zeichen einschließlich der beiden übertragenen CRC-Bytes, das Ergebnis der Berechnung muss 0xF0B8 sein. Andere Verfahren verwenden andere Startwerte, ebenfalls gibt es unterschiedliche Vorgaben für die Bitreihenfolge bei der Übertragung. Du musst es so machen, wie es das von dir verwendete Verfahren vorgibt! Alles andere führt zu nichts. Welches Verfahren ist es denn nun? Grüße Stefan
Stefan Wagner schrieb: > Welches Verfahren ist es denn nun? Das weis ich nicht so genau. also wenn ich bei dem Mikrocontroller im debugger schaue, dann seh ich das wenn ich das CRC Register Resete das es dann den Wert 0xFFFF FFFF hat. also nehme ich den Startwert 0xFFFF FFFF an. in dem Datenblatt des Controllers steht nur das das Generatorpolynom 0x4C11DB7 wie bei Ethernet. Darunter steht dann noch folgendes: – X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 +X8 + X7 + X5 + X4 + X2+ X +1 und es ist natürlich ein CRC 32 bit
crcler schrieb: > in dem Datenblatt des Controllers steht nur das das > Generatorpolynom Jetzt kommen wir der Sache näher. a) Welcher Controller ist das? b) Muss sich deine Anwendung an Vorgaben halten? Oder legst du das Verfahren fest? Grüße Stefan PS: Diese Informationen, ganz zu Anfang gegeben, hätten viel Raterei erspart.
Stefan Wagner schrieb: > a) Welcher Controller ist das? > b) Muss sich deine Anwendung an Vorgaben halten? Oder legst du das > Verfahren fest? ja sry. zu a) also es ist ein stm32f10x und ich möchte eben die Kommunikation zwischen dem Controller und dem PC über eine CRC 32 absichern. der Controller besitzt ein internes Modul welche eine CRC berechnen und auf die gleiche weise muss ich am PC nun auch die CRC berechnen, damit ich es vergleichen kann. und wie der Controller das genau macht weis ich nicht. zu b) wie meinst du das mit Vorgaben? ich möchte halt am ende ein array von bytes übertragen und zum schluss die CRC
crcler schrieb: > ich möchte eben die Kommunikation zwischen dem Controller und dem PC > über eine CRC 32 absichern. > ich möchte halt ein array von bytes übertragen > es ist ein stm32f10x Warum muss man denn alles erst mühsam erfragen? Dann bist du im Verfahren nicht festgelegt und kannst nehmen, was du möchtest. Erste Empfehlung: Nimm ein eingeführtes Verfahren, dann tappst du nicht in Designfallen. Zweite Empfehlung: Such das Verfahren nach den Anforderungen deiner Übertragung aus, nicht nach dem, was zufällig im Controller eingebaut ist. Deswegen: - Wie groß ist ein Datentelegramm? - Wie störanfällig ist die Stecke? (Bzw.: Worüber überträgst du?) Danach solltest du das verwendete CRC-Verfahren aussuchen. Falls du überhaupt eins brauchst. Solltest du nur über USB auf einen virtuellen COM-Port gehen wollen, brauchst du eigentlich keinen CRC. (USB hat bereits eine Sicherung über CRC.) Falls du aber trotzdem einen CRC implementieren willst, würde ich dir fast raten wollen, die CRC-Unit zu vergessen und es auf beiden Seiten rein in Software zu machen. Codebeispiele gibt es genug und Rechenleistung dürftest du auf beiden Seiten mehr als ausreichend haben. Du kannst natürlich auch die eingebaute CRC-Unit verwenden. Dann musst du aber das Datenblatt und das Reference Manual sehr genau lesen, um die CRC-Unit passend zu konfigurieren. Grüße Stefan PS: Einzige Ausnahme: Du musst die Daten in einem derartigen Tempo "raushauen", dass das Berechnen "zu Fuß" nicht mehr möglich ist. Nach deiner Beschreibung scheint das aber nicht der Fall zu sein.
vielen dank für die antwort. die crc möchte ich verwenden da es sehr wichtig ist das die bytes korrekt übertragen werden. die telegramlänge ist bis zu 255 bytest. die kommunikation kann über verschiedene wege stattfinden, z.b. usb, rs485, rs232, ethernet,... desweiteren kann die störbeeinflussung der umgebung sich verändern.
Ok, da kannst du vom CRC-16 über den CCITT-CRC bis zum CRC-32 eigentlich alles verwenden. Du kennst http://www.mikrocontroller.net/articles/CRC und http://www.mikrocontroller.net/forum/codesammlung?filter=crc* ? Da du ursprünglich einen 32er haben wolltest, ist wohl das hier was für dich: Beitrag "Yet another CRC32 Code" Grüße Stefan
Stefan Wagner schrieb: > Ok, > > da kannst du vom CRC-16 über den CCITT-CRC bis zum CRC-32 eigentlich > alles verwenden. > > Du kennst http://www.mikrocontroller.net/articles/CRC und > http://www.mikrocontroller.net/forum/codesammlung?... ? > > Da du ursprünglich einen 32er haben wolltest, ist wohl das hier was für > dich: Beitrag "Yet another CRC32 Code" > > Grüße > > Stefan danke Stefan für deine Große mithilfe. ich hab jetzt mal im Mikrocontroller eine eigene CRC berechnung erstellt und mit dieser klappt alles. DANKE Dennoch würde mich gerne interesieren was die interne CRC berechnung des stm32 anderst macht.
crcler schrieb: > Dennoch würde mich gerne interesieren was die interne CRC berechnung des > stm32 anderst macht. Das müsstest du alles im Reference Manual finden können. Das Kapitel über den CRC-Generator ist recht umfangreich. Richte dich aber auf ein paar Stunden konzentrierter Lektüre ein... Grüße Stefan
Stefan Wagner schrieb: > Das müsstest du alles im Reference Manual finden können. Das Kapitel > über den CRC-Generator ist recht umfangreich. > > Richte dich aber auf ein paar Stunden konzentrierter Lektüre ein... umfangreich? da sind doch nur 3 Seiten. Seite 62-64
Reference Manual: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/CD00171190.pdf
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.