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
Das kommt auf das Programm drauf an. Eine Möglichkeit wäre z.B. CRC32 http://en.wikipedia.org/wiki/CRC32 Gruß Roland
@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
@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.ä.
@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
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.
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
@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
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.