Eine Datenübertrag (115200 Bit/s) zwischen 2 ATMega88 (Takt 3,6 Mhz) soll gesichert werden. Die Datensatzlänge beträgt zwischen 12 und 600 Bytes. Welches Prüfsummenfahren ist geeignet? CCR32/64 ist ziemlich sicher, aber bei Anwendungen mit größeren Datensatzlängen wohl nicht üblich. Zudem vermute ich, dass der Zeitaufwand zur Berechnung recht hoch ist für einen kleinen Mikrocontroller. Wer hat Erfahrung mit der Prüfsumme größer Datenmenge und kann mir zu einem Prüfsummenverfahren raten?
Ein CRC-16 sollte genuegen. Der ist gut fuer 2^16 bits was 8kBytes sind. Der kann auch noch relativ einfach gerechnet werden, entweder mit schieben-xor, oder Tabelle
Markus schrieb: > Zudem vermute ich, dass der > Zeitaufwand zur Berechnung recht hoch ist für einen kleinen > Mikrocontroller. CRC-Berechnungen arbeiten nicht zwingend bitweise, sondern können auch byteweise arbeiten. Auf Tabellen basierend. Das sollte schnell genug sein.
Die Prüfsumme nach Fletcher (https://en.wikipedia.org/wiki/Fletcher_checksum#Fletcher-16) besitzt die gleichen Eigenschaften zur Erkennung von Übertragungsfehlern wie die zyklische Redundanzprüfung, benötigt aber einen wesentlich geringeren Rechenaufwand. Es handelt sich um eine positionsabhängige Prüfsumme, d.h. im Gegensatz zu „einfachen Prüfsummenverfahren“, werden Änderungen in der Reihenfolge der übermittelten Daten erkannt.
Vielen Dank für eure Antworten. Peter Dannegger schrieb: > Nimm einfach die >
1 | > #include <util/crc16.h> |
2 | >
|
:)
> #include <util/crc16.h>
fuer die Anspruchslosen...
Ein Schiebe-XOR Ansatz mit einem CRC-16 benoetigt etwas ueber 80 befehle
pro byte. Ohne genau zu zaehlen. Bei 3.6MHz und 115kBit haben wir 360
Befehle pro byte. Der Rest bleibt fuer was Anderes. Nicht grad der
Hammer.
Der Tabellenbasierte Ansatz ist kuerzer. Dabei gibt es zwei
Moeglichkeiten. Ich glaub mich zu erinnern. Die lange Tabelle benoetigt
256 Worte und rechnet mit byte aufs Mal, die kurze Tabelle benoetigt 32
oder 64 worte und rechnet mit Nibble aufs Mal...
Siebzehn oder Fuenfzehn schrieb: > fuer die Anspruchslosen... ich glaube die lib ist schon für die Atmels optimiert und verwendet Tabelle + Xor.
Marco M. schrieb: > Es handelt sich um eine positionsabhängige Prüfsumme, > d.h. im Gegensatz zu „einfachen Prüfsummenverfahren“, werden Änderungen > in der Reihenfolge der übermittelten Daten erkannt. Hm also unter deinem Link steht was anderes. https://en.wikipedia.org/wiki/Fletcher_checksum#Weaknesses_of_simple_checksums >The first weakness of the simple checksum is that it is insensitive to the >order of the blocks (bytes) in the data word (message). If the order is >changed, the checksum value will be the same and the change will not be >detected.
> werden Änderungen in der Reihenfolge der übermittelten Daten erkannt.
Eine Pruefsumme in dieser Anwendung ist gegen Einzelbitfehler
hervorgerufen durch Spikes auf der Uebertragungsstrecke gedacht, und
nicht gegen Bytevertauschen. Bytevertauschen kommt auf einer
Uebertragungsstrecke statistisch gesehen eher selten vor...
Siebzehn oder Fuenfzehn schrieb: > Ein Schiebe-XOR Ansatz mit einem CRC-16 benoetigt etwas ueber 80 befehle > pro byte. Ohne genau zu zaehlen. Bei 3.6MHz und 115kBit haben wir 360 > Befehle pro byte. Der Rest bleibt fuer was Anderes. Nicht grad der > Hammer. Ein Blick in die <util/crc16.h> verrät, _crc_ccitt_update() braucht 17 Zyklen. Allerdings ist der Baudratenfehler bei 3,6MHz schon 2,4%. Diee AVRs unterhalten sich daher mit 112,5kBaud und nicht mit 115,2kBaud. Mitlauschen mit dem PC ist dann unzuverlässig.
Peter Dannegger schrieb: > Allerdings ist der Baudratenfehler bei 3,6MHz schon 2,4%. > Diee AVRs unterhalten sich daher mit 112,5kBaud und nicht mit > 115,2kBaud. > Mitlauschen mit dem PC ist dann unzuverlässig. Es sind exakt 3,686400 MHz.
Hallo, wenn du byteweise Parity verwenden kannst (8bit + P) und dazu eine 16bit Prüfsumme, reicht das völlig aus, und die Rechenzeit ist nahezu unmessbar. Das mit der Reihenfolge ist irrelevant, weder bei Speichern wie Floppy oder Festplatte noch bei serieller Übertragung gibt es einen plausiblen Mechanismus, der die Reihenfolge vertauschen könnte. Interessanter ist die Frage nach Mehrfachfehlern, aber i.d.R. sind die Verbindungen nicht so schlecht dass das eine Rolle spielen würde. Gruss Reinhard
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.