mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 4-Byte lange Checksumme bei Programmiergerät


Autor: Ralf Altmann (warpnine)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe bei einigen Programmiergeräten bzw. deren Software gesehen,
dass zu jedem geladenen HEX-File eine 4-Byte Checksumme angegeben
wird.

Wie genau wird die denn berechnet? Eine CRC-Berechnung kann es wohl
kaum sein, oder?
Wohl eher einfach die Daten von 0 ausgehend immer abgezogen, oder?

Ralf

Autor: Roland Praml (pram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kommt auf das Programm drauf an. Eine Möglichkeit wäre z.B. CRC32
http://en.wikipedia.org/wiki/CRC32
Gruß
Roland

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralf:

Dann schau doch mal in der Bedienungsanleitung nach.

Ansonsten, ist Checksumme immer noch besser als nichts, oder?

Mein Programmiergerät aus alten Zeiten, als der Speicher noch kleiner
war, erzeugt eine Checksumme aus 3 Byte für 64 kB. Die habe ich dann in
die obersten 3 Byte des Codespeichers übertragen, beim Programmstart die
Checksumme summiert, und damit verglichen. Das ist schon ganz in
Ordnung.

Einen Fehler bei einem gekippten Bit erkennt man damit allemal. Bei 2
gekippten Bits in 2 Bytes, entgegengesetzt an irgend einer gleichen
Wertigkeitsstelle, ist die Checksumme schon nicht mehr sicher, da das
Ergebnis stimmen kann. Da ist die Redundanz nicht besser als bei der
Parity-Prüfung für ein einzelnes Byte. Bei gekippten Bits in
unterschiedlichen Stellen wird die Erkennung wieder besser.

Hier müßte man tiefer in Mathematik und Statistik einsteigen.

Gegen CRC ist nichts einzuwenden, aber das Programmiergerät bildet
diese eben nicht. Die Berechnung mußt du dann selbst durchführen, und
zwar mit einem auf dem PC laufenden Programm aus dem Hexfile oder
besser Binärfile, dann im Speicher der Anwendung ablegen. In der
Anwendung muß die CRC-Berechnung nochmals auf gleiche Art durchgeführt
und das Ergebnis mit dem abgelegten Wert verglichen werden.

Manche Anwendungen bilden auch Modulo(x) aus (y) Bytes in definierten
Blockgrößen, also der Vielfalt der Fehlererkennung sind wirklich keine
Grenzen gesetzt.

Aufwändige Codes führen sogar Korrekturen von 1, 2, 3 oder mehr Bits in
einem kleinen Block von vielleicht 32 Bit durch, aber das ist bei einem
Codespeicher vom Typ EPROM, EEPROM oder Flash kaum vernünftig zu
handhaben, bei RAM hingegen schon. Das hat aber wiederum nichts mit CRC
zu tun.

Teurere PC (IBM, etc.) hatten mal eine 9. RAM-Bank je 8 Bit
Datenbreite, nur um die Parity zu überwachen. Das machte wohl der
BIOS-Controller, aber Details kenne ich da nicht.

Gruß

Dietmar

Autor: Profi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dietmar:
Habe auch mal ein Memory-Board gesehen, das hatte 13 Bits pro Byte.
Nannte sich EDAC (Error Detection And Correction). Das konnte
on-the-fly einen Soft- und einen Hard-Error erkennen und korrigieren.

Von Intel habe ich die Dok eines solchen Memory-Controllers gelesen,
die Theorie ist nicht gerade einfach zu verstehen, mit Syndrome-Bits
etc.

@Ralf:
CheckSum bedeutet urspünglich Summe, also werden die Bytes einfach
addiert.
Habe auch andere Verfahren gesehen, z.B. XOR und CRC in verschiedenen
Breiten und mit verschiedenen Startwerten.

Am besten, Du veränderst in einer Datei nur ein Bit und schaust, wie
sich die Checksum ändert. Falls komplett anders, ist es CRC o.ä.

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Profi:

13 bit pro Byte, ist schon eine fette Sache. Irgendwo in meinem alten
Digitaltechnik-2-Skript hab ich über Korrektur-Codes nähere Info.
Nachdem ich von diesen Dingen weiß, habe ich auch nichts mehr gegen
richtig teure PC einzuwenden. Datenkorrektur on the fly, das hat
durchaus seine Berechtigung.

Gegenwärtig entwickle ich CAN-Bus-Anwendungen, auch
Software-Fern-Update über CAN-Bus. Da überlege ich zur Zeit noch, ob
ich überhaupt einen CRC-Code per Software implementieren muß. Von Haus
aus hat der CAN Frame eine HD = 6 (Hamming-Distanz (Hamming, Wikipedia
nachschauen), ein Maß für Redundanz), in den CAN-Bus-Spezifikationen
ist die Rede von einem einzelnen Datenfehler in mehr als 10 hoch 11
Frames (100 Milliarden). Das bezieht sich wohl auf die
Hardware-CRC-Bildung, die in den CAN-Spezifikationen ebenfalls
beschrieben ist.

Welche HD (Hamming-Distanz) hat eigentlich die Checksumme, wenn man das
überhaupt so ausdrücken darf? Nun, in einer Software, Binär-File, kommen
doch alle Bitkombinationen vor.

Hat da jemand noch weitere Info?

Gruß

Dietmar

Autor: Jasmin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das wird wohl das alt bekannte intel-hex Format sein.

Schau mal hier http://www.mikrocontroller.net/forum/read-2-16608.html
d.s.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

danke für die Antworten.

Es geht mir nicht um einen bestimmten Programmer, ich bastle gerade
selber an einem, und daher wollte ich es wissen, wie genau es gemacht
wird bzw. gemacht werden kann.

Ralf

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jasmin:

"das alt bekannte intel-hex Format" bildet am Ende einer Zeile nur
das 2-er Komplement aus den Nutzbytes einer Zeile in einem Byte, also
keine 3 oder 4 Bytes.

Gruß

Dietmar

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.