Prüfsummenverfahren gesucht.

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.

Nimm einfach die

1

#include <util/crc16.h>

>  #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...

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.