Hi Leute, ich suche ich eine Software mit der ich die HEX Files vom Mikrocontroller ändern kann und die Checksumme automatisch berechnet wird. Mir geht es darum, Kalibrationsdaten die via Linker-File auf bestimmten Sektoren des uC's abgelegt werden, direkt im HEX File zu ändern. Dabi soll di Checksumme automatisch neu berechnet werden... Kenn Ihr solche Tools? Alles was ich finde, sind eher die HEX Editoren für binäre Dateien.
Im Zweifelsfall: Mit objcopy nach bin konvertieren, mit Hex-Editor bearbeiten und zurück-konvertieren. Klappt aber nicht gut wenn man Lücken im Adressraum hat.
Python hat eine m.M.n. sehr mächtige Lib ("IntelHex") für das Öffnen,
Bearbeiten und Abspeichern von Intel-Hex.
Ein Skript was dir ein paar Bytes ändert, anschließend eine Checksumme
über einen bestimmten Speicherbereich errechnet und diese dann noch
ablegt sollte in wenigen Zeilen machbar sein.
Wir benutzen das hier für einen genau solchen Postbuild-Hook.
Ob es sowas von der Stange für genau deinen Fall gibt würd ich
bezweifeln.
Le X. schrieb: > Python hat eine m.M.n. sehr mächtige Lib ("IntelHex") für das Öffnen, > Bearbeiten und Abspeichern von Intel-Hex. > > Ein Skript was dir ein paar Bytes ändert, anschließend eine Checksumme > über einen bestimmten Speicherbereich errechnet und diese dann noch > ablegt sollte in wenigen Zeilen machbar sein. > Wir benutzen das hier für einen genau solchen Postbuild-Hook. > > > Ob es sowas von der Stange für genau deinen Fall gibt würd ich > bezweifeln. Python kann ich nicht, ein Script was sowas machen könnte, würde ich in C# hinbekommen, mir geht es aber darum, ob solche Tools existieren? Es soll auch für Kollegen machbar sein, eine HEX Datei bearbeiten zu können, mit der der uC beschrieben wird.
Gast
#5971192
A. F. schrieb: > Kenn Ihr solche Tools? Bei meinen Programmern ist Software dabei, die Hexdateien auch wieder ausgibt. Ich fürchte nur dass die ohne den Programmer nicht läuft, obwohl das ja nur im Speicher stattfindet. Georg
Gast
#5971194
Jeder Programmer kann das umwandeln. Man braucht nicht mal den Programmer selbst dazu. Problem wird sein, wie deine Prüfsumme berechnet wird. Da gibt es viele Möglichkeiten.
bisher gebe ich die einzelnen Zeilen immer in einen Online Rechner ein. Würde auch gerne ne Lösung für den Notepad++ Editor haben, der markiert bei einer Änderung zwar die falsche Checksumme farblich, eine Korrekturfunktion gibts aber anscheinend nicht.
Ich mach das jetzt in C#, habe jetzt auf die Schnelle schon was zusammengebastelt. Muss die Anzeige nur bisschen ordentlicher gestallten. Vielleicht baue ich noch gleich die command line programmierung des STM32 mit ein. Mein highlighter trödelt leider ein wenig. Ein 80kB STM32 File, wird 4 Sekunden lang eingelesen...
Angehängte Dateien:
-
hexedit.png
(100 KB)
Ich stand vor 2-3 Jahren auch vor einer ähnlichen Problematik(Signatur über den Applikationbereich hinzufügen, CRC Prüfsummen für einen Flashheader berechnen) und wollte das Rad nicht neu erfinden. Dabei fand ich folgendes Tool welches extrem mächtig ist. srecord.sourceforge.net Kann neben Konvertieren in diverse Formate auch Heraustrennen/ Auffüllen und div. Prüfsummen rechnen. Habe für meine Zwecke mit diversen Zwischendateien gearbeitet und hinterher alles wieder zu einer Datei zusammen gebaut. Also auf jeden Fall einen Blick wert.
A. F. schrieb: > Ich mach das jetzt in C#, habe jetzt auf die Schnelle schon was > zusammengebastelt. Ach, jetzt verstehe ich. Es ging dir gar nicht darum eine Checksumme über einen bestimmten Speicherbereich zu berechnen sondern dir geht es um die im Intel-Hex-Format spezifizierte Prüfsumme am Ende jeder Zeile?
Gast
#5971624
Früher war das ein verbreitetes Problem, dafür gibt es Uralt-Software: http://www.keil.com/download/docs/113.asp Georg
Gast
#5971683
Georg schrieb: > Früher war das ein verbreitetes Problem, dafür gibt es Uralt-Software: > > http://www.keil.com/download/docs/113.asp > > Georg Er will das File nicht konvertieren sondern editieren! Und auch für alte Probleme gibt es u.U. aktuelle Software, in dem Fall z.B. SRecord.
A. F. schrieb: > Python kann ich nicht, ein Script was sowas machen könnte, würde ich in > C# hinbekommen, mir geht es aber darum, ob solche Tools existieren? > Es soll auch für Kollegen machbar sein, eine HEX Datei bearbeiten zu > können, mit der der uC beschrieben wird. Das kapier ich nicht, Du schreibst daß Du das problemlos programmieren kannst, dann mach es doch. Die Kollegen benutzen dann Dein Programm um die Kalibrierwerte einzugeben und dann klicken sie auf den "Flash"-Button und dann geht alles automatisch. Wenn Du programmieren kannst dann kannst Du das so idiotensicher machen daß es ein trainierter Schimpanse bedienen kann. Wo ist das Problem?
Gast
#5971718
Dann wäre da noch SRecord Links: http://srecord.sourceforge.net/
Gast
#5971842
guest schrieb: > Er will das File nicht konvertieren sondern editieren! Editieren kann man das mit unzähligen Programmen, sein Problem ist die editierten Daten mit den richtigen Prüfsummen wieder auszugeben. Georg
Gast
#5972103
Mit HEXED kann man das komfortabel machen. Da gibt es auch eine Prüfsumme. Aber ob es die Methode des TO ist???
Gast
#5972117
Hmm, bei Autosar-Code funktioniert CDM-Studio nicht schlecht duckundweg
Gast
#5972316
Was fuer ein Quatsch ist das nun ? Heutzutage kann der Prozessor selbst unter Programmkontrolle ins Flasch oder ins EEPROM schreiben. Also ich mach das zB so, um Konfigurationswerte zu speichern...
Hallo! Für das editieren von INTEL-HEX-Dateien ist das Programm HxD sehr gut geeignet. Es berechnet selbstverständlich nach jeder Änderung die Zeilen- und Gesamtprüfsumme neu. https://mh-nexus.de/de/hxd/
Gast
#5972411
Die Galep Software kann das.
Gast
#5972440
Srecord funktioniert allenfalls unter Linux. Die Autoren sind in recht pubertärem Humor auch noch stolz drauf, daß sie es geschafft haben, ein solch vergleichsweise simples Tool nicht-portabel hinzukriegen. Unter Cygwin läßt es sich auch nicht bauen. Ich hab mir dann lieber für meinen use case ein Hextool selber geschrieben, was schneller ging, als mich mit Srecord herumzuplagen.
Nop schrieb: > Srecord funktioniert allenfalls unter Linux. Die Autoren sind in recht > pubertärem Humor auch noch stolz drauf, daß sie es geschafft haben, ein > solch vergleichsweise simples Tool nicht-portabel hinzukriegen. Unter > Cygwin läßt es sich auch nicht bauen. Was laberst Du für einen Unsinn? "SRecord runs on almost any flavor of UNIX. The source distribution is self configuring using a GNU Autoconf generated configure script. SRecord also runs on Windows. You can build SRecord for Windows using Cygwin or DJGPP, see the Windows page."
Gast
#5972450
Bernd K. schrieb: > Was laberst Du für einen Unsinn? Bla. > SRecord also runs on Windows. You can build SRecord for Windows > using Cygwin or DJGPP, see the Windows page." Bla. Einer von uns beiden hat das real versucht, der andere zitiert bloß die Doku.
Nop schrieb: > Bernd K. schrieb: > >> Was laberst Du für einen Unsinn? > > Bla. > >> SRecord also runs on Windows. You can build SRecord for Windows >> using Cygwin or DJGPP, see the Windows page." > > Bla. Einer von uns beiden hat das real versucht, der andere zitiert bloß > die Doku. Nein, Du hast einen Schwachsinn von "pubertärem Humor" und "absichtlich" dahergelogen. Dafür gibt es keinen Anhaltspunkt, ganz im Gegenteil.
Gast
#5972466
Bernd K. schrieb: > Nein, Du hast einen Schwachsinn von "pubertärem Humor" und "absichtlich" > dahergelogen. Werd mal nicht unverschämt, Bürschchen. > Dafür gibt es keinen Anhaltspunkt, ganz im Gegenteil. http://srecord.sourceforge.net/windows.html Mit kleinem weinendem Kind rechts. Gar nicht pubertär.
Nop schrieb: > http://srecord.sourceforge.net/windows.html > > Mit kleinem weinendem Kind rechts. Gar nicht pubertär. Wo steht da daß er irgendwas absichtlich unportabel gemacht hat?
Gast
#5972483
Bernd K. schrieb: > Wo steht da daß er irgendwas absichtlich unportabel gemacht hat? Lies die Hauptseite. Upgraden auf Linux. Abgesehen davon sollte ein CLI-Tool, was einfach nur Dateien einliest, transformiert und wieder wegschreibt, überhaupt keine OS-Abhängigkeit haben. Das kann man auch in portablem C/C++ schreiben und mit jedem standardkonformen Compiler übersetzen. Alles andere ist an sich schon ein Antipattern.
Nop schrieb: > Bernd K. schrieb: > >> Wo steht da daß er irgendwas absichtlich unportabel gemacht hat? > > Lies die Hauptseite. Upgraden auf Linux. Die hab ich oben zitiert. Dort stehen Anweisungen für Windows, also hat er das vorgesehen, das genaue Gegenteil von dem was Du unverschämterweise unterstellst. Er hat sich sogar sehr ausführliche Mühe gegeben eine extra Seite für Windows zu machen und in ellenlanger Ausführlichkeit die Schritte aufzulisten, weitaus mehr als man überhaupt hätte verlangen können!
Gast
#5972490
Bernd K. schrieb: > also hat er das vorgesehen, das genaue Gegenteil von dem was Du > unverschämterweise unterstellst. Ich wiederhole: Du hast überhaupt keine Ahnung, weil Du bloß die Doku zitierst. Ich habe das real unter Cygwin versucht, bevor ich mir stattdessen mein eigenes Tool geschrieben habe, weil nichts von der Srecord-Doku so funktioniert wie behauptet. Zusammen mit den auch im Rest der Doku anzutreffenden Seitenhieben auf Windows ergibt sich da ein sehr eindeutiges Bild. Die suche ich Dir jetzt aber nicht im Einzelnen raus, das darfst Du selber tun. Übrigens funktioniert mein Tool, was den für mich wichtigen Teil der Srecord-Funktionalität abbildet, selbstverständlich unter Windows und Linux gleichermaßen, ohne daß irgendwelche Anpassungen nötig wären. Für das Gegenteil muß man sich schon entweder anstrengen oder komplett unfähig sein, und Letzteres wollte ich den Srecord-Entwicklern nun nicht unterstellen.
Nop schrieb: > Bernd K. schrieb: > >> also hat er das vorgesehen, das genaue Gegenteil von dem was Du >> unverschämterweise unterstellst. > > Ich wiederhole: Du hast überhaupt keine Ahnung, Jetzt wiederhole ich! Um nämlich nochmal auf Deine dreiste unverschämte Lüge zurückzukommen: > Die Autoren sind in recht > pubertärem Humor auch noch stolz drauf, daß sie es geschafft haben, ein > solch vergleichsweise simples Tool nicht-portabel hinzukriegen" Wo genau steht das? Antworte gefälligst oder schweige!
Gast
#5972498
Bernd K. schrieb: > Wo genau steht das? Antworte gefälligst oder schweige! Siehe Vorposting und Vor-Vorposting. EOD, Du trollst lediglich dämlich herum und hast substantiell genau gar nichts beigetragen. Leute wie Du ziehen das Forum echt runter.
Nop schrieb: > Leute wie Du > ziehen das Forum echt runter. Du ziehst das Forum herunter indem Du aus heiterem Himmel Autoren von freien Softwareprojekten beleidigst und ihnen Sachen unterstellst die nicht der Wahrheit entsprechen.
Gast
#5972618
Bernd K. schrieb: > Du ziehst das Forum herunter indem Du aus heiterem Himmel Autoren von > freien Softwareprojekten beleidigst und ihnen Sachen unterstellst die > nicht der Wahrheit entsprechen. Es fällt allerdings schon sehr schwer, zu erklären, warum man zum Bau so eines doch eher trivialen Streameditors überhaupt zwingend gcc und cygwin braucht. Das kann nach Lage der Dinge nur Unfähigkeit oder Absicht sein. Der eigentliche Code sieht aber eben nicht nach völliger Unfähigkeit aus, sondern scheint soweit ganz brauchbar zu sein (habe nur flüchtig reingeschaut). Was bleibt denn da deiner Meinung nach noch als Erklärung über?
c-hater schrieb: > Was bleibt denn da deiner Meinung nach noch als Erklärung über? Daß er es mit gcc und autotools entwickelt hat vielleicht? Immerhin ist das der de-facto Standard und auf ALLEN relevanten Plattformen verfügbar (sogar auf Windows) was man von so manchen anderen Toolchains nicht sagen kann, er hat also den gemeinsamen Nenner gewählt und keine künstliche Einschränkung vorgenommen. Weise Entscheidung.
Gast
#5972787
Srecord ist auch zu Empfehlen! Gruss Chregu
Gast
#5972792
c-hater schrieb: > Es fällt allerdings schon sehr schwer, zu erklären, warum man zum Bau so > eines doch eher trivialen Streameditors überhaupt zwingend gcc und > cygwin braucht. Wegen "scratch my itch" und "works for me". Dann noch eine Crypto-Lib als externe Abhängigkeit reingesetzt, weil mehr Abhängigkeiten schließlich mehr Spaß bedeuten. Und bitte keine Leerzeichen in Pfadnamen, immer ein Indiz für solide Software. Aber was erwartet man schon von Leuten, die WISSEN, daß etliche Eeprommer nur mit 16 Datenbytes pro Datenzeile im Hexformat klarkommen - und das nicht etwa zum Anlaß nehmen, 16 Bytes als Default zu wählen. Nee wieso, da nimmt man "natürlich" 32 Bytes und lästert dann lieber in der Doku über blöde Eeprommer ab.
Gast
#5972856
Bernd K. schrieb: > Daß er es mit gcc und autotools entwickelt hat vielleicht? Immerhin ist > das der de-facto Standard Nur in deiner, sehr kleinen Welt...
Bernd K. schrieb: > Du schreibst daß Du das problemlos programmieren kannst, dann mach es > doch. Die Kollegen benutzen dann Dein Programm um die Kalibrierwerte > einzugeben und dann klicken sie auf den "Flash"-Button und dann geht > alles automatisch. Wenn Du programmieren kannst dann kannst Du das so > idiotensicher machen daß es ein trainierter Schimpanse bedienen kann. Wo > ist das Problem? Mache ich auch :) siehe hier: Beitrag "Re: Intel Hex Format Dateien bearbeiten"
Nop schrieb: > Srecord funktioniert allenfalls unter Linux. Die Autoren sind in recht > pubertärem Humor auch noch stolz drauf, daß sie es geschafft haben, ein > solch vergleichsweise simples Tool nicht-portabel hinzukriegen. Sag dass bitte nicht meinem srec_cat das wir sehr erfolgreich und nativ unter Win7 verwenden. Nicht dass es auf einmal seinen Dienst quitiert. Nop schrieb: > bevor ich mir > stattdessen mein eigenes Tool geschrieben habe, weil nichts von der > Srecord-Doku so funktioniert wie behauptet. Erst letzte Woche mussten wir für ein (dem lieben Kunden geschuldetem) eher exotisches Bootloader-Scenario mehrere hexfiles wild mergen, Sektionen verschieben, ausschneiden und nochmal mergen und wieder verschieben. Ich hab Srecord/srec_cat lange nicht mehr benutzt, aber mit der umfassenden Doku war ich recht schnell in der Lage das Ganze so zu skripten dass es stabil und sauber läuft. Unter Windows, wohlgemerkt. Allerdings: mit Python und der IntelHex-Lib wäre ich noch schneller am Ziel gewesen. Aber wir wollten uns nicht noch mehr Abhängigkeiten in den Buildprozess ziehen.
A. F. schrieb: > Bernd K. schrieb: >> Du schreibst daß Du das problemlos programmieren kannst, dann mach es >> doch. Die Kollegen benutzen dann Dein Programm um die Kalibrierwerte >> einzugeben und dann klicken sie auf den "Flash"-Button und dann geht >> alles automatisch. Wenn Du programmieren kannst dann kannst Du das so >> idiotensicher machen daß es ein trainierter Schimpanse bedienen kann. Wo >> ist das Problem? > > Mache ich auch :) siehe hier: > Beitrag "Re: Intel Hex Format Dateien bearbeiten" Naja, das ist eigentlich nicht das was ich meinte. Das sieht aus wie ein universell verwendbarer Editor für Intel-hex. Was ich jedoch meinte war etwas zu programmieren das die Forderung nach Benutztbarkeit durch unkundige Personen erfüllt. Diese wissen doch genau NICHT welche Speicherstellen sie in welcher Art ändern müssen, wie die Datei überhaupt heißt und wo sie das hinspeichern müssen. Im Idealfall bekommen die einen Button vorgesetzt auf den sie klicken müssen und NULL Freiheitsgrade um irgendetwas falsch zu machen. DAS versuchte ich vorzuschlagen!
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.