Hallo ReAVR-Freunde, es freut mich zu lesen, dass mein AVR-Dis- oder vielmehr Reassembler (weil er direkt wiederverwertbaren Assemblercode erzeugt) auch in den 2020ern noch immer wieder einmal Thema ist. Vielleicht freut es Euch dann auch, dass ich ihn Ende des letzten Jahres noch einmal angepackt habe, um ihm nun auch den Umgang mit den vielen neuen AVRs seit den XMegas beizubringen. Das hat sich zwar als ein etwas umfangreicheres Unterfangen herausgestellt, aber ich bin dabei und hoffe, in den nächsten Monaten eine erste Testversion auf meine Website stellen zu können. Über den Namen bin ich mir noch nicht klar - "ReAVR_II" oder "ReAVRplus" - doch einen neuen Namen wird die neue Version auf jeden Fall erhalten. Außerdem wird es ein Companion-Tool geben, das die avrasm-*def.inc-Dateien aus den Studio-7- oder MPLAB-Repositories liest und in die ReAVR-internen Listen mit MCU-Spezifikationen und IORegister-Adressen umwandelt. Nicht zu vergessen die Möglichkeit, eigene Kommentare einzufügen, wahlweise am Ende einer Zeile oder als neue Zeile, wegen derer ich die ganzen Änderei überhaupt angefangen hatte... ;) Ich werde die neue Version ASAP veröffentlichen. Also "stay tuned." Beste Grüße Johannes
Ich wüßte nicht, wozu man so etwas gebrauchen könnte. Interessante Geräte sind gelockt, da kommt man also an den Code nicht ran. Und größere Projekte sind in Hochsprachen geschrieben, da sieht der Assembler wie Kraut und Rüben aus. Bei komplexen Projekten ist neu programmieren oftmals einfacher als reassemblieren.
Peter D. schrieb: > Ich wüßte nicht, wozu man so etwas gebrauchen könnte. In dem Moment, in dem du das Ding brauchst, weißt du, wofür du das brauchst. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > In dem Moment, in dem du das Ding brauchst, weißt du, wofür du das > brauchst. Hä?
Ich bin gespannt! Wie schaut es mit der Unterstützung der ATTiny4/5/9/10 aus? Da hätte ich das ein oder andere Projekt, bei dem das super nützlich wäre!
Oliver S. schrieb: >> Ich wüßte nicht, wozu man so etwas gebrauchen könnte. > > In dem Moment, in dem du das Ding brauchst, weißt du, wofür du das > brauchst. Und Apfelmus ist Mus aus Äpfeln!
Ghidra … auch wenn es ausgerechnet von der NSA kommt, es ist Opensource, und es zimmert gleich noch ein C-Code-Gerippe zurecht. Hab's gerade mal auf einem aktuellen AVR-Projekt (mit ATtiny204) probiert. Gut, die Vektortabelle, die sie benutzen, hat nicht die korrekten Namen (und Länge), muss man halt korrigieren. Aber ansonsten schon durchaus beeindruckend, was sie da aus dem Stand heraus erkennen. Das das nicht ohne Interaktionen geht, ist natürlich klar. J. A. schrieb: > weil er direkt wiederverwertbaren Assemblercode erzeugt Geht auch mit dem ganz normalen Disassembler aus den Binutils. Man muss nur die Headerzeilen und die Spalten mit Adressen und Opcodes wegwerfen. Gerade probiert:
1 | avr-objdump -d myfile.hex --disassemble-zeroes -b ihex -m avr5 -j .sec1 | sed -e '1,7d' -e 's/^..................//'> foo.s |
2 | avr-as -mavr5 -o foo.o foo.s |
3 | avr-ld -o foo.elf foo.o |
4 | avr-objcopy -O ihex foo.elf foo.hex |
5 | diff -u myfile.hex foo.hex |
6 | # -> keine Unterschiede gefunden |
:
Bearbeitet durch Moderator
Ey, @Folks, macht doch bitte J.A. nicht nieder. Das Programm ist kostenlos benutzbar, hat ne freie Lizenz und ist unter anderem in Delphi geschrieben. Als Hacker oder reverse engineer ist man bei seinem Hobby auf jeden "Strohhalm" angewiesen, der einem gereicht wird, da ist das Proggy dann doch gut! @J.A., wie willst Du das Millitär von Deinem Proggy fernhalten? Hast Du da ne besondere Strategie? ;-O ;-))) mfg
J. A. schrieb: > Über den Namen bin ich mir noch nicht klar - "ReAVR_II" oder "ReAVRplus" Üblich ist die Vergabe von Versionsnummern: An erster Stelle für Mayor-Releases (hochgezählt bei wesentlichen Änderungen, Inkompatibilitäten) und danach Minor (Bugfixes, Tippos in der Doku, etc.). Ansonsten wird's irgendwann komisch Tool ToolII ToolPlus ToolBesser ToolNochBesser ToolSuperGutUndNochViiielBesser ToolSuperHypeMegaUnglaublichHyperGutBestEverII
Lotta . schrieb: > und ist unter anderem in Delphi geschrieben. Macht das irgendwas besser, außer daß es mancher Leute religiöse Gefühle bedient?
Harald K. schrieb: > Lotta . schrieb: >> und ist unter anderem in Delphi geschrieben. > > Macht das irgendwas besser, außer daß es mancher Leute religiöse Gefühle > bedient? Hey, Du hast es genau erfasst: Philippe Kahn hat damals in der Wende den "Raubkopier-Ossis" nicht juristisch nachgestellt, sondern Ihnen ne kostenlose Lizenz gegeben, also ihre Raubkopien legalisiert. Das hat natürlich Auswirkungen auf die Loyalität der Leuts zu Borland bis heute, auch wenn Borland ja inzwischen leider zigmal umfirmiert wurde. Hatte bestimmt auch mit guten Beziehungen des Ostblocks mit Frankreich zu tun, (der osten hat zb. das Secam Fensehsystem übernommen) Philippe war ja Franzose. mfg
Harald K. schrieb: > Muss man nicht verstehen. Es war einfach ne geile, interessante Zeit damals. Philippe hat damals einfach den "Ossis" geholfen, die mit 100 DM Begrüßngsgeld in ne neue Gesellschaftsordnung mit "keiner Ahnung von Tuten und Blasen" gestoßen wurden. Heut machen die Superreichen und Politiker lieber Bombenangriffe auf Krankenhäuser und Kindergärten. das macht ja auch mehr Spass. :-((((((( mfg
:
Bearbeitet durch User
Echt fantastisch, was ich so alles zu lesen bekomme. Na dann stelle ich mal in den Raum, dass ich von Geburt Niedersachse bin und mein ganzes bisheriges Leben dort verbracht habe, von gelegentlichen Ausflügen in andere Gegenden Deutschlands und Europas abgesehen. Dass ich etliche Programme in 8080- und Z80-Hex-Code geschrieben und meinen HD64180-CP/M-Computer erst aufgegeben habe, als ich mich, von außen gedrängt, in die AT-kompatible Welt begab. Da waren dann schon alle 8088-, 8086-, 80186- und 80286-Maschinen an mir vorbei gegangen, und das damals noch übliche MS-DOS hatte schon die Version 5 erreicht. Von Windows war in der Zeit noch allenfalls gerüchteweise zu hören, bis Windows 3.0 herauskam, und als soweit erschwingliche höhere Programmierumgebung gab es nur TurboPascal. Linux und Open-Source waren damals noch überhaupt kein Thema. Ich war damals und bin es bis heute in einem Betrieb der produktiven Industrie beschäftigt und hatte/habe daher einige Möglichkeiten, stellte aber irgendwann fest, dass ich beim Programmieren durcheinander kam, als ich versuchte, alle meine Aufgaben in C zu erledigen. Weshalb ich mich entschloss, C nur für meine AVR-Projekte zu verwenden, und für meine PC-Anwendungen Pascal, im weiteren dann Delphi. Diese Entscheidung war rein pragmatisch und hat nichts mit religiösen Gefühlen zu tun. Wenn derlei je im Spiel gewesen wäre, hätte ich mich auch wohl kaum darauf eingelassen, für den c't68000 Anwendungen in Pearl zu schreiben, oder die Testprogramme für ein Transputer-Projekt in Occam. Im Übrigen bin ich am Überlegen, den neuen ReAVR, wenn er erstmal alles so tut wie gewünscht, in ein Lazarus-Projekt umzuwandeln und ihn anschließend dem Open-Source-Verfechter aus der Runde zur weiteren Betreuung zu übergeben. Dann wären seine Mäkeleien mit einem Schlag aus der Welt. Und ich hätte nichts mehr damit zu tun. Ein paar Anmerkungen zu speziellen Kommentaren noch: Die erste zum Namen. Klar ist die übliche Methode, einfach die Version hochzuzählen, und das habe ich in der Vergangenheit auch immer so gehalten. Nur gehen diesmal die Änderungen so weit, dass ich mir einfach solche Fragen ersparen möchte wie "Warum geht dies und das auf einmal nicht mehr?" Die zweite dazu, wozu ReAVR gut ist. Lieber Kommentator, es wird Dich wahrscheinlich überraschen, wie viele AVRs für professionelle embedded Anwendungen ungelockt sind. Tatsächlich sind mir bei meinen Untersuchungen zu meiner eigenen Überraschung nur wenige gelockte untergekommen. Ansonsten kann man sich, wenn man mit Assembler so weit vertraut ist, problemlos in den Hex-Code eines Compilers einlesen. Ok, bei größeren Codes ab 8 oder 16KB wird das zeitaufwändig, und man muss entscheiden, ob man es wirklich vertreten kann. Und zu den binutils: Klar bekommt man damit mit etwas Editor-Gefummle auch ein wieder assemblierbares Disassembly hin. Aber auch nur das, mit allen kryptischen Labels, wie sie sind. Und wenn man dann zum Beispiel bei den in/out-Instruction die richtigen IO-Namen haben will, muss man für jeden einzeln ein Suchen/Ersetzen anstoßen. Genau das macht aber ein Reassembler wie ReAVR von sich aus automatisch - und interaktiv.
J. A. schrieb: > Genau das macht aber ein Reassembler wie ReAVR von sich aus automatisch > - und interaktiv. Wie geschrieben, Ghidra letztlich auch, und das erzeugt auch gleich noch ein C-Code-Gerippe. Man könnte den Aufwand also eigentlich auch da reinstecken, dass Ghidra von Haus aus noch möglichst viele AVRs mit all ihren Register-Details kennt, damit man diese automatisiert konvertieren kann. > Nur gehen diesmal die Änderungen so weit, ReAVR NG :-) Aber auch das hätte natürlich das Problem, was Johann beschreibt: wenn die übernächste Version wieder alles über den Haufen wirft, suchst du wieder einen neuen Namen. Daher die übliche Konvention, dass man bei inkompatiblen Änderungen die major number hochzählt. Aber seit Feuerfüchse und dergleichen alle nasenlang die Nummern komplett hochzählen, ist das natürlich auch irgendwie Vergangenheit.
J. A. schrieb: > Ok, > bei größeren Codes ab 8 oder 16KB wird das zeitaufwändig, und man muss > entscheiden, ob man es wirklich vertreten kann. Ja, bei Anwendungen über das Anfängerniveau hinaus wird das schnell unhandlich. Ich habe schon lange keine Hemmungen mehr, float, printf, scanf zu verwenden, um bequem programmieren zu können. Auch Structs und Arrays sehen in Assembler extrem kryptisch aus, erhöhen aber in C erheblich die Lesbarkeit und Flexibilität. Den typischen Spaghetticode möchte man eigentlich nicht mehr haben. Und um Fehler zu suchen oder Abläufe zu verstehen, ist es oftmals einfacher, das Programm im Debugger laufen zu lassen.
Jörg W. schrieb: > Wie geschrieben, Ghidra letztlich auch, und das erzeugt auch gleich noch > ein C-Code-Gerippe. Und was ist mit den Kommentaren und selbsterklärenden Namen?
Noch ein paar Anmerkungen, bevor ich mich verabschiede, bis der neue ReAVR fertig ist: @Jörg: Ich habe kurz bei Ghidra vorbei gesehen und festgestellt, dass da im Prinzip dasselbe Schema verfolgt wird wie bei Microchips MPLAB - der Code ist Java-basiert und damit recht einfach auf alle drei "großen" OSse anzupassen (Linux, MacOS und Windows). Was die includes angeht, habe ich noch nicht weiter geforscht und kann deshalb nicht sagen, ob die geradeaus oder vielleicht etwas skurril sind. Vielleicht magst Du mir einmal ein Beispiel zukommen lassen, gerne auch als PN? Die "NG"-Idee ist übrigens nicht schlecht ;) Und keine Sorge. Es wird danach keine weitere so tiefgreifende Änderung von ReAVR mehr geben. @Peter: Wie kommst Du eigentlich darauf, dass 8 bis 16KB AVR-Code Anfängerniveau sind? Aber vielleicht hast Du bisher einfach nie eine kostenkritische embedded Anwendung programmieren müssen, bei der die gehobenen Funktionen uninteressant waren, weil es dort weder floats noch Schnittstellen gab, auf die printf oder scanf angewendet werden konnten. Ansonsten finde ich C-Code im Disassembly keineswegs kryptisch. Ich brauche mich nur etwas einzulesen und dabei vielleicht ein Dutzend Aufruf-Labels global zu ändern. Was mit ReAVR ganz einfach geht... Nach meiner Erfahrung gibt es nur einen Compiler, der wirklich kryptischen Assemblercode erzeugt, und das ist Bascom. @Georg: Genau. Dazu hat bisher keiner etwas beigetragen. Beste Grüße Johannes
J. A. schrieb: > Was die includes angeht, habe ich noch nicht weiter geforscht und kann > deshalb nicht sagen, ob die geradeaus oder vielleicht etwas skurril > sind. Vielleicht magst Du mir einmal ein Beispiel zukommen lassen, gerne > auch als PN? Sorry, nein, die Interna von Ghidra habe ich mir nicht angesehen. Ich hatte es nur mal kurz auf mein aktuelles (dienstliches) AVR-Projekt losgelassen und dabei gesehen, dass sie zwar IO-Ports und Interruptvektoren benennen, die aber für meinen ATtiny204 natürlich nicht korrekt sind. Ich wurde auch erst vor kurzem drauf aufmerksam gemacht, weil ich eine 68000er Firmware analysieren möchte (meines Spektrumanalysators, für den es schon lange niemanden mehr gibt, der einem Fragen zu den Interna beantworten könnte).
Hallo J. A., lasse dich nicht ärgern. Ich verstehe den Threadverlauf auch nicht. Viel zu viel Gemecker.
Hallo, ich möchte sagen, dass ich durch diesen Thread gerade erst auf ReAVR aufmerksam geworden bin und werde ihn auf jeden Fall ausprobieren. Mit den Binutils kann ich bestätigen, ist das Ergebnis eher durchwachsen. Zu TurboPascal und Delphi. Die Sprache ist genial und wurde lange in der Lehre verwendet. Der Borland Compiler ist super schnell, dass war damals einzigartig! Und Delphi war zu Windows 3.1 und Win95 Zeiten das einzig brauchbare RAD Tool und das hat Eindruck hinterlassen! Von daher verstehe ich das Gemecker nicht ;-) ReAVR als Lazarus Projekt und Open-Source würde ich begrüßen
Johann L. schrieb: > Üblich ist die Vergabe von Versionsnummern: An erster Stelle für > Mayor-Releases ...für den Bürgermeister? :-)
J. A. schrieb: > Wie kommst Du eigentlich darauf, dass 8 bis 16KB AVR-Code > Anfängerniveau sind? Nun, das sind so meine Erfahrungswerte. Einfache Projekte (Timer, Meßgeräte) sind damit noch kein Problem. Aber für komplexe Steuerungen und Regelungen steigt der Aufwand schnell an. Typisch sind auch Schnittstellen zur Fernbedienung, Kalibration und Diagnose nötig. 10k Codezeilen kommen da schnell zusammen. J. A. schrieb: > Aber vielleicht hast Du bisher einfach nie eine > kostenkritische embedded Anwendung programmieren müssen Ich habe keine so hochvolumigen Anwendungen, wo man ewig lange dran rum entwickeln kann und erst recht nicht in Assembler. Bei unseren geringen Stückzahlen ist die Entwicklungs- und Testzeit der Hauptkostenpunkt. Außerdem werden die Projekte sehr oft erweitert, so daß gute Wartbarkeit und hohe Flexibilität eine wichtige Voraussetzung sind. Der Kunde weiß beim Start des Projektes oft selber noch nicht so richtig, was die Software alles können soll. So sind sehr oft noch viele Änderungen und Erweiterungen nötig. J. A. schrieb: > weil es dort weder floats noch > Schnittstellen gab, auf die printf oder scanf angewendet werden konnten. Sobald Standardfunktionen einen Entwicklungsvorteil bieten, werden sie eingesetzt. Mehr Flash kostet ja nichts im Vergleich zu längerer Time-to-Market.
Ich habe mir 1995 mal angeschaut, wie der Keil C51 die Matheroutinen implementiert hat. Die Lib-Funktionen werden nicht im Listing angezeigt, nur deren Aufrufe. Daher habe ich ein C-Programm geschrieben, es im Simulator gestartet und dann aus dem Codefenster den Assembler rauskopiert. Die Routinen des Hern Keil waren natürlich viel effizienter, als meine Versuche. Das war quasi mein einzigstes Reassembling.
:
Bearbeitet durch User
Sehr gerne fasse ich auch Variablen zu Structs und Arrays of Structs zusammen. Das erhöht deutlich die Übersicht und ist auch leicht mit weiteren Members erweiterbar. In Assembler möchte ich mir das allerdings nicht ansehen. Ich verlasse mich voll darauf, daß der Compiler die ganzen Indirektionen, Indexes und Offsets schon richtig berechnet.
J. A. schrieb: > Wie kommst Du eigentlich darauf, dass 8 bis 16KB AVR-Code > Anfängerniveau sind? In der Codesammlung habe ich mal eine DCF77-Uhr mit ATtiny12 veröffentlicht. Das war aber mehr eine Demonstration, was mit nur 512 Befehlen im Flash so geht. Am meisten hat mich dabei der nur 3-Level Hardwarestack geärgert. Ursprünglich war die DCF77-Uhr in C51 auf dem AT89C2051 mit 2kB Flash geschrieben. Daher wußte ich schon recht genau, wo ich noch was eindampfen konnte.
:
Bearbeitet durch User
Peter D. schrieb: > Am meisten hat mich dabei der nur 3-Level Hardwarestack geärgert. Das hat ja jenseits von AT90S1200 und ATtiny11/12 auch keiner mehr sonst gehabt. ;-)
Moin zusammen, doch noch ein paar Anmerkungen vor dem Abtauchen. Dazu waren die letzten Beiträge einfach zu gut ;) @Jörg: Schade, ich hatte von Dir als demjenigen, der so auf Ghidra abhob, erhofft, dass Du mir dazu ein paar Tips geben könntest... Ansonsten finde ich, dass der Tiny28 - der erste Tiny mit mehr als 8 Pins - und der Tiny15, der noch nach den 11/12/28 kam und als erster mit interner x4 PLL "richtig" schnelle 8bit-PWM ermöglichte, durchaus auch einer Erwähnung bei den RAM-less AVRs wert sind. @Peter: Im Prizip hast Du mit Deinen weiteren Erläuterungen fast alle Deine Einwände so weit relativiert. Und in einem Punkt fast ad absurdum geführt: Dein "einzigstes" (gibt es im Deutschen gar nicht, nur "einziges") Reassembly war von 8051- und nicht von AVR-Code. Aber auch egal. Jedenfalls bist Du schon einmal mit Reassemblieren weiter gekommen. Also denk einfach, dass selbst ich, der Autor, ReAVR heutezutage zumeist dazu benutze, durch fremden Lib-Code, wie etwa den ~8KB großen für STs Time-of-Flight-Sensoren durchzusteigen, um ihn für meine C-Anwendungen bestmöglich zu konfigurieren und die zurück gelieferten Daten bestmöglich zu verarbeiten. Im übrigen noch zweierlei: Erstens habe ich in meiner Anfangszeit bei der Firma, für die ich bis heute arbeite, einen IAR-8051-C nacharbeiten dürfen, den anscheinend 1:1 aus einem int Pascal geschriebenen Versuchscode abgeleitet worden war. Ich hoffe, Du verstehts, was ich meine... Zweitens habe ich mit der Vorgabe THT und noch bevor der ATmega128 verfügbar wurde auf Grundlage des ATmega161 eine Fax-Anwendung programmiert, bei der über den externen Bus ein SRAM für die zu übertragenden Daten sowie ein EPROM für die TIF-Muster verwendet wurden, weil für beide die internen Speicher des AVRs nicht ausreichten. Mit den heutigen AVRxxDs und allgemein verbreiteter SMT wäre das ein Klacks und C für alles keine Frage, aber vor über 20 Jahren war es einfach noch nicht so. @Thorsten: Falls Du ein IOR-File für einen AVR brauchst, das noch nicht existiert, schreibe mir einfach eine PN. Der Generator für alle möglichen IOR-Files existiert bereits, ist aber vielleicht etwas zu groß für den bisherigen ReAVR. Ansonsten hast Du recht. TurboPascal war der Vorreiter und Delphi war unter Windows lange Zeit das RAD IDE schlechthin. Bis Microsoft mit seinen Visual-Progammierumgebungen den von Delphi eingeführten Objectinspector abkupferte... Und @Veit: Danke. Aber Gemecker macht mir hier nichts mehr aus. Irgendwie scheint es für Manche ein Muss zu sein ;)
J. A. schrieb: > @Jörg: Schade, ich hatte von Dir als demjenigen, der so auf Ghidra > abhob, erhofft, dass Du mir dazu ein paar Tips geben könntest... Sorry, dazu bin ich auch noch zu neu dort. > Ansonsten finde ich, dass der Tiny28 - der erste Tiny mit mehr als 8 > Pins - und der Tiny15, der noch nach den 11/12/28 kam und als erster mit > interner x4 PLL "richtig" schnelle 8bit-PWM ermöglichte, durchaus auch > einer Erwähnung bei den RAM-less AVRs wert sind. Historisch halt, genauso wie AT90S1200 und ATmega103, der dann ziemlich schnell einen ATmega128 als Nachfolger bekam. Dieser wiederum wurde zum „Dauerbrenner“, der wird als ATmega128A sogar zwei Jahrzehnte später noch produziert.
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.