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?
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
Beispiel: Sender: TxBuffer[100]: Daten[96] + CRC[4] Empfänger: RxPuffer[100]: Daten[96] + CRC[4]
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.
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..
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.
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.
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>
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.
Es kann ja auch sein das beim Versenden die 4 Bytes für die CRC fehlerhaft sind.
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.
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.
Oder soll nur über die 96 Bytes (Daten) die CRC gebildet werden und mit der empfangenen CRC verglichen werden?
>>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.
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 ...
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.
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?
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.