Forum: Mikrocontroller und Digitale Elektronik Prüfsumme wie ?


von Tobias (Gast)


Lesenswert?

Ich habe 2x 32 BIT Konstanten welche im EEPROM abgelegt werden sollen. 
Zur Sicherheit möchte ich eine Checksumme bilden damit ich beim auslesen 
der Konstanten sicherstellen kann, dass diese noch Korrekt sind.

Im Moment bilde ich eine einfache Summe dieser beiden Konstanten und 
begrenze diese mit 8 BIT:

CheckSum = ((uint8_t) (Konstante1 + Konstante2));

beim zurücklesen dann:

if (CheckSum == (uint8_t) (Konstante1 + Konstante2)) CheckSum ok

Das Ganze funktioniert auch aber ich denke Checksummen bildet man 
anders!?!? habe aber leider keine Ahnung wie man es richtig macht.

Ich hoffe es braucht keinen komplizierten Algorithmus um so eine 
einfache Checksumme zu bilden ?

Unter der Annahme das ich es auch so belassen könnte, welche Risiken 
sind hierbei zu beachten ? wie sicher ist meine Prüfsumme ?

von Lehrmann M. (ubimbo)


Lesenswert?

Eine Prüfsumme kann alles sein - je nach Anforderungen ...

http://de.wikipedia.org/wiki/Pr%C3%BCfsumme

das entscheidest du schon selbst was du implementierst. Wenn du's 
komplex haben willst hashen oder CRC ...

Was du hast ist eine etwas komische Sache - die Umwandlung in einen 8 
Bit unsigned integer würde mir nicht gefallen ... aber das wird 
persönlicher Geschmack sein ...

von lalala (Gast)


Lesenswert?

so wie du das machst ist es falsch, da die oberen Bits (9 bis 32) 
unberücksichtigt sind. Du kannst eine einfache Summe von Bytes machen. 
Also die 2 DWORD Konstanten in je 4 Bytes aufteilen und dann die 8 Bytes 
zusammenaddieren. Das sollte dann für deine Zwecke ausreichen.

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

Alle 8bit-Blöcke (Bytes) mittels XOR verknüpfen.

von Huch (Gast)


Lesenswert?

Die Überlegungen, wie sicher so eine Checksumme ist, sind nicht trivial.

Ganz allgemein kann es, wenn Du aus n Bits eine k-Bit Checksumme 
bildest, wobei k <= n, 2^(n-k) Kombinationen der Originaldaten geben die 
eine Checksumme haben die identisch ist mit einer der sonstigen 2^k 
Kombinationen der Originaldaten.
Wie oft so ein Duplikat jeweils auftritt hängt von dem konkreten 
Algorithmus ab. Aber das Duplikate auftreten lässt sich prinzipiell 
nicht vermeiden.

In dem Wikipedia-Artikel zur CRC gibt es, glaube ich, auch dazu 
Überlegungen die aber wiegesagt, nicht ganz einfach nachzuvollziehen 
sind.

Bei nur 64 Bit Originaldaten wäre es aber vielleicht noch möglich 
einfach eine 64 Bit Checksumme zu bilden, weil das ja nicht viel 
zusätzlichen Speicher belegt. Mit dem passenden Algorithmus wäre das 
auch absolut sicher.

von Huch (Gast)


Lesenswert?

Eine wesentliche Rolle spielt dabei auch die Frage welche Originaldaten 
überhaupt auftreten können. Evtl. sind ja nicht alle 2^64 Kombinationen 
möglich. Das könnte man bei der Auswahl des Algorithmus für die 
Checksumme berücksichtigen.

von Micha H. (mlh) Benutzerseite


Lesenswert?

Ich habe in einem einfachen Anwendungsfall 32 Bytes abzspeichern und 
benutze dazu die 8-bit Prüfsumme, d.h. alle Daten werden in einer 8 Bit 
breiten Variable aufsummiert. Jeder Überlauf wird damit verworfen.
Eine weiterführende Frage ist natürlich, was passiert wenn ein Fehler 
erkannt wird (das geschieht hier durchaus gelegentlich)? Ich speichere 
dazu einen zweiten Satz der gleichen Daten mit ebensolcher Prüfsumme ab. 
Das hat bisher recht gut funktioniert, alle wieder eingelesenen Daten 
waren plausibel (was nicht notwendigerweise bedeutet daß sie auch immer 
richtig waren).
Solch ein einfaches Verfahren genügt für Daten, die nicht lebenswichtig 
sind und funktioniert trotzdem recht gut.
Für "lebenswichtige" Daten muß die Redundanz und der Aufwand natürlich 
wesentlich erhöht werden, siehe z.B. Hamming-Code.

von Tobias (Gast)


Lesenswert?

Vielen Dank für die zahlreichen Erklärungen.

Bitte 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
Noch kein Account? Hier anmelden.