Hallo, ich bräuchte eine einmalige Hilfe um einen hex Code in der Arduino-Umgebung, also als Sketch lesen zu können. ich möchte aber nicht das komplette Assembling und so lernen, da ich es wirklich nur für zwei .hex Dateien mit ca 100 Zeilen, die mir zwar zur Verfügung stehen. Dort ich gerne zwei Umrechnungsfaktoren ändern bei Bedarf. Hier mal Zeile 11-13 von 100 zur Anschauung was mir leider unleserlich zur Verfügung steht. Code: :1000A00015BA97E392BB9FE19ABB87BB8CE384BBF5 :1000B00080E381BB84E083BF82E88FBD88E18EBD91 :1000C00080EE91E09BBD8ABD80E483BD87E989BF56 wenn mir jemand den Gesamtcode wieder zum lesen aufbereiten könnte? Vielen Dank im voraus Einstein55
> ich bräuchte eine einmalige Hilfe um einen hex Code in der > Arduino-Umgebung, also als Sketch lesen zu können. Einfach den Quellcode laden und feddisch. > ich möchte aber nicht das komplette Assembling und so lernen Brauchst Du auch nicht, das macht die Toolchain für Dich. Was Du augenscheinlich machen willst ist Disassemblieren. Spar Dir die Arbeit und such den Quellcode, das ist weniger Aufwand. > wenn mir jemand den Gesamtcode wieder zum lesen aufbereiten könnte? Was wäre dann?
Hallo g457 Quellcode wäre super.... der ist leider seit 2013 in den ewigen Festplattengründen. Einstein55
Guten morgen, die Darstellung nennt man Intel-Hex-Format # https://de.wikipedia.org/wiki/Intel_HEX Hinter dieser Darstellung verbergen sich die Binärdaten eines Assemblerprogramms. Das wiederum aus einer Hochsprache erzeugt wurde. Man kann das Intel-Hex-Format in Binärdaten umwandeln und dann mit einem Disassembler die Assembler Memnomics ansehen. Ich verwende dazu den Disassembler von LunaAVR. Mehr kann man nicht erwarten.
Ich fürchte das wird nicht ohne etwas höhere Kosten ablaufen, wenn sich hier nicht ein Nerd findet, der das zum Spass macht. Jedenfalls müsste man mal vorher wissen, welche Informationen Du insgesamt überhaupt vorliegen hast, damit man abschätzen kann, ob überhaupt eine Chance besteht eine Konstante im Code zu identifizieren. Das man Dir den Sketch wieder herstellt ist eher illusorisch. Allenfalls einen Sketch, der genau diesen Assemblercode enthält.
Um nichts installieren zu müssen: https://onlinedisassembler.com/odaweb/ Dort kannst Du deine Datei hochladen, oder auch hier anhängen damit vielleicht noch andere mit spielen können.
Danke allen, das killt jetzt zwar meine Euphorie, etwas schneller zu erledigen, aber dann muss ich den Sketch eben neu schreiben. Ist ja nur eine Steppermotorregelung für einen Motor mit Anpassungsfaktor für Durchmesser zu Geschwindigkeitsanzeige. Und den Atmega16 wollte ich eigentlich schon lange gegen einen UNO austauschen. Einstein55
An den "Sketch", also den C++-Quellcode kommt man damit genauso gut wieder heran, wie man aus einem Batzen Hackfleisch die zugehörige Kuh rekonstruieren kann. Man kann das allenfalls in Assembler-Quelltext übersetzen, dem aber alle symbolischen Bezeichner fehlen, d.h. Variablennamen, Funktionsnamen etc. sind verloren und durch automatisch generierte Bezeichner ersetzt. Kommentare gibts natürlich auch keine, und Datentabellen im Code sind oft nicht als solche erkennbar. Das kommt auf die Qualität des verwendeten Disassemblers an, es gibt welche, die eine statische Codeanalyse vornehmen, und anhand dessen so etwas besser erraten können. Ein Beispiel dafür ist IDA, allerdings weiß ich gerade nicht, ob das AVRs kennt.
Rufus Τ. F. schrieb: > Ein Beispiel dafür ist IDA, allerdings weiß > ich gerade nicht, ob das AVRs kennt. Kann es: https://www.hex-rays.com/products/ida/processors.shtml
Udo W. schrieb: > > Quellcode wäre super.... > der ist leider seit 2013 in den ewigen Festplattengründen. > Das ist doch gar kein Problem, einfach auf die Datensicherung zugreifen und fertig!
Udo W. schrieb: > Ist ja nur eine Steppermotorregelung für einen Motor mit > Anpassungsfaktor für Durchmesser zu Geschwindigkeitsanzeige. Weißt du noch, wie der Parameter im Originalcode definiert war? Am einfachsten wäre es, wenn er aus dem EEPROM gelesen würde. Dann müsstest du die Firmware nicht einmal anfassen, sondern einfach nur die entsprechenden Bytes im EEPROM überschreiben. Falls der Parameter als globale Variable definiert wurde, stehen die Chancen immer noch ganz gut, den Wert im Disassembly zu finden und zu ändern, zumindest dann wenn man die Funktionsweise und den Ablauf des Programms noch einigermaßen im Kopf hat. Meist werden solche Dinge aber per #define definiert. Wenn der Parameter in arithmetischen Ausdrücken (womöglich sogar in mehreren) verwendet wird, die vom Compiler bis zur Unkenntlichkeit optimiert worden sind, wird es schon sehr schwierig, die zu patchende Stelle zu lokalisieren. Aber damit nicht genug: Wenn bspw. der ursprüngliche Parameter zufälligerweise eine Zweierpotenz war, für die der Compiler Multiplikationen zu Shift-Operationen optimiert hat, muss man diese nun evtl. durch eine echte Multiplikation ersetzen, d.h. selber ein paar Zeilen Assemblercode schreiben. Dabei muss man natürlich darauf achten, dass man nicht versehentlich ein noch anderweitig genutztes Register überschreibt. Und und und ... Da hast du das Programm sicher schneller neu geschrieben. Versuch es positiv zu sehen: Ein Programm, das man ein zweites Mal schreibt, wird meistens sehr viel besser (effizienter, weniger Fehler usw.).
Yalu X. schrieb: > Da hast du das Programm sicher schneller neu geschrieben. > > Versuch es positiv zu sehen: Ein Programm, das man ein zweites Mal > schreibt, wird meistens sehr viel besser (effizienter, weniger Fehler > usw.). Richtig, Ich habe jetzt den Parameter gleich mal zusätzlich einstellbar gemacht, um nicht bei Abweichungen jedesmal den Sketch ändern zu müssen. Die Beschichtungen der Rollen nutzen sich ja auch ab und das hatte doch schon Längenmessprobleme gegeben. Danke nochmal Einstein55
Yalu X. schrieb: > Versuch es positiv zu sehen: Ein Programm, das man ein zweites Mal > schreibt, wird meistens sehr viel besser (effizienter, weniger Fehler > usw.). Dieser Aussage würde ich mich fast vollständig anschliessen wollen. Klar, bei einer Re-Implementierung wählt man in aller Regel ein besseres Konzept zur Umsetzung der Problemstellung und dies sorgt dann dafür, dass der Kram am Ende auch effizienter wird. Aber was die Fehler betrifft, bin ich der Meinung, dass eine Re-Implementierung zwar recht zuverlässig alle alten Fehler entsorgt, aber dafür auch reichlich Gelegenheit gibt, ungefähr genau so viele neue einzubauen... Man findet sie Dank des besseren Programmkonzepts nur schneller. Allein deswegen kommt es einem so vor, als wären es in der neuen Variante des Codes deutlich weniger gewesen. Eine objektive Analyse zeigt allerdings i.d.R. ziemlich gnadenlos, dass das NICHT der Fall war. Über den Daumen gepeilt kann man wohl sagen: Im Mittel waren wieder genauso viele Fehler drin wie in der ursprünglichen Variante.
c-hater schrieb: > Über den > Daumen gepeilt kann man wohl sagen: Im Mittel waren wieder genauso viele > Fehler drin wie in der ursprünglichen Variante. Ist das Deine Selbstkritik an Deiner Programmierweise? Mit dem Problem des TO hat das doch überhaupt nichts zu tun, es sei denn, Du kennst das ursprüngliche und das aktuelle Programm.
c-hater schrieb: > bei einer Re-Implementierung wählt man in aller Regel ein besseres > Konzept zur Umsetzung der Problemstellung und dies sorgt dann dafür, > dass der Kram am Ende auch effizienter wird. Da haben andere Leute andere Erfahrungen gemacht: http://wiki.c2.com/?SecondSystemEffect "* The first time you use a new technology or build a new type of system, you know that you're a beginner, so you tend to be naturally conservative. * The second time around, you have experience. You know what you're doing. You have success under your belt, so you pull out all the stops and do all the things you are afraid to do the first time around. If your project is the second system for most of your designers, then it will probably fail outright. If it doesn't fail, it will be bloated, inefficient, and icky."
Dr. Sommer schrieb: > c-hater schrieb: >> bei einer Re-Implementierung wählt man in aller Regel ein besseres >> Konzept zur Umsetzung der Problemstellung und dies sorgt dann dafür, >> dass der Kram am Ende auch effizienter wird. > Da haben andere Leute andere Erfahrungen gemacht: > http://wiki.c2.com/?SecondSystemEffect Das scheint mir eine Fehlinterpretation zu sein. Bei Wikipedia zum Beispiel wird das schon wieder ganz anders verstanden: "The second-system effect (also known as second-system syndrome) is the tendency of small, elegant, and successful systems to be plagued with feature creep due to inflated expectations.[1] The phrase was first used by Fred Brooks in his book The Mythical Man-Month.[2] It described the jump from a set of simple operating systems on the IBM 700/7000 series to OS/360 on the 360 series." Außerdem halte ich dieses sogenannte "Syndrom" oder die Tatsache daß es formuliert wurde für eine Manifestation eines ganz anderen Syndroms, nämlich des "Von-Sich-Selbst-Auf-Die-Allgemeinheit-Schließen-Syndrom". Denn für jedes "zweite System" das schlechter ist als das vorherige kann man wahrscheinlich mindestens drei andere nennen bei denen es genau umgekehrt war. Und mindestens ebensoviele bei denen erst die dritte oder vierte Version schlecht wurde. Oder die fünfte. Oder schon die erste floppte jedoch aber die zweite hervorragend funktionierte. Oder die Dritte. Dieses sogenannte "Syndrom" ist IMHO ausgemachter Schwachsinn. Er hat viel zu wenig Stichproben genommen bevor er so eine allgemeingültige Regel hätte formulieren können, es ist vollkommen übergeneralisiert und nicht geeignet den Ausgang von irgendwas anderem vorherzusagen. Man muss wirklich nicht jeden Spruch der Fred Brooks mal in der Verbitterung über irgend ein in den Sand gesetztes Projekt seiner eigenen(!) Abteilung rausgerutscht ist in Stein meißeln und verehren als wäre Brooks ein Gott oder ein Prophet. Ich mach jetzt auch mal eine Vorhersage: Die zweite Version wird meistens besser Könnt ihr ebenso in Stein meißeln und daneben stellen.
:
Bearbeitet durch User
Ich kenne das ganz anders: Das erste Haus baue für Deinen Feind, Das zweite Haus für Deinen Freund, Das Dritte für Dich selbst.
:
Bearbeitet durch User
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.