Forum: Projekte & Code Update: AVR Debugger


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von David M. (milo-d)


Angehängte Dateien:

Lesenswert?

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

von Thomas O. (kosmos)


Lesenswert?

@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.

von Corona V. (coronavirus)


Lesenswert?

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ß!

von Jack V. (jackv)


Lesenswert?

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.

von David M. (milo-d)


Lesenswert?

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 :)

von Jürgen (Gast)


Lesenswert?

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

von David M. (milo-d)


Lesenswert?

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 ?

von Oliver S. (oliverso)


Lesenswert?

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

von David M. (milo-d)


Lesenswert?

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 :)

von David M. (milo-d)


Lesenswert?

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.

von David M. (milo-d)


Angehängte Dateien:

Lesenswert?

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).

von c-hater (Gast)


Lesenswert?

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...

von Thomas O. (kosmos)


Lesenswert?

@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.

von Gerhard (Gast)


Lesenswert?

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.

von David M. (milo-d)


Lesenswert?

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 Thomas O. (kosmos)


Lesenswert?

von compilieren habe ich keine Ahnung so eine geführte Anleitung wäre 
aber wirklich klasse und wäre mir eine Spende wert.

von David M. (milo-d)


Lesenswert?

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.

von David M. (milo-d)


Lesenswert?

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) ^^

von David M. (milo-d)


Lesenswert?

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 ^^

von Thomas O. (kosmos)


Lesenswert?

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
von David M. (milo-d)


Lesenswert?

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

von Ale (Gast)


Lesenswert?

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.

von David M. (milo-d)


Lesenswert?

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 ^^

von David M. (milo-d)


Lesenswert?

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 ;)

von Thomas O. (kosmos)


Lesenswert?

Sollte ich make clean all nochmal ausführen?

von David M. (milo-d)


Lesenswert?

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
von Vorn N. (eprofi)


Lesenswert?

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

von David M. (milo-d)


Lesenswert?

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 ^^

von Oliver S. (oliverso)


Lesenswert?

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

von David M. (milo-d)


Lesenswert?

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 ^^

von Oliver S. (oliverso)


Lesenswert?

Du wirst es herausfinden ;)

Oliver

von Thomas O. (kosmos)


Lesenswert?

wollte dir ein paar Darstellungsfehler zeigen, soll ichs übers Forum 
posten, dann sieht man ob andere auch davon betroffen sind.

von David M. (milo-d)


Lesenswert?

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 ^^

von Thomas O. (kosmos)


Angehängte Dateien:

Lesenswert?

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.

von David M. (milo-d)


Lesenswert?

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.

von David M. (milo-d)


Lesenswert?

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 ^^

von Thomas O. (kosmos)


Angehängte Dateien:

Lesenswert?

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?

von David M. (milo-d)


Lesenswert?

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.

von Thomas O. (kosmos)


Lesenswert?

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
von David M. (milo-d)


Lesenswert?

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.

von David M. (milo-d)


Angehängte Dateien:

Lesenswert?

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
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.
von David M. (milo-d)


Angehängte Dateien:

Lesenswert?

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.

von David M. (milo-d)


Angehängte Dateien:

Lesenswert?

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.

von David M. (milo-d)


Angehängte Dateien:

Lesenswert?

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
von David M. (milo-d)


Lesenswert?

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.