Hallo, ich habe schon vor ca. 1 Jahr einen Thread aufgemacht und nun wollte ich ein kurzes "Update" geben. Da sich nun doch einiges in dieser Zeitspanne getan hat, enthält mein erster Beitrag veraltete Informationen zum Projekt und leider hat das Löschen bzw. Editieren nicht geklappt. Wie auch immer: Es handelt sich hierbei um einen AVR Debugger. Dieser nimmt Hexdateien (zurzeit nur im Intel ihex Format) entgegen und disassembliert diese und stellt dann eine Umgebung bereit in der es möglich ist den Code zu simulieren. Im Anhang findet sich noch ein aktuelles Screenshot vom Projekt. Was gibt's neues: - Backstep: Hat man mal was verpasst, kann man einfach zurückgehen - Step-Over: Man kann auch über Subroutinen steppen. - Bis zu 4 Dateien gleichzeitig simulieren - Mehrere Instruktionen hinzugefügt (zurzeit werden 91 Instr. unterstützt) - Es werden nun um die 30 verschiedene Debugcommands unterstützt - Syntax Highlight für den disassemblierten Code - Projekt nun in C verfasst Was noch ansteht: - Das Instruction-Set muss noch komplett implementiert werden - Graph-Ansicht für den disassemblierten Code - Support für Peripherie - vieles mehr... Natürlich wird jetzt die Frage auftauchen: Warum nicht einfach Atmel Studio, oder ähnliches benutzten ? Ich arbeite an diesem Projekt aus Spaß und Interesse, mein Ziel ist es nicht Atmel Studio abzulösen. Für den einen oder anderen mag das hier dennoch interessant sein, oder auch nicht :) Wer weitere Ideen dazu hat, kann sich gerne äußern. Verbesserungsvorschläge sind immer gern gesehen :) https://github.com/Milo-D/MDX-Assembly-Debugger
Angehängte Dateien:
-
mdx_avr.png
190 KB
@David M.: Das Bild sieht richtig gut aus. Dickes Lob. Ist genau das was ich schon lange suche, wenn man es dann für einen Raspberry Pi compilieren könnte, wäre es perfekt.
Ich verstehe nicht was das immer soll? Spaß ander Freude? OK. Aber ansonsten hast du doch keine Chance ein besseres Produkt als das Atmel Studio zu erstellen. Das hat Syntaxhighlightning und einen Simulator bereits drin und besser als du das das in Eigenregie jemals erstellen kannst. David M. schrieb: > Natürlich wird jetzt die Frage auftauchen: Warum nicht einfach Atmel > Studio, oder ähnliches benutzten ? Ich arbeite an diesem Projekt aus > Spaß und Interesse, mein Ziel ist es nicht Atmel Studio abzulösen. Für > den einen oder anderen mag das hier dennoch interessant sein, oder auch > nicht :) Ich sehe du hast meine Frage bereits beantwortet. Dann noch viel Spaß!
Thomas O. schrieb: > Ist genau das was ich schon lange suche, wenn man es dann für einen > Raspberry Pi compilieren könnte, wäre es perfekt. Wieso „könnte“? Das geht ohne ein Problem.
Thomas O. schrieb: > @David M.: Das Bild sieht richtig gut aus. Dickes Lob. > > Ist genau das was ich schon lange suche, wenn man es dann für einen > Raspberry Pi compilieren könnte, wäre es perfekt. @Thomas O. Vielen Dank für die Rückmeldung. Freut mich, dass es jemand nützlich findet :) Man kann es durchaus mit einem Crosscompiler (arm-gcc) für den Raspberry Pi kompilieren. Als das ganze noch in C++ verfasst war, habe ich dies auch getan, lief ohne Probleme. Falls es dennoch Probleme mit dem Raspberry Pi gibt, kannst du mir gerne Bescheid geben, dann würde ich mich gerne darum kümmern :)
Hallo, ich sehe das ziemlich anders. Die Tage von ATMEL Studio 7 sind gezählt. Da ist es schon gut eine alternative zu kennen. Allerdings muss an dem Debugger noch vieles Ergänzt werden (Target CPU, Symbolisches Debuggen etc.). Da stellt sich die Frage ob der Programmautor Zeit und Muse hat das alles zu integrieren. Ciao
Corona V. schrieb: > Ich verstehe nicht was das immer soll? Spaß ander Freude? OK. > Aber ansonsten hast du doch keine Chance ein besseres Produkt als das > Atmel Studio zu erstellen. Das hat Syntaxhighlightning und einen > Simulator bereits drin und besser als du das das in Eigenregie jemals > erstellen kannst. > > David M. schrieb: >> Natürlich wird jetzt die Frage auftauchen: Warum nicht einfach Atmel >> Studio, oder ähnliches benutzten ? Ich arbeite an diesem Projekt aus >> Spaß und Interesse, mein Ziel ist es nicht Atmel Studio abzulösen. Für >> den einen oder anderen mag das hier dennoch interessant sein, oder auch >> nicht :) > > Ich sehe du hast meine Frage bereits beantwortet. Dann noch viel Spaß! Besser als Atmel werde ich das wohl nicht hinkriegen, alleine da die die Chips entwickeln. Das stimmt. Das ist auch nicht das Ziel. Dennoch gibt es durchaus Leute, die eine Kommandozeile präferieren (sowie ich). Ich meine wo würden wir landen, wenn es zu einem Produkt gar keine Alternativen mehr gibt ?
Jürgen schrieb: > ich sehe das ziemlich anders. Die Tage von ATMEL Studio 7 sind gezählt. > > Da ist es schon gut eine alternative zu kennen. Allerdings muss an dem > Debugger noch vieles Ergänzt werden (Target CPU, Symbolisches Debuggen > etc.). Na ja, das Studio simuliert auch die Hardwaremodule des AVRs, davon ist der hier gezeigte Debugger weit entfernt. Für eine reine Softwaresimulation ohne Hardwaremodule hat avr-gdb zudem seit Ewigkeiten einen Simulator integriert, der das alles auch kann. Oliver
Oliver S. schrieb: > Jürgen schrieb: >> ich sehe das ziemlich anders. Die Tage von ATMEL Studio 7 sind gezählt. >> >> Da ist es schon gut eine alternative zu kennen. Allerdings muss an dem >> Debugger noch vieles Ergänzt werden (Target CPU, Symbolisches Debuggen >> etc.). > > Na ja, das Studio simuliert auch die Hardwaremodule des AVRs, davon ist > der hier gezeigte Debugger weit entfernt. > > Für eine reine Softwaresimulation ohne Hardwaremodule hat avr-gdb zudem > seit Ewigkeiten einen Simulator integriert, der das alles auch kann. > > Oliver Zurzeit wird leider keine Peripherie unterstützt, das stimmt. Dies soll sich aber definitiv ändern. Nur das ganze braucht halt seine Zeit. gdb ist ja auch nicht von heute auf morgen entstanden :)
Update: 8-bit Timer sind nun implementiert. Interrupts für den Timeroverflow funktionieren nun auch noch. Zurzeit wird nur Timer0 unterstützt, mit einem Prescaler von 1/8/64/256/1024. Externe Taktgebung wird in naher Zukunft noch einfließen, genau wie PWM und der 16-bit Timer. Desweiteren wurden noch einige Assembly Instructions ergänzt.
Angehängte Dateien:
-
mdx.png
390 KB
Update (v.0.4.3): (1) MDX kann nun das gesamte Instruction-Set dekodieren und darstellen. (2) Das EEPROM kann nun ebenfalls simuliert werden. Folgende Funktionen des EEPROMs können cyclegenau dargestellt werden: - Erase/Write (atomic) - Write Only - Erase Only - Read - ERDY Interrupts (3) IO Register Annotation. Die IO Register werden nun im Datensegment annotiert. Dies verbessert das Verständnis während der Simulation deutlich. (4) Schreibzugriffe auf reservierte IO Register werden nun blockiert und Lesezugriffe auf solche geben immer eine 0 zurück. (5) Neuer Debugcommand: Jump Cycles (jc), welches die Simulation um n Cycles vorspult. (6) Ein paar kleine notwendige Änderungen am Timer0 wurden auch noch vorgenommen, sowie ein paar kleine Bugfixes hier und da. (7) MDX unterstützt absofort ATmega328(P).
David M. schrieb: > (7) MDX unterstützt absofort ATmega328(P). Wenn du wirklich was Gutes tun willst, dann solltest du dich auf die Teile konzentrieren, für die das Studio keine Simulatoren bereitstellt, d.h. die "neuen" Megas und Tinys, sowie die AVR64DA/DB und AVR128DA/DB. Also all den Kram der auf XMega-Technologie basiert. Denn bei all diesen Teilen fehlt mir ein Simulator schmerzlich. Debugging "OnChip" ist nur ein sehr ungenügender Ersatz. OK, kann für bestimmte Probleme natürlich auch sehr hilfreich sein, aber für viele andere ist er es halt nicht wirklich, bzw. nur zum Aufspüren der Situation, bei der es dann endlich kracht. Um sich davon ausgehend dann rückwärts zur eigentlichen Ursache des Problems durchzukämpfen, ist nur mit mit einem "full-featured" Simulator möglich. Also einem, der erstens auch die Peripherie simuliert und zweitens Stimuli ermöglicht. So dass man die Entstehungsgeschichte des "sichtbaren" Fehlers immer wieder neu auf immer wieder gleiche Weise abspulen kann. Wenn dein Simulator das kann, würde ich mich notfalls auch mit mit einer Kommandozeilen-Oberfläche abfinden. Sowas finde ich zwar ziemlich pervers und unkomfortabel, aber besser ein zwar beschissen zu handhabendes, aber immerhin funktionierendes Werkzeug als gar keins... Aber leider: Bis dein Simulator dieses Stadium des Funktionierens für meine Zwecke erreicht haben wird, werde ich sehr wahrscheinlich lange in Rente sein und Mikrochip selber wird wohl in irgendeiner Form endlich Simulatoren für diese Teile gebacken bekommen haben, die dann vermutlich auch eine brauchbare graphische Oberfläche haben werden...
@David: Lass dich nicht entmutigen, finde es klasse was du als Einzelperson hier geschafft hast. Mein Wunsch wäre es ja wenn man das irgendwie auf einem Raspberry nutzen konnte.
Thomas O. schrieb: > Mein Wunsch wäre es ja wenn man das > irgendwie auf einem Raspberry nutzen konnte. In seinem github Link ist doch eine genaue Beschreibung, wie man es auscheckt und compiliert. Was willst du mehr? Natürlich musst du git, gcc, ... installiert haben.
Thomas O. schrieb: > @David: Lass dich nicht entmutigen, finde es klasse was du als > Einzelperson hier geschafft hast. Mein Wunsch wäre es ja wenn man das > irgendwie auf einem Raspberry nutzen konnte. Danke vielmals ^^ Den Simulator kann man durchaus auf dem Raspberry Pi laufen lassen. Hab ich sogar schon mal gemacht, jedoch war es damals noch in C++. Sollte aber eigentlich keine Probleme geben, da gcc ja einen Crosscompiler für ARM anbietet. Du kannst es gerne mal auf dem Raspberry Pi ausprobieren und falls Probleme auftreten sollten, würde ich mich sehr gerne um diese kümmern ^^ Danke nochmal.
von compilieren habe ich keine Ahnung so eine geführte Anleitung wäre aber wirklich klasse und wäre mir eine Spende wert.
c-hater schrieb: > David M. schrieb: > >> (7) MDX unterstützt absofort ATmega328(P). > > Wenn du wirklich was Gutes tun willst, dann solltest du dich auf die > Teile konzentrieren, für die das Studio keine Simulatoren bereitstellt, > d.h. die "neuen" Megas und Tinys, sowie die AVR64DA/DB und AVR128DA/DB. > Also all den Kram der auf XMega-Technologie basiert. > > Denn bei all diesen Teilen fehlt mir ein Simulator schmerzlich. > Debugging "OnChip" ist nur ein sehr ungenügender Ersatz. OK, kann für > bestimmte Probleme natürlich auch sehr hilfreich sein, aber für viele > andere ist er es halt nicht wirklich, bzw. nur zum Aufspüren der > Situation, bei der es dann endlich kracht. Um sich davon ausgehend dann > rückwärts zur eigentlichen Ursache des Problems durchzukämpfen, ist nur > mit mit einem "full-featured" Simulator möglich. Also einem, der erstens > auch die Peripherie simuliert und zweitens Stimuli ermöglicht. So dass > man die Entstehungsgeschichte des "sichtbaren" Fehlers immer wieder neu > auf immer wieder gleiche Weise abspulen kann. > > Wenn dein Simulator das kann, würde ich mich notfalls auch mit mit einer > Kommandozeilen-Oberfläche abfinden. Sowas finde ich zwar ziemlich > pervers und unkomfortabel, aber besser ein zwar beschissen zu > handhabendes, aber immerhin funktionierendes Werkzeug als gar keins... > > Aber leider: Bis dein Simulator dieses Stadium des Funktionierens für > meine Zwecke erreicht haben wird, werde ich sehr wahrscheinlich lange in > Rente sein und Mikrochip selber wird wohl in irgendeiner Form endlich > Simulatoren für diese Teile gebacken bekommen haben, die dann vermutlich > auch eine brauchbare graphische Oberfläche haben werden... Die XMega Reihe klingt auch sehr interessant. Ich könnte mir die Architektur mal anschauen, vielleicht lässt sich diese noch unterbringen. Den Support für den ATmega328(P) einzustellen wäre aber nicht mehr möglich, da ich schon viel zu weit gekommen bin um das alles nun zu verwerfen. Als einzelne Person werde ich den Support für die XMega, wie du schon richtig gesagt hast, höchstwahrscheinlich nicht rechtzeitig rausbringen können. Jedoch sind Alternativen wichtig. Vielleicht nicht für die Mehrheit der Nutzer, aber es ist immer sinnvoll einige Alternativen zu haben, da diese sich ja durchaus gegenseitig ergänzen können. Beispielsweise das Backstepping, welches MDX unterstützt, ist oftmals eine nette Ergänzung. Zur Kommandozeile kann ich sagen, dass diese oftmals viel schneller bedient werden kann als eine GUI. Der Wechsel von Maus zur Tastatur und zurück kann doch schon recht anstrengend werden. Ansonsten hängt der Rest meist immer von der Angewohnheit ab. Außerdem kann man ja immer noch eine GUI dazu erstellen, nur für mich ist die Oberfläche, sei es nun eine Kommandozeile oder eine richtige GUI, eher uninteressant und zweitrangig.
Thomas O. schrieb: > von compilieren habe ich keine Ahnung so eine geführte Anleitung wäre > aber wirklich klasse und wäre mir eine Spende wert. Gerne. Ich melde mich gleich wieder mit einer kleinen Anleitung (dürfte nicht wirklich schwierig werden) ^^
Thomas O. schrieb: > von compilieren habe ich keine Ahnung so eine geführte Anleitung wäre > aber wirklich klasse und wäre mir eine Spende wert. So, hab das mal vorhin auf einem Raspberry Pi 3 kompiliert und ausprobiert. Funktioniert auf den Ersten Blick einwandfrei, zumindest auf einem frisch installierten Raspbian OS. Hier die Anleitung: 1.) git clone https://github.com/Milo-D/MDX-Micro-Debugger.git 2.) cd MDX-Micro-Debugger 3.) sudo apt-get install libncurses5-dev libncursesw5-dev 4.) make clean all 5.) mv build/apps/mdx /usr/bin/ Der 3. Schritt installiert die ncurses Library, welches die Terminal-"grafik" ermöglicht. Die ist recht klein und kompakt. Der 5. Schritt ist optional und ermöglicht es dir MDX von überall aus aufzurufen. Kannst auch eine Pfadvariable in der .bashrc setzen. Läuft auf dasselbe hinaus. Das wärs dann sogar schon. Das ganze dauert vielleicht eine Minute. Bei Fragen zur Benutzung, gibt es ein kleines Github Wiki (https://github.com/Milo-D/MDX-Micro-Debugger/wiki) oder einfach direkt Kontakt aufnehmen (am besten per Email). Eine Sache wäre da noch. Ich habe das Programm nicht wirklich für ARM entwickelt und somit auch nicht wirklich ausgiebig getestet. Ich denke mal nicht, dass es da zu Problemen kommt, sollte dir aber dennoch was auffallen, gerne einfach Kontakt aufnehmen, dann kann ich mich darum kümmern ^^
also ich habs jetzt mal auf 2 Rpis installiert einmal per git clone und einmal per wget runtergeladen. auf dem einen mit git clone mal getestet, scheint zu funktionieren, habe mal das Hexfile einen ATMegaM16 durchgesteppt auf die schnelle könnte es einen Fehler beim der movw geben, da werde ich mir aber noch genaue anschauen und berichtet. Ich schau mir mal alles an vielleicht kann ich etwas unterstützung liefern und wenn es nur irgendwelche Schreibarbeit für andere AVRs ist. Da das ganze bei mir nicht Fensterfüllend ist wäre rechts noch Platz z.B: Kommandoübersicht. Könnte ja auch ein komplett neues Fenster/Programm sein das man neben hinschiebt. Edit: Achja und wo kann ich mal nen Keks hinüberweisen
:
Bearbeitet durch User
Thomas O. schrieb: > also ich habs jetzt mal auf 2 Rpis installiert einmal per git clone und > einmal per wget runtergeladen. > > auf dem einen mit git clone mal getestet, scheint zu funktionieren, habe > mal das Hexfile einen ATMegaM16 durchgesteppt auf die schnelle könnte es > einen Fehler beim der movw geben, da werde ich mir aber noch genaue > anschauen und berichtet. > > Ich schau mir mal alles an vielleicht kann ich etwas unterstützung > liefern und wenn es nur irgendwelche Schreibarbeit für andere AVRs ist. > > Da das ganze bei mir nicht Fensterfüllend ist wäre rechts noch Platz > z.B: Kommandoübersicht. Könnte ja auch ein komplett neues > Fenster/Programm sein das man neben hinschiebt. > > Edit: Achja und wo kann ich mal nen Keks hinüberweisen Freut mich dass es funktioniert. Also die movw Instruktion funktioniert bei mir, andererseits wird der ATmega16 zurzeit noch nicht unterstützt. Falls es da wirklich einen Fehler geben sollte, gib mir einfach kurz bescheid und ich mache das schnell fertig ^^ Das mit den zusätzlichen Fenstern ist durchaus in Planung. Generell soll die CLI mal überarbeitet werden, da sie leider noch recht wenig Flexibilität bietet, vorallem was die Programmierung und Erweiterbarkeit angeht. Ich habe der CLI leider zu wenig Zeit gewidmet (finde diesen Teil des Projekts eher lästig ^^). Es war so gedacht, dass das rechte Panel (zurzeit SourceCode Panel) später mal austauschbar sein wird. Beispielsweise könnte man sich dort vielleicht eine IO-Register Beschreibung einblenden lassen oder aber eben auch die erwähnte Kommandoübersicht. Zum Keks: Danke vielmals, aber ich nehme kein Geld für sowas an. Ist mir schließlich eine Freude ^^ LG
Sieht sehr gut aus ! ich mag die Art die Infromation darzustellen die du gewählt hast, genau wie ich es mir vorstelle :). Mehr ist mehr :) Eine Frage, hast du an die Symbolen in map Datei gedacht ? So dein disassembly die Namen der Funktionen und der Specher kennt. Es funktioniert auch in wsl (Ubuntu 16.04 LTS) !, man muss ncurses-dev noch instalieren, ich musste.
Ale schrieb: > Sieht sehr gut aus ! ich mag die Art die Infromation darzustellen die du > gewählt hast, genau wie ich es mir vorstelle :). Mehr ist mehr :) > Eine Frage, hast du an die Symbolen in map Datei gedacht ? So dein > disassembly die Namen der Funktionen und der Specher kennt. > > Es funktioniert auch in wsl (Ubuntu 16.04 LTS) !, man muss ncurses-dev > noch instalieren, ich musste. Danke, freut mich, dass es dir gefällt. Du meinst wahrscheinlich das Listing File ? Ja das wäre tatsächlich noch eine gute Idee um die Lesbarkeit weiter zu verbessern ^^
Update (v.0.4.4): - Die Ausführgeschwindigkeit wurde drastisch verbessert. Es können nun ca. 12,8 Millionen Cycles in der Sekunde simuliert werden. Sprich die Simulation "taktet", zumindest auf meinem i5, mit knapp 13 MHz, was natürlich immernoch verbesserungswürdig ist, da die ATmega328er mit bis zu 20 MHz takten können. Somit wäre ein bedeutendes Ziel, die Simulation auf mindestens 20 Millionen Cycles/Sekunde zu bringen. - Ein User aus diesem Forum hat mich netterweise darauf hingewiesen, dass das Makefile ein paar Fehler hat. Diese sind mit dieser Version behoben worden. Danke nochmals ;)
Thomas O. schrieb: > Sollte ich make clean all nochmal ausführen? "make clean all" baut das gesamte Projekt ohne inkrementelle Kompilierung. Das hat den Nachteil, dass es etwas länger dauert als ein "make all". Du bist damit jedoch auf der sicheren Seite, da das "make all" veränderte Headers nicht mit berücksichtigt. Und da das Kompilieren so oder so nur ein paar Sekunden beansprucht, würde ich es mit "make clean all" kompilieren ^^ Edit: Falls du irgendwelche Fehler entdecken solltest, melde dich einfach. Ich habe das ganze zwar vor dem Release gründlich getestet, aber man weiß ja nie ;)
:
Bearbeitet durch User
Auf der einen Seite finde ich Deine Aktivität bewundernswert. Auf der anderen Seite frage ich mich, ob die Energie nicht besser in ein bestehendes Projekt investiert wird, um es voranzubringen. Ich habe ein paar Verbesserungen zu mul, muls und mulsu: bei allen müssen die Cycles nicht um 1, sondern um 2 hochgezählt werden. bei allen kann man statt (result & ff00)>>8 einfach result>>8 schreiben (evtl. bei negativem Vorzeichen aufpassen, dass kein asr passiert) Danke
Vorn N. schrieb: > Auf der einen Seite finde ich Deine Aktivität bewundernswert. > Auf der anderen Seite frage ich mich, ob die Energie nicht besser in ein > bestehendes Projekt investiert wird, um es voranzubringen. > > Ich habe ein paar Verbesserungen zu mul, muls und mulsu: > bei allen müssen die Cycles nicht um 1, sondern um 2 hochgezählt werden. > bei allen kann man statt (result & ff00)>>8 einfach result>>8 schreiben > (evtl. bei negativem Vorzeichen aufpassen, dass kein asr passiert) > > Danke Vielen dank ^^ Ja da hast du Recht. Es sind anscheinend wirklich 2 Cycles. Gut, dass du da nochmal drüber geschaut hast. Dadurch, dass ich so viel von Grund auf entwickelt habe, konnte ich sehr viel über die AVRs lernen. Ich weiß nicht, ob so viel hängengeblieben wäre, hätte ich die Energie in andere Projekte gesteckt ^^
David M. schrieb: > zu 20 MHz takten können. Somit wäre ein bedeutendes Ziel, die Simulation > auf mindestens 20 Millionen Cycles/Sekunde zu bringen. Wenn du das mit den ganzen noch fehlenden Hardwaremodulen hinbekommst, chapeau... Oliver
Oliver S. schrieb: > David M. schrieb: >> zu 20 MHz takten können. Somit wäre ein bedeutendes Ziel, die Simulation >> auf mindestens 20 Millionen Cycles/Sekunde zu bringen. > > Wenn du das mit den ganzen noch fehlenden Hardwaremodulen hinbekommst, > chapeau... > > Oliver Ist ehrlich gesagt auch einer meiner Sorgen. Aber ich habe da noch einige unnötige Performance Einbuße, welche recht einfach sein sollten zu beheben aber dennoch einen signifikanten Anteil der Rechenzeit ausmachen. Außerdem versuche ich auch nur die aktivierten Hardwaremodule zu simulieren. Klar, wenn man nun alle Module gleichzeitig aktiviert, wird sich das auf die Performance auswirken. Aber das ist doch hoffentlich die Ausnahme ^^
wollte dir ein paar Darstellungsfehler zeigen, soll ichs übers Forum posten, dann sieht man ob andere auch davon betroffen sind.
Thomas O. schrieb: > wollte dir ein paar Darstellungsfehler zeigen, soll ichs übers Forum > posten, dann sieht man ob andere auch davon betroffen sind. Kannst es gerne hier ins Forum posten oder ein Issue auf Github aufmachen. Ist eigentlich egal ^^
Angehängte Dateien:
-
AVR-Debugger_Registeransicht.png
150 KB -
Befehlszeile.png
9,7 KB
ich habe schon mit verschiedenen Terminaleinstellungen gespielt z.B. Zeilen/Zeichenanzahl. Vielleicht würde ein Leerzeichen nach R1: genügen wäre noch etwas kompakter. Das mit der Kommando-Übersicht meinte ich so wie es bei Norton oder Midnight-Commander ist da hat man unten diese Übersicht für die Funktionen der F-Tasten. Praktisch wäre es auch wenn man das nicht jede Eingabe mit Enter bestätigen muss. In Basic hätte ich jetzt gesagt statt input inkey o. get benutzen um eine einzige Tastenabfrage durchzuführen.
Thomas O. schrieb: > ich habe schon mit verschiedenen Terminaleinstellungen gespielt z.B. > Zeilen/Zeichenanzahl. Vielleicht würde ein Leerzeichen nach R1: genügen > wäre noch etwas kompakter. > > Das mit der Kommando-Übersicht meinte ich so wie es bei Norton oder > Midnight-Commander ist da hat man unten diese Übersicht für die > Funktionen der F-Tasten. > > Praktisch wäre es auch wenn man das nicht jede Eingabe mit Enter > bestätigen muss. In Basic hätte ich jetzt gesagt statt input inkey o. > get benutzen um eine einzige Tastenabfrage durchzuführen. Versuch's mal mit Strg- Die CLI könnte da ein bisschen mehr responsive sein, da hast du Recht ^^ Jedoch braucht sie auch einen gewissen Mindestplatz um die ganzen Daten darzustellen. Mit Strg- bzw Strg+ kann man das ganze skalieren. Sobald sich die Terminalgröße verändert, wird MDX reagieren und sich anpassen. Du musst auch nicht jedes mal den Befehl abtippen. Ähnlich wie bei gdb wird die letzte Eingabe zwischengespeichert. Dann braucht man nur noch Enter zu drücken. Also beispielsweise einmal 'n' eingeben für das Steppen und dann nur noch Enter drücken um den letzten Befehl erneut auszuführen. Die kleine Kommandoübersicht gefällt mir, vielleicht könnte man die tatsächlich noch einbauen. Ich muss mal gucken wie es mit dem Platz aussieht. Ansonsten könnte man ein seperates Panel dafür schreiben, falls die Liste zu lang wird.
Thomas O. schrieb: > ich habe schon mit verschiedenen Terminaleinstellungen gespielt z.B. > Zeilen/Zeichenanzahl. Vielleicht würde ein Leerzeichen nach R1: genügen > wäre noch etwas kompakter. > > Das mit der Kommando-Übersicht meinte ich so wie es bei Norton oder > Midnight-Commander ist da hat man unten diese Übersicht für die > Funktionen der F-Tasten. > > Praktisch wäre es auch wenn man das nicht jede Eingabe mit Enter > bestätigen muss. In Basic hätte ich jetzt gesagt statt input inkey o. > get benutzen um eine einzige Tastenabfrage durchzuführen. Und ? Hat dir die letzte Antwort weitergeholfen oder gibt es da immernoch Probleme ^^
Angehängte Dateien:
-
MDX_zoom_out.png
9,5 KB -
MDX_n.png
24 KB -
MDX.png
150 KB
die Aktualisierung funktioniert ganz selten mal, meist stürzt es mit einem Speicherfehler ab sobald ich anschließend n drücke. Ansonsten sieht es so aus. Denke ich muss die Schrift noch kleiner machen. Ich probiere mal nen Screenshot zu machen. Kann man eigentlich Registerwerte ändern?
Thomas O. schrieb: > die Aktualisierung funktioniert ganz selten mal, meist stürzt es mit > einem Speicherfehler ab sobald ich anschließend n drücke. Ansonsten > sieht es so aus. Denke ich muss die Schrift noch kleiner machen. Ich > probiere mal nen Screenshot zu machen. > > Kann man eigentlich Registerwerte ändern? Okay, das sollte eigentlich nicht passieren. Könnte sein, dass es daran liegt, dass du es auf dem Raspberry benutzt, da habe ich es nämlich noch gar nicht testen können. Ich schaue mir das direkt mal an. Vielleicht könntest du ein Issue aufmachen auf Github mit den Schritten zur Reproduktion des Speicherzugrifffehlers. Das würde aufjedenfall weiterhelfen und ich könnte das recht schnell fixen.
ok hab es eingestellt. Ich beschreib es hier nochmal kurz. MDX im Terminalfenster starten z.B: mdx avr.hex Mit STRG+Shft+- einen Zoom out probieren(dachte damit verkleinert man die Schrift) es wird aber das Terminalfenster selber verkleinert, danach sieht man nur noch die blauen Rahmen ohne Inhalt. Um eine Aktualisierung anzustoßen, dachte ich einfach mal einen Step mit n und anschließendem Enter und schon wird das Programm mit dem Speicherfehler beendet. Edit: Enter ist garnicht nötig sobald man n drückt fliegt man raus nach dieser Zoomaktion
:
Bearbeitet durch User
Thomas O. schrieb: > ok hab es eingestellt. > > Ich beschreib es hier nochmal kurz. > > MDX im Terminalfenster starten > z.B: mdx avr.hex > > Mit STRG+Shft+- einen Zoom out probieren(dachte damit verkleinert man > die Schrift) es wird aber das Terminalfenster selber verkleinert, danach > sieht man nur noch die blauen Rahmen ohne Inhalt. > > Um eine Aktualisierung anzustoßen, dachte ich einfach mal einen Step mit > n und anschließendem Enter und schon wird das Programm mit dem > Speicherfehler beendet. > > Edit: Enter ist garnicht nötig sobald man n drückt fliegt man raus nach > dieser Zoomaktion Habs mir gerade mal angeschaut. Auf Debian funktioniert das ohne Probleme, jedoch weiß ich jetzt wo der Fehler liegt und bin fast fertig mit dem Fix dazu. Es liegt daran, dass die Mindestgröße unterschritten wird und somit die einzelnen Fensterkomponenten falsch initialisiert werden. Das kann dann bei einigen Systemen wohl als stiller Fehler durchgehen ohne abzustürzen. Beim Raspberry Pi offenbar nicht ^^ Heute oder morgen ist der Fehler beseitigt. Bis dahin kannst du einfach dein Terminal (bevor du MDX startest) mit Strg+ bzw Strg- auf eine akzeptable Größe stellen und dann MDX starten.
Angehängte Dateien:
-
mdx.png
400 KB
Update (v.0.5.0): -> Kernmodul für die zukünftige statische Analyse hinzugefügt. Es soll in Zukunft möglich sein, mittels statischer Analyse, noch ein wenig mehr aus den AVR Binaries rauszuholen. Unter anderem sollen folgende Module ihren Weg in den Debugger finden (zumindest in der Theorie): 1.) Funktions-Analyse. Eventuell kann man versuchen, die Argumente und den Rückgabewert sowie die Verweise auf die jeweilige Funktion zu ermitteln und diese dann dem Nutzer bereitzustellen. 2.) SFR-Analyse. Dieses Submodul sollte recht bald eingefügt werden. Es soll sich darum kümmern, konstante Addressen im Sourcecode zu finden, die sich auf das Dataspace beziehen um diese dann mit dem dementsprechenden IO-Registernamen zu annotieren (falls es denn überhaupt ein IO-Register ist). 3.) Interrupt-Analyse bzw. ISR-Analyse. Man könnte ebenfalls versuchen, ISRs zu annotieren und sie somit vom Rest des Codes hervorzuheben. 4.) Vieles mehr... -> Performance verbessert: Es können nun ca. 17.000.000 Cycles pro Sekunde simuliert werden, was ca. 17 MHz entspricht. Somit kann nun der ATmega328P eines Arduinos in Echtzeit simuliert werden (bei der Standardkonfiguration zumindest). -> Es können nun eigene Kommentare während des Debuggings eingefügt werden. -> Der zuvor gemeldete Bug in der UI wurde noch nicht behoben. Ich habe mich dazu entschieden die UI zu refactoren und dann den Bug zu fixen. Mit diesem Update wurde auch die UI refactored und somit kann ich demnächst damit beginnen den Bug zu fixen. Der Fehler tritt auf, wenn das Terminal extrem vergrößert wird. Also kann man den Fehler bis dahin ganz gut vermeiden, da man bei solch einer Größe ohnehin nicht alle Panels darstellen kann. -> Es werden nun, anstelle von Zeilennummern, Addressen im Seitenpanel angezeigt. -> Einige kleinere Änderungen hier und da. Edit: Leider zweimal denselben Screenshot hochgeladen. Kann dies anscheinend auch nicht mehr rückgängig machen.
:
Bearbeitet durch User
David M. schrieb: > Leider zweimal denselben Screenshot hochgeladen. Kann dies anscheinend > auch nicht mehr rückgängig machen. Habe den zweiten gelöscht.
Beitrag #6532266 wurde vom Autor gelöscht.
Angehängte Dateien:
-
mdx_debug.png
360 KB
Update (v.0.5.2 + v.0.5.3) -> Analyzer Pipeline um einen Instruction Decomposer erweitert. Dieser zersetzt Opcodes in ihre Operanden und klassifiziert diese (Immediate, Register, etc.). Dies könnte später für die statische Analyse wichtig werden. -> Desweiteren wurde das EEPROM Modul um den Write-Only Modus ergänzt. Damit werden nun alle 3 Modi (erase-write, erase, write) unterstützt. Im EEPROM Modul fehlen nun nur noch die CPU Halts nach einem Read/Write. -> Eine Opcode Ansicht wurde dem Disassembly hinzugefügt. Dies vereinfacht das Matching von Opcode zu Instruktion. -> Kleine Änderungen am Prescaler vom Timer0. -> Neue Datenstruktur zur Collection hinzugefügt, um die ineffiziente queue_t abzulösen. -> Desweiteren wurden Heap-Allocations reduziert. Generell soll im Laufe der Zeit der Heapverbrauch reduziert werden, da dieser zurzeit noch zu hoch ist. Weitere Verbesserungen in der Richtung folgen also noch.
Angehängte Dateien:
-
sfr.png
140 KB
Update (v.0.5.4) -> Es wurde ein Submodul für den Analyzer hinzugefügt. Der SFR Analyzer kümmert sich um die Referenzen auf IO Register und annotiert diese um somit einen besseren Überblick zu erhalten. So wird beispielsweise aus: sbi 0x1f, 2 ; IO[1f, 2] <- 0x01 sbi 0x1f, 2 ; EECR -> Ein neuer Debugcommand wurde hinzugefügt: 'xeb' (examine EEPROM as bitmap). Dieser Befehl gibt einfach nur die Binärdarstellung einer EEPROM Zelle aus. -> Kleiner Refactor vom 8-bit Timer Modul -> Ein paar kleine Aufräumarbeiten: Unbenutzte Headers, Variablen wurden entfernt.
Angehängte Dateien:
Update (v.0.6.0) -> Der Speicherverbrauch des Disassemblers und des Analyzers wurde deutlich reduziert. (Issue #47) -> Neues Submodul zum Analyzer hinzugefügt: Der Label Analyzer. Dieser untersucht das Disassembly auf mögliche Labels und weist ihnen eine eindeutige ID zu. Desweiteren werden die Aufrufe/Verzweigungen zu solchen Labels ermittelt. Diese Callers werden dann gespeichert um später tiefergehende Analysen zu ermöglichen. -> Die generierten Labels werden nun aufsteigend sortiert und angezeigt. Beispielsweise würde das Label L12 vor L14 im Disassembly liegen. - Ein Bug im Disassembler wurde gefixt. (Issue #46) - Neben dem Speicherverbrauch wurde auch die Laufzeit des Disassemblers und Analyzers deutlich verbessert. - Diverse andere Kleinigkeiten, welche man sich im offiziellen Changelog nochmal anschauen kann. Update (v.0.5.5) -> Die Projekt Struktur wurde nochmal überarbeitet. Die Engine, welches die Analyzer Pipeline beinhaltet (Decoder, Decomposer, Disassembler, Analyzer, virtueller Mikrocontroller) wurde vom Debugger getrennt und in verschiedene Verzeichnisse gesteckt. -> Die Struktur sieht nun folgendermaßen aus: engine |------ src |------ include debugger |------ src |------ include shared |------ src |------ include -> In Zukunft würde ich gerne versuchen eine statische Library aus der Engine zu machen. Diese könnte man dann für Programmanalysen (statisch und dynamisch) verwenden. Oder aber auch als Test-Suite für Mikrocontroller sodass man kleine Tests für reale Projekte schreiben kann.
:
Bearbeitet durch User
Update (v.0.7.0) -> Die Simulation erreicht nun Geschwindigkeiten von knapp 20 MHz. Somit kann man nun die ATmega328 Familie in Echtzeit simulieren. -> Ich habe das User Interface, welches als c-hater schrieb: > pervers und unkomfortabel galt, aus der Repo geschmissen ;) und aus dem Projekt eine Library für statische und dynamische Analyse von AVR Programmen gebaut. Ich habe mich dafür entschieden, da ich wesentlich mehr Lust habe an der Engine zu arbeiten ohne mir den Kopf darüber zerbrechen zu müssen, wie ich denn die neuen Features überhaupt in die Commandline reinquetschen kann. Der Nutzen der Library soll sein: - automatisierte (Regression) Tests für Embedded Systems, um echte Hardware Projekte auf potentielle Fehler zu testen. - binäre Analyse von AVR Programmen - natürlich kann man die Library auch einsetzten um seine eigenen Tools, wie beispielsweise einen Simulator zu bauen Später sollen auch noch Bindings für andere Programmiersprachen, wie bspw. Python und Java folgen. Kleine Randnotiz: Da ich die Engine erst vor kurzem zu einer Library gemacht habe, könnten sich noch einige Implementierungsdetails verändern. Über Verbesserungsvorschlage oder generell Feedback würde ich mich freuen, da ich nur so, eine für den Nutzer, angenehme Library erstellen kann ^^ Der neue Link zur Repository: https://github.com/Milo-D/libvmcu-Virtual-MCU-Library Was mit MDX passiert ? MDX wird in eine neue Repository verlegt. Diese kann dann bei Bedarf maintained werden.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
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.