Hallo zusammen, ich benutze oft Atmega und Dspic microcontroller in meinen Projekten. Und beim programmieren lass ich das Programier-gerät auch immer überprüfen ob das gerade programmierte ok ist. Meine Frage ist jetzt wie macht er dans genau? Checksumme? Könnte man diese Checksumme (wenn es nun eine ist) benuzten um zu überprüfen welche software version sich auf dem chip befindet? Danke, Tytus
Tytus W. schrieb: > Hallo zusammen, > > ich benutze oft Atmega und Dspic microcontroller in meinen Projekten. > Und beim programmieren lass ich das Programier-gerät auch immer > überprüfen ob das gerade programmierte ok ist. > > Meine Frage ist jetzt wie macht er dans genau? Checksumme? reinbrennen auslesen und vergleichen ob das Gelesene mit dem übereinstimmt was gebrannt hätte werden sollen
Das heisst die softwares die programmieren merken sich nicht irgentwo mit einer checksumme oder was anderes was gerade prgrammiert wurde? Ich frage um zu wissen ob es eine einfachere Methode gibt als das ganze programm auszulesen und zu verglaichen?
Wenn C, schreib per DATE_ und _TIME die CompileTime an definierter Stelle in Flash oder Eprom. Kann man auch per Macro zu einer Prüfsumme zerlegen. Stefan
Tytus W. schrieb: > Das heisst die softwares die programmieren merken sich nicht irgentwo > mit einer checksumme oder was anderes was gerade prgrammiert wurde? Nein. Der Programmer vergleicht alle einzelnen Bytes. Es steht Dir aber frei, eine Versionsinformation als Konstante in den Code aufzunehmen. PS: Checksummen taugen nicht als Versionsinformation, weil verschiedene Programme die gleiche Checksumme haben können.
Bronco schrieb: > PS: Checksummen taugen nicht als Versionsinformation, weil verschiedene > Programme die gleiche Checksumme haben können. Aber auch nur, wenn man eine vollkommen ungeeignete Methode zur Berechnung der Checksumme verwendet. Nimmt man eine aktuelle Hashfunktion, dann sollte das kein Problem sein.
Tytus W. schrieb: > Ich frage um zu wissen ob es eine einfachere Methode gibt als das ganze > programm auszulesen und zu verglaichen? Das kann nicht funktionieren, weil verschiedene Programme die gleiche Checksumme ergeben können. Presst man x Bits, egal nach welchem Verfahren, in y Bits rein (y kleiner als x), dann muss irgendeine Information auf der Strecke bleiben. Ansonsten wäre eine Checksumme nämlich ein idealer Kompremieralgorithmus :-) Ein 8KB langes Programm in lediglich 2 oder 4 Bytes abbilden und trotzdem eindeutig daraus wieder rekonsturieren können. D.h. Die Abbildung Programm->CHecksumme ist nicht eindeutig. Sind die Checksummen unterschiedlich, dann sind auch die Programme unterschiedlich. Sind die Checksummen aber gleich, bedeutet das noch nicht, dass auch die Programme gleich sind. Wenn du ein Programm aber in einen µC brennst, dann reicht dir das nicht. Du willst die Gewissheit, das tatsächlich jedes einzelne Bit genau so im µC gelandet ist, wie vorgegeben. Eine Checksumme kann diesen 100% Test auf Gleichheit aber nicht leisten.
Die Versionsnummer des Programms sowie das Datum der Programmerstellung speichere ich als Konstante (egal ob mit Assembler oder C) gerne am Speicherende ab (wenn möglich). Denke aber daran, wenn Du das Auslesen über den Programmer oder die Programmierschnittstelle sperrst kannst Du, außer über dein Programm selber, nicht auf die Versionsnummer zugreifen. Die Checksumme als Versionsnummerersatz funktioniert nicht. Der Programmer selber vergleicht ganz einfach den Rückgelesenen! Speicherinhalt Byte für Byte mit dem Soll-Inhalt vom HEX-File. Und setzt anschließend ggf. die Auslese-Sperr-Bits.
Natürlich funktioniert eine Checksumme als Versionsnummernersatz. Dass man dabei kein CRC16 o.ä. verwenden kann, dürfte nach obigen Einwänden einleuchten. Bei 16 Bit ist die Kollisionswahrscheinlichkeit zu hoch. Nimmt man aber eine längere Checksumme (das altehrwürdige und kryptographisch nicht mehr empfehlenswerte, aber weit verbreitete MD5 ist für diesen Zweck immer noch gut geeignet), dann ist die Kollisionswahrscheinlichkeit kleiner als die Wahrscheinlichkeit, dass beim Byte-für-Byte-Vergleich ein Übertragungsfehler auftritt. MD5 ist dabei nur ein Beispiel. Klassische Fehlererkennungs-Prüfsummen (CRC, Adler) sind für diesen Zweck jedoch meistens schlechter geeignet als andere. An geeigneten kollisionsresistenten Hashes mangelt es jedenfalls nicht. Die Länge des Hashes ist auch ein wichtiger Faktor. Ob es hilft, eine 16- oder 32-Zeichen-Hexadezimalzahl als Versionsnummer zu haben, muss dann der Anwendungszweck zeigen. Für Endanwender ist sowas ungeeignet, für automatische Verarbeitung oder unter Entwicklern ist das völlig OK.
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.