Gast
#5249612
Guten Morgen, von einem PC werden Daten via UDP an einen Mikrocontroller versendet. Zusätzlich soll einen CRC Prüfung beim Empfänger eingebaut werden. Wie müsste ich da vorgehen?
LEON schrieb: > Wie müsste ich da vorgehen? CRC berechnen
Naja. Den CRC an die Meldung anhaengen und pruefen. Wo liegt das Problem ? Der CRC sollte Teil des Protokolle sein. Falls der CRC nicht stimmt, gibt der Empfaenger keine Antwort, das Packet ist verschwunden und wird nochmals gesendet. eigentlich enthaelt eine UDP Meldung schon einen CRC... implizit im Ethernet frame
Gast
#5249652
Beispiel: Sender: TxBuffer[100]: Daten[96] + CRC[4] Empfänger: RxPuffer[100]: Daten[96] + CRC[4]
Gast
#5249653
Welche CRC Berechnung bzw. Polynom sollte man dafür einsetzen?
Gast
#5249655
LEON schrieb: > Welche CRC Berechnung bzw. Polynom sollte man dafür einsetzen? Idealerweise hat der µC ein CRC Modul und dann schaut man, welche Polynome dies unterstützt. Ansonsten hilft dir google zu CRC Polynomen und deren Fähigkeiten Bitfehler zu entdecken.
Gast
#5249660
LEON schrieb: > CRC[4] Da Du wohl schon 32bit für die CRC vorgeschlagen hast, probier doch mal die CRC32.. Da wir den verwendeten µC nicht kennen, können wir auch nicht empfehlen welcher Algorithmus besonders geeignet wäre..
Gast
#5249662
XMC4700
Siehe CRC.
Gast
#5249667
Was soll das bringen wenn man die CRC auch mit sendet?
Wichtig ist auf beiden Seiten denselben Code zu verwenden. Per Copy paste. Das Polynom alleine reicht leider nicht. Wir hatten schon zu viele Implementation, die nicht gepasst haben, weil die Annahme war - passt schon. Ein CRC16 kann 2^16 bit = 8kByte schuetzen, ein CRC32, 2^32bit = 256MByte. Ich wuerd's beim CRC16 belassen und den falls noetig als Tabelle implementieren falls die Zeit knapp ist. Sonst als Bitschieber.
Gast
#5249672
LEON schrieb: > Was soll das bringen wenn man die CRC auch mit sendet? Lies dir erstmal das durch: https://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung https://www.mikrocontroller.net/articles/CRC Dann solltest du das wissen, warum es mitgeschickt wird.
Gast
#5249675
Ok vielen Dank. Wie läuft das beim Empfänger ab? Muss über die ankommenden Daten (Daten[96]) eine CRC gebildet werden? Was passiert mit den vier weiteren Bytes in denen die CRC vom Sender enthalten ist?
LEON schrieb: > Was soll das bringen wenn man die CRC auch mit sendet? Wie soll der Empfänger denn sonst wissen, ob der von ihm berecnete CRC mit dem übereinstimmt, den der Sender berechnet hat? <rolleyes>
Gast
#5249678
LEON schrieb: > Wie läuft das beim Empfänger ab? Muss über die ankommenden Daten > (Daten[96]) eine CRC gebildet werden? Was passiert mit den vier weiteren > Bytes in denen die CRC vom Sender enthalten ist? Wie gesagt, beide Artikel lesen.
Gast
#5249689
Es kann ja auch sein das beim Versenden die 4 Bytes für die CRC fehlerhaft sind.
Gast
#5249692
LEON schrieb: > Es kann ja auch sein das beim Versenden die 4 Bytes für die CRC > fehlerhaft sind. Ja sicher, das wird aber auch mit einer hohen Wahrscheinlichkeit detektiert.
Gast
#5249695
Auch über die ankommende CRC soll dann eine CRC gebildet werden?
Gast
#5249700
LEON schrieb: > Es kann ja auch sein das beim Versenden die 4 Bytes für die CRC > fehlerhaft sind. Macht nichts. Am Empfänger wird der CRC über die Nachricht einschliesslich des angehängten CRC gebildet. Dabei sollte 0 rauskommen.
Gast
#5249701
Oder soll nur über die 96 Bytes (Daten) die CRC gebildet werden und mit der empfangenen CRC verglichen werden?
Gast
#5249709
>>Am Empfänger wird der CRC über die Nachricht einschliesslich des >>angehängten CRC gebildet. Dabei sollte 0 rauskommen. Ok dann werde ich das ganze mal implementieren.
Gast
#5249730
LEON schrieb: > Oder soll nur über die 96 Bytes (Daten) die CRC gebildet werden und mit > der empfangenen CRC verglichen werden? Natürlich! Was hätte es sonst für einen Sinn, CRC zu senden? Am Besten so: nachtmix schrieb: > Am Empfänger wird der CRC über die Nachricht einschliesslich des > angehängten CRC gebildet. Dabei sollte 0 rauskommen. LEON schrieb: > Es kann ja auch sein das beim Versenden die 4 Bytes für die CRC > fehlerhaft sind. Ja, das wäre dann halt insofern Pech, dass trotz eigentlich richtigem Datenempfang wiederholt werden muss - false positive. Dagegen kannst du dich letztlich nicht schützen und musst es auch nicht. Ein erfolgreiches Ergebnis sagt dir nur, dass mit sehr hoher Wahrscheinlichkeit kein Fehler erfolgt ist. Denn theoretisch gäbe es auch den Fall, dass sowohl Daten als auch CRC so gefälscht werden, dass die CRC-Prüfung trotzdem noch passt. Diese Wahrscheinlichkeit lässt sich minimieren, wenn das Verhältnis der Längen von den Nutzdaten zu den CRC-Daten kleiner wird. Null wird sie trotzdem nicht, dafür die Wahrscheinlichkeit der false positiv größer. Wie sagt man so schön: einen Tod musst du leiden ...
Gast
#5249740
HildeK schrieb: > Wie sagt man so schön: einen Tod musst du leiden ... Z.B. den Tod die vorgeschlagenen Artikel zu lesen statt 13x zu fragen.
Gast
#5249766
Wieso überhaupt CRC implementieren? Das sollte eigentlich im OSI Layer 2 automatisch gemacht werden. Da wird ein Paket auch direkt verworfen, wenn die CRC nicht stimmt. Welchen Stack nutzt du denn? Oder haste was eigenes entwickelt?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.