Forum: Projekte & Code AVR Simulator mit grafischer Benutzeroberfläche für Linux


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 R. M. (Gast)


Angehängte Dateien:

Bewertung
8 lesenswert
nicht lesenswert
Hallo an die große Runde!

Das Projekt, welches ich vorstellen möchte, ist aus einem Spieltrieb 
heraus entstanden, der dem ähnelt, den ich seinerzeit bei den ersten 
Schritten mit dem AVR-Studio entwickelt habe. Leider funktioniert dies 
aber unter WINE nicht so zuverlässig, wie ich es mir wünschen würde. Hin 
und wieder brauche ich aber doch eine kleine Hilfestellung, um einen 
Knoten im Kopf zu lösen..
Da ich vor vielen Jahren mal einen MCS-51-Simulator in Turbo-Pascal 
geschrieben hatte, wollte ich mal wissen, ob da noch was geht.
Dieses kleine Programm simuliert auch (erstmal) nur die CPU, vielleicht 
kommt später noch etwas Peripherie dazu.
Nichts professionelles, nur für den kleinen Spieltrieb zwischendurch.
mfG

von Rene S. (Firma: BfEHS) (rschube)


Bewertung
0 lesenswert
nicht lesenswert
Danke für deinen Beitrag!

Ich hab das mal kurz angetestet und es sieht auf den ersten Blick sehr 
gut aus.

Noch ein bisschen Besserwisserei ;-) Es ist GNU-Linux.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
1 lesenswert
nicht lesenswert
Das sieht gut aus.
Ist denn eine GDB Anbindung geplant?
Dann kann man noch besser debuggen ;)
Nen GDB Server coden is auch garnicht mal so schwer.

von R. M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Ist denn eine GDB Anbindung geplant?

Nein, der Simulator ist intern, und ob man die Sichten auf die Periperie 
über die GDB-Schnittstelle abbilden könnte, bin ich mir auch nicht 
sicher.

Das müsste ja dann gegebenenfalls der GDB-Server für die Hardware 
leisten.
Für die reine CPU gibt es den Simulator mit GDB-Schnittstelle ja auch 
schon. Und der simulavr zeigt das Wichtigste seines Innenlebens, 
(zusätzlich) über seine Konsole an.
Hab mal DDD als grafisches Frontend für den GDB auf simulavr getestet,
https://www.mikrocontroller.net/articles/AVR-Simulation#SimulAVR
da würde ich, vom Abstraktionsniveau, auf absehbare Zeit nicht hinkommen 
- wäre auch unsinnig, der ist ja ausgereift. Dort hatte ich lediglich 
die Stoppuhr, und die Unterstützung für die niedrigen Assembler 
vermisst. Vielleicht hab ich mich auch nur zu dumm angestellt.
In Hardwaredebugger habe ich bisher keine Zeit/ kein Geld investiert, da 
ich mir einbilde, das Funktionsprinzip des HW-Debuggings mit AVR ist, 
das auf den Haltepunkt eine BREAK-Anweisung geschrieben wird, die dann 
in den Debug-Modus führt. Sprich: es wird ständig auf den Flash 
rumgeschrieben, das wollte ich eigentlich vermeiden. Vielleicht fehlt 
mir dazu aber auch nur die Erfahrung. Kann mich erinnern, irgendwo bei 
Atmel gelesen zu haben, das man die Steine, die man für HW-Debugging 
genutzt hat, nicht mehr "scharf" einsetzen sollte.
Aber für so einen, ausschließlich in SW realisiertern Simulator sind 
auch die Einstiegshürden niedriger. Und den Simulator im Studio4 fand 
ich, wie bereits geschrieben, richtig gut. Seit dem Umstieg auf 
GNU/Linux (Danke Rene!), hab ich aber meine Arbeitsweise in mancher 
Hinsicht umgebaut. So hat mir die Sache, wenn auch der Nutzeffekt gering 
ist, trotzdem was gebracht. Zummindest kenne ich jetzt den Befehlssatz 
etwas besser als vorher. ;-)
mfG

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mit der tabellarischen Darstellung des RAM und Flash hat es schneller 
geklappt, als erwartet. Da sich die Aktualisierungsgeschwindigkeit 
dadurch deutlich erhöht hat, und gleich noch Möglichkeit dazu gekommen 
ist, diese Speicher manuell zu modifizieren, schiebe ich mal ein Update 
nach.
Ein Hinweis zum RAM: der geht ja eigentlich erst ab 0x60 los. Auf den 
unteren Adressen findet man die Register (0 bis 31) und den I/O-Bereich 
(0x20 bis 0x5f), den man damit auch in der Hand hat. Dies analog zu den 
Zugriffsmöglichkeiten der LD und ST-Befehle.
Der schon mit eingebaute EEPROM-Bereich hat zur Zeit noch keine 
Funktion, die kommt später.
An der Anleitung hat sich nichts geändert, dazu siehe erster Beitrag.
mfG

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte bei der GDB Schnittstelle auch eher an den Spieltrieb 
appeliert.
Danach weis man ziemlich sicher wie das funktioniert.

Die Periperie Register sind Memory mapped und der GDB kann Speicher 
auslesen, das geht also.
Die GDB Schnittstelle war auch eher als Zusatz gemeint, der Simulator 
bleibt wie er ist. Kann aber zusätzlich per GDB Debugbefehle entgegen 
nehmen.
Der Witz ist ja, dass der DDD dann mit deinem Simulator laufen würde, 
wenn du einen GDB Server einbaust ;)
DDD trommelt auf dem GDB rum, dieser trommelt auf deinem Simulator rum 
-> Profit!

Eine BREAK Anweisung in den Flash zu schreiben ist dann ein 
Softwarebreakpoint und so macht der GDB das auch. Ist sogar noch 
schlimemr als du denkst, denn der GDB löscht nach jedem STEP alle 
Breakpoints und legt die vor einem neuen STEP wieder an.
... Es könnte ja die Verbindung abbrechen und das Target mit wilden 
Breakpoints rumlaufen.
Man merkt eben, dass GDB eher von Mainframes kommt zum Userprozesse 
debuggen.

Ich hab ja auch schonmal nen Simulator geschrieben, aber für MIPS1.
Mit GDB Schnittstelle.
Da hätt man auch den QEMU nutzen könne, aber die Periperie war etwas 
spezieller.

von R. M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Ist sogar noch
> schlimemr als du denkst, denn der GDB löscht nach jedem STEP alle
> Breakpoints und legt die vor einem neuen STEP wieder an.

Das hatte ich mir schon so gedacht, macht ja eigentlich fast jedes 
Monitorprogramm so. Solange das Programm im RAM steht, tut das ja auch 
überhaupt nicht weh - aber diese Diskussion hatten wir hier ja schon 
öfter.
Fürchte blos, wenn ich zu viele Baustellen aufmache, dann verzettele ich 
mich. Meine nächsten Ziele sind, erstmal die Ansicht der wichtigsten 
Hardware auf der GUI abzubilden, dabei werde ich versuchen, die dafür 
erforderlichen Informationen weiterhin aus den <typ>def.inc Dateien zu 
beziehen. Dann kommt die Funktion der nicht statischen (Ports) Hardware 
dran: EEPROM, FLASH-Selbstprogrammierung, Timer (einschließlich 
Interrupts). Kann allerdings den Zeitrahmen dafür noch nicht annähernd 
abschätzen.
Wer sich mal den Quellcode angeschaut hat, wird bemerkt haben, das ich 
schon eine relativ klare Trennung zwischen dem Simulator und der GUI 
gezogen habe man könnte die Teile bei Bedarf auch auseinanderziehen. 
Vorher müssen sie aber erstmal beide fehlerfrei funktionieren.

mfG

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Inzwischen habe ich die Benutzeroberfläche stark überarbeitet.
Die Peripherie hat jetzt eine, nach Funktionsgruppen geordnete 
Baumansicht bekommen. Das bedingte allerdings, das ich von den "rohen" 
Includedateien abgehen musste und neue Definitionsdateien erstellen 
musste (iodefs). In der Anleitung dazu, bei Bedarf, mehr Details.
mfG

von R. M. (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Mittlerweile kann das Programm auch die "elf"-Objektdateien, welche 
avr-gcc 4.9.2 erzeugt, einlesen und die Quelltext-Zeileninformationen 
aus den debug-daten verarbeiten. Das avr-gcc_sample ist das Testprojekt, 
welches mir zum Evaluieren dient. Es besteht aus einem "C"-Hauptteil und 
2 Assemblermodulen. Die Verfolgung des "C"-Quelltextes funktioniert 
schon ganz gut (Der GCC packt die Info nach dem dwarf-Standard, der ganz 
gut dokumentiert ist), in den Assemblerteilen hakt die Verfolgung des 
Quelltextes noch stellenweise, dort gibt es noch was zu tun (hier werden 
die Quelltextzeilen in einer Weise kodiert, die weder bei elf, noch bei 
dwarf, noch bei stab wiederzuerkennen ist, aber das Prinzip erscheint 
auch so verständlich, daher schon die Grundfunktion da.

Wer damit das erste Mal ein in "C" geschriebenes Programm simuliert, 
bitte nicht wundern:
Bevor die erste Zeile der "main"-Funktion zu sehen ist, kommen erstmal 
einige Initialisierungen (Stackpointer, globale Variablen werden 
genullt), also nicht ungeduldig werden! Wenn man erstmal die 
Startadresse von main gesehen hat, kann man ja einen Haltepunkt dorthin 
setzen und beim nächsten Versuch mit "run" bis dort durchlaufen lassen.

Wenn das rund läuft, dann schau ich mal, ob ich das 
gdb-Netzwerkprotokoll finde, eventuell schaffe ich es doch noch, an 
einen Hardwaredebugger anzudocken - als erstes Opfer könnte ja der 
simulavr dienen.
Alternativ könnte ich versuchen, den avr-gdb über die 
Kommandozeilenschnittstelle "fernzubedienen", den Zeitrahmen dafür kann 
ich aber noch nicht abschätzen.
mfG

von R. M. (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ganz kleines Update:
Beim Einlesen der "elf"-Datei, wird jetzt auch die Symboltabelle 
(zummindest für den Codebereich) mit eingelesen, die Disassemblerausgabe 
wird damit beschriftet. Als Nebeneffekt, kann man jetzt auch in die 
Eingabefelder für PC und Breakpoint einen Funktionsnamen eingeben, damit 
entfällt z.B. auch die Suche nach der Adresse von "main". Mit Symbolen 
für den Datenbereich tu ich mich noch etwas schwer, zumal der GCC 
ohnehin versucht, so Viel wie möglich in den Registern zu halten. Hier 
sollte man sich mal die Disassemblerausgabe anschauen, wo die Daten 
abgelegt werden.
mfG

von Michael B. (mb_)


Bewertung
1 lesenswert
nicht lesenswert
Das ist ein recht interessantes Projekt.

Vor vielen Jahren habe ich auch mal einen AVR emulator angefangen, der 
grundsätzlich auch funktioniert. Die Emulation ist recht schnell, weil 
in der CPU Optimierungen wie Lazy-Flags verwendet werden. (Das ist, wenn 
die CPU-Flags werden erst berechnet, wenn sie benötigt werden und nicht 
bei jeder Instruktion).

Irgendwann habe ich dann aber das Interesse verloren.
Vielleicht ist der Code dennoch nützlich für dich.
Ich habe ihn mal hier hochgeladen:
https://bues.ch/cgit/avremu.git/

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Wie ich sehe gehts vorran und nun willste doch was mit dem GDB machen ;)
Auch wenns die andere Richtung ist.

Über TCP quatscht der GDB genauso wie über die Serielle Schnittstelle.
Schnödes ASCII nach altem Protokoll.
Es gibt zwar nen Binary Protokoll, aber das hab ich auch nicht 
implementiert.
Hier gibts Infos zur PingPong Kommunikation:
http://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html
Hier kannste gucken welche Befehle es gibt und was diese bewirken:
https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html#Remote-Protocol

Viele Debugger haben eine Option "jump to main", dann landet man dort 
immer ohne init durchklicken oder manuell nen FUnktionsbreakpoint zu 
setzen.
Nur so als Option für Faule.

Falls du willst kann ich dir ja mal von meinem MIPS Sim den GDB Teil 
zukommen lassen.

von R. M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> Vielleicht ist der Code dennoch nützlich für dich.
> Ich habe ihn mal hier hochgeladen:
> https://bues.ch/cgit/avremu.git/

Hallo Michael,
Danke schon mal, für den Einblick, sieht etwas professioneller aus, als 
mein Stückwerk, ist aber anscheinend auf ähnlichem Stand: CPU wird 
emuliert, Periperie noch nicht, hab aber nur mal kurz überflogen, werd 
mir aber noch mal mehr Zeit nehmen.

Mw E. schrieb:
> Viele Debugger haben eine Option "jump to main", dann landet man dort
> immer ohne init durchklicken oder manuell nen FUnktionsbreakpoint zu
> setzen.
> Nur so als Option für Faule.

Das ist auch eine Sache, die wenig Aufwand in der Umsetzung machen 
dürfte.
Mal sehen, vielleicht komme ich noch dieses WE dazu.
Die GDB-Sachen setzen doch etwas mehr Lesen und Verstehen voraus, da 
kann ich noch nichts versprechen.
mfG

von Uwe S. (steinm)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe es mal unter Linux probiert und gleich bei der ersten elf-Datei ein 
segm fault bekommen, weil in elf.c:159 ein Speicherbereich freigeben 
wurde (free(stabstr);), der wohl zuvor nicht allociert wurde.

Wenn man als PC einen nicht existierenden Symbolnamen eingibt, dann 
kommt es auch zum Absturz. Diesmal in
refresh () at avrsim.cpp:120
 bei dem sprintf()

  Uwe

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hat etwas länger gedauert als geplant, hatte am Wochenende noch eine 
andere Baustelle und wollte auch vorher noch die, durch Uwe gemeldeten 
Fehler (Danke für den aussagekräftigen Bericht) korrigieren.
- Laden von "ELF"s sollte jetzt auch funktionieren, wenn keine 
"stabstr"-Tabelle drin ist;
- bei Eingabe ungültiger Symbolnamen / nicht als HEX lesbarer Werte in 
PC und Haltepunkt, kommt Fehlermeldung in Statuszeile, alter Wert wird 
nicht verändert;
- "goto main" ist auf der neuen Schaltfläche "m()";
mfG

von Uwe S. (steinm)


Bewertung
0 lesenswert
nicht lesenswert
Habe es nochmal ausprobiert. Die beschriebenen Abstürze sind weg, aber 
war es vorher nicht so, dass man bei der Eingabe eines Symbolnamens 
(oder auch eines hex-Werts) als PC im Disassembler an die entsprechende 
Stelle gesprungen ist? Man gibt also z.B. 'main<CR>' ein und sieht im 
Disassembler-Fenster dann den Assembler-Code. Egal was ich eingebe, es 
wird immer ab Adresse 0x0000 disassembliert.

Noch eine blöde Frage. Was muss ich den machen, um den Quellcode zu 
sehen?

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Uwe S. schrieb:
> Habe es nochmal ausprobiert. Die beschriebenen Abstürze sind weg, aber
> war es vorher nicht so, dass man bei der Eingabe eines Symbolnamens
> (oder auch eines hex-Werts) als PC im Disassembler an die entsprechende
> Stelle gesprungen ist?

Autsch - Rückgabewert auf Gültigkeit geprüft, dann aber doch eine 0 in 
den PC geschrieben, so geht es natürlich nicht - ist jetzt korrigiert 
(aber ohne linux-binary, hab hier gerade nur Windows zur verfügung).

> Man gibt also z.B. 'main<CR>' ein und sieht im
> Disassembler-Fenster dann den Assembler-Code. Egal was ich eingebe, es
> wird immer ab Adresse 0x0000 disassembliert.

sollte jetzt funktionieren, sollte man allerdings nur machen, wenn man 
nicht beabsichtigt, den Code auch auszuführen, weil damit die 
Initialisierungen (SP und so weiter) übersprungen werden. Dafür ist die 
neue Funktion "go to main" besser, damit wird die reguläre 
Initialisierung abgearbeitet, bis der PC auf "main" steht.

> Noch eine blöde Frage. Was muss ich den machen, um den Quellcode zu
> sehen?

Das Quellcodefenster wird mit "View->Source" ein/ausgeblendet, ob dort 
auch wirklich etwas angezeigt wird, hängt von den Debugging-Infos in der 
ELF-Datei ab, und ob sich die Quelldatei im gleichen Verzeichnis (oder 
im "Include-Path") befindet.

mfG

von Uwe S. (steinm)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Korrektur. Jetzt läuft es deutlich besser. Bei der letzten 
Fassung hatte ich auch sporadisch Abstürze, wenn die Emulation lief. Die 
sind jetzt weg.

Wie springe man denn im Disassembler an die Stelle im Code, an die auch 
"go to main" springt, ohne gleich die Emulation zu starten. Um einfach 
mal zu schauen, was der Compiler produziert hat.

Den Quellcode sehe ich auch, aber nur die Assembler-Teile meines 
Programms. Könnte man auch den C-Code passend anzeigen?

von R. M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uwe S. schrieb:
> Wie springe man denn im Disassembler an die Stelle im Code, an die auch
> "go to main" springt, ohne gleich die Emulation zu starten. Um einfach
> mal zu schauen, was der Compiler produziert hat.

Wie gesagt, um nur die Disassemblerausgabe anzuschauen, kannst Du in den 
PC eine Adresse oder einen Symbolnamen eingeben. Musst nur im 
Hintergrund behalten, das der restliche Prozessor dann nicht im Zustand 
ist, dort einfach "weiterzuarbeiten". Musst dann Funktionsaufrufe, 
Rücksprünge selbst im Hinterkopf behalten.
Wenn es um Disassemblierung eines ganzen Programmes geht, könnte ich 
noch mit einbauen, gibt aber auch z.B. schon fertige Lösungen für.
Risiko bei so etwas, sind immer Datenstrukturen im Flash, die den 
Disassembler durcheinander bringen.
Daher disassembliere ich auch immer nur die als Nächstes auszuführenden 
Befehle.
mfG

von Ingo W. (uebrig)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
In Beitrag "Schiebebefehl ATmega8 - mov Rd,Rr" ist ein 
Fehler im Befehl "mov Rd,Rs" festgestellt worden (Quelle und Ziel in der 
Simulation vertauscht). Im Anhang, die Korrektur.

von Andreas N. (nabi)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Ingo,

vielen Dank für die super schnelle Reaktion.

Danke.

von Kaj G. (Firma: RUB) (bloody)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Ingo,

Ich wollte den Simulator mal testen, und habe mir die Linuxversion
aus diesem Beitrag:
Beitrag "Re: AVR Simulator mit grafischer Benutzeroberfläche für Linux"
runtergeladen. Direkt beim starten stuertzt das
Programm mit einem SIGSEGV ab.

Was ich an Informationen geben kann:
Warnung beim Compilieren:
avrsim.cpp: In function 'MyTable* cr_tab(int, int, int, int, Fl_Double_Window**, int, int, const char*)':
avrsim.cpp:397:1: warning: no return statement in function returning non-void [-Wreturn-type]
 }
 ^

Das ist nicht gut, da die Funktion 3x aufgerufen wird:
ram_tab = cr_tab(20,20,380,400,&ram_win,DT_RAM,20,"RAM");
eeprom_tab = cr_tab(40,40,380,400,&eeprom_win,DT_EEPROM,20,"EEPROM");
flash_tab = (60,60,640,400,&flash_win,DT_FLASH,40,"FLASH");
MyTable *cr_tab(int x, int y, int w, int h, Fl_Double_Window **win, int kind,int col_width,const char *name){
  MyTable *r;
  *win=new Fl_Double_Window(x,y,w,h,name);
  r=new MyTable(0,0,w,h,kind,col_width);
  (*win)->end();
  (*win)->resizable(r);
  (*win)->show();
  (*win)->hide();
}
Wenn du hier noch ein 'return r;' einfuegst, funktioniert es. :)

Interessanterweise ist dieser Bug schon seit der Version vom 27.02.2017 
drin.
Beitrag "AVR Simulator mit grafischer Benutzeroberfläche für Linux"


Gruesse

von Ingo W. (uebrig)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Hallo Kaj,
danke für den Hinweis!
Peinlich, das mir dies bisher nicht aufgefallen ist, theoretisch hätte 
es garnicht funktionieren dürfen, den Compiler habe ich immer über das 
"fltk-config"-bash script aufgerufen, der hat mir keine Warnung 
geworfen.
Die (ausschliesslich) geänderte "avrsim.cpp" hab ich nochmal einzeln 
angehängt, dann brauchen die Linux-Nutzer nicht das ganze Quellarchiv 
runterladen.

von Kaj G. (Firma: RUB) (bloody)


Bewertung
0 lesenswert
nicht lesenswert
Ingo W. schrieb:
> Hallo Kaj,
> danke für den Hinweis!
Gerne :)

von Mutluit M. (mutluit)


Bewertung
0 lesenswert
nicht lesenswert
Hi Ingo,
ich wollte das mal unter Debian 8 (jessie) auf x86_64 ausprobieren, aber 
bekomme folgende Compile-Fehler:
$ diff OLD/fltk-config .
49c49
< OPTIM=" -O3 -Wall -Wunused -Wno-format-y2k  -fno-exceptions -fno-strict-aliasing -ffunction-sections -fdata-sections"
---
> OPTIM=" -O3 -Wall -Wextra -std=gnu++11 -Wunused -Wno-format-y2k  -fno-exceptions -fno-strict-aliasing -ffunction-sections -fdata-sections"

D.h. ich habe nur "-Wextra -std=gnu++11" hinzugefügt.

Die besagten Libs sind installiert:
# aptitude search libfltk1.3-dev libx11-dev
i   libfltk1.3-dev    - Fast Light Toolkit - development files
i A libx11-dev        - X11 client-side library (development headers)

$ ./c
ui.fl:2: unknown version '1.0303'
g++ -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -g -O2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -o 'avrsim' 'avrsim.cpp' -lfltk -lX11
avrsim.cpp:68:38: error: no matching function for call to ‘Fl_RGB_Image::Fl_RGB_Image(Fl_Pixmap*, int)’
 static Fl_RGB_Image img_icon(&p_sim,0);
                                      ^
avrsim.cpp:68:38: note: candidates are:
In file included from /usr/include/FL/Fl_Menu_Item.H:23:0,
                 from /usr/include/FL/Fl_Menu_.H:28,
                 from /usr/include/FL/Fl_Choice.H:25,
                 from /usr/include/FL/Fl_File_Chooser.H:29,
                 from avrsim.cpp:7:
/usr/include/FL/Fl_Image.H:204:3: note: Fl_RGB_Image::Fl_RGB_Image(const uchar*, int, int, int, int)
   Fl_RGB_Image(const uchar *bits, int W, int H, int D=3, int LD=0) :
   ^
/usr/include/FL/Fl_Image.H:204:3: note:   candidate expects 5 arguments, 2 provided
/usr/include/FL/Fl_Image.H:167:17: note: Fl_RGB_Image::Fl_RGB_Image(const Fl_RGB_Image&)
 class FL_EXPORT Fl_RGB_Image : public Fl_Image {
                 ^
/usr/include/FL/Fl_Image.H:167:17: note:   candidate expects 1 argument, 2 provided
avrsim.cpp: In function ‘int main(int, char**)’:
avrsim.cpp:441:16: error: ‘class Fl_Double_Window’ has no member named ‘default_icon’
  ui->main_win->default_icon(&img_icon);
                ^

von 2⁵ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> D.h. ich habe nur "-Wextra -std=gnu++11" hinzugefügt.

Habe ich auch gemacht und konnte den Quelltext src_20190427-1040.tar.gz 
problemlos unter Xubuntu 18.04 compilieren. Habe auch die fltk-1.3-dev 
installiert. Kann es sein, dass bei dir noch ein altes fltk rumspukt?
Starte doch mal auf in der shell fluid. Gehe auf help->About. Welche 
Version wird angezeigt?

von 2⁵ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Oder: fltk-config --version

von Mutluit M. (mutluit)


Bewertung
0 lesenswert
nicht lesenswert
2⁵ schrieb:
>> D.h. ich habe nur "-Wextra -std=gnu++11" hinzugefügt.
>
> Habe ich auch gemacht und konnte den Quelltext src_20190427-1040.tar.gz
> problemlos unter Xubuntu 18.04 compilieren. Habe auch die fltk-1.3-dev
> installiert. Kann es sein, dass bei dir noch ein altes fltk rumspukt?
> Starte doch mal auf in der shell fluid. Gehe auf help->About. Welche
> Version wird angezeigt?

fluid startet normal und im About wird Version 1.3.1 angezeigt

$ fltk-config --version
1.3.1


# dpkg -l | grep -i fltk
ii  fltk1.3-doc                1.3.2-6         all     Fast Light Toolkit - documentation
ii  libfltk-cairo1.3:amd64     1.3.2-6+b1      amd64   Fast Light Toolkit - Cairo rendering layer support
ii  libfltk-forms1.3:amd64     1.3.2-6+b1      amd64   Fast Light Toolkit - Forms compatibility layer support
ii  libfltk-gl1.3:amd64        1.3.2-6+b1      amd64   Fast Light Toolkit - OpenGL rendering support
ii  libfltk-images1.3:amd64    1.3.2-6+b1      amd64   Fast Light Toolkit - image loading support
ii  libfltk1.1:amd64           1.1.10-19+b1    amd64   Fast Light Toolkit - shared libraries
ii  libfltk1.3:amd64           1.3.2-6+b1      amd64   Fast Light Toolkit - main shared library
ii  libfltk1.3-dev             1.3.2-6+b1      amd64   Fast Light Toolkit - development files

Ist das eine zu alte Version?


Oder liegt es vlt. an der Compiler-Version?
$ g++ --version
g++ (Debian 4.9.2-10+deb8u2) 4.9.2

: Bearbeitet durch User
von Ingo W. (uebrig)


Bewertung
0 lesenswert
nicht lesenswert
Mutluit M. schrieb:
> $ ./c
> ui.fl:2: unknown version '1.0303'

Dieser Hinweis kommt aus dem Fluid (Präcompiler für die GUI-Ressourcen), 
den hatte ich je nach Umgebung auch schon, allerdings ohne Auswirkungen.


> 'avrsim' 'avrsim.cpp' -lfltk -lX11
> avrsim.cpp:68:38: error: no matching function for call to
> ‘Fl_RGB_Image::Fl_RGB_Image(Fl_Pixmap*, int)’
>  static Fl_RGB_Image img_icon(&p_sim,0);

Hier kennt die aktuelle FLTK-Bibliothek anscheinend die Funktion zum 
Zuweisen des Piktogrammes zum Hauptfenster nicht. Das diese für die 
Funktion des Programmes aber auch nicht zwingend erforderlich ist, kann 
man diese Quellkodezeilen auch auskommentieren, oder durch ein "#define 
WIN32 1" am Anfang des Quelltextes deaktivieren.
Unter Windows funktioniert diese Methode, einem Fenster ein Symbol 
zuzuweisen nämlich auch nicht.

von Mutluit M. (mutluit)


Bewertung
0 lesenswert
nicht lesenswert
Hab's jetzt kompilieren können! :-)

Musste dafür die beiden WIN32 ifdefs in avrsim.cpp deaktivieren (d.h. 
komplett auskommentieren).
Hab "WIN32" auch in fltk-config rausgenommen (bzw. diese Zeilen komplett 
auskommentiert).

: Bearbeitet durch User
von Mutluit M. (mutluit)


Bewertung
0 lesenswert
nicht lesenswert
Ingo W. schrieb:
> Mutluit M. schrieb:
>> $ ./c
>> ui.fl:2: unknown version '1.0303'
>
> Dieser Hinweis kommt aus dem Fluid (Präcompiler für die GUI-Ressourcen),
> den hatte ich je nach Umgebung auch schon, allerdings ohne Auswirkungen.
>
>
>> 'avrsim' 'avrsim.cpp' -lfltk -lX11
>> avrsim.cpp:68:38: error: no matching function for call to
>> ‘Fl_RGB_Image::Fl_RGB_Image(Fl_Pixmap*, int)’
>>  static Fl_RGB_Image img_icon(&p_sim,0);
>
> Hier kennt die aktuelle FLTK-Bibliothek anscheinend die Funktion zum
> Zuweisen des Piktogrammes zum Hauptfenster nicht. Das diese für die
> Funktion des Programmes aber auch nicht zwingend erforderlich ist, kann
> man diese Quellkodezeilen auch auskommentieren, oder durch ein "#define
> WIN32 1" am Anfang des Quelltextes deaktivieren.
> Unter Windows funktioniert diese Methode, einem Fenster ein Symbol
> zuzuweisen nämlich auch nicht.

Ja, wie in meinem vorigen Posting geschrieben, habe ich alle Vorkommen 
von WIN32 auskommentiert, und so hat's geklappt.
Ich nehme an, WIN32 in der fltk-config hat man wohl gebraucht wenn man 
unter Windows mit g++ kompiliert hat.

Aber egal, jetzt klappt's bei mir unter Linux.
Die nächste Frage wäre bezüglich Benutzung: ich habe z.B. ein 
LED-Blinkprogram in C für den Arduino UNO. Das hex-File davon konnte ich 
in avrsim laden und auch laufen lassen, jedoch läuft es Fullspeed. Wie 
kann ich da den Sourcecode anzeigen um so Breakpoints zu setzen?
Oder geht das nur mit dem Maschinen- bzw. Assemblercode?

: Bearbeitet durch User
von Mutluit M. (mutluit)


Bewertung
0 lesenswert
nicht lesenswert
Mutluit M. schrieb:
> Hab's jetzt kompilieren können! :-)
>
> Musste dafür die beiden WIN32 ifdefs in avrsim.cpp deaktivieren (d.h.
> komplett auskommentieren).

Korrektur: es sind ifndefs

> Hab "WIN32" auch in fltk-config rausgenommen (bzw. diese Zeilen komplett
> auskommentiert).

von 2⁵ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mutluit M. schrieb:
> fluid startet normal und im About wird Version 1.3.1 angezeigt
>
> $ fltk-config --version
> 1.3.1

Bei mir war's die 1.3.4. Evtl. lag es daran. Die WIN32 #defines habe ich 
nicht verändert.

von Mutluit M. (mutluit)


Bewertung
0 lesenswert
nicht lesenswert
2⁵ schrieb:
> Mutluit M. schrieb:
>> fluid startet normal und im About wird Version 1.3.1 angezeigt
>>
>> $ fltk-config --version
>> 1.3.1
>
> Bei mir war's die 1.3.4. Evtl. lag es daran. Die WIN32 #defines habe ich
> nicht verändert.

Also, irgendwas fehlt bei mir noch, weil das Source-Window leer ist 
(ganz weiss).

Wie ist denn das Koordinatensystem für die Windows hierbei: ist der 
Nullpunkt links unten oder links oben?

von Alexander S. (alesi)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nur zur Info: Bei mir unter Debian stretch (stable)
$ uname -a
Linux deb10 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64 GNU/Linux
$ fltk-config --version
1.3.4
$ g++ --version
g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
funktioniert das binary avrsim aus src_20190427-1040.tar.gz direkt,
d.h. ohne zu compilieren.
$ file avrsim
avrsim: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0 ...

von 2⁵ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mutluit M. schrieb:
> fluid startet normal und im About wird Version 1.3.1 angezeigt
>
> $ fltk-config --version
> 1.3.1

Hm... unabhängig davon, dass Debian jessie jetzt doch etwas älter ist, 
ist die Version von fltk-1.3 selbst für jessie zu alt:

Gugst du: https://packages.debian.org/search?keywords=fltk

Paket libfltk1.3-dev
jessie (oldstable) (libdevel): Fast Light Toolkit - development files
1.3.2-6+b1: amd64 armel armhf i386
stretch (stable) (libdevel): Fast Light Toolkit - development files
1.3.4-4: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x

D.h. die letzte Release für jessie war die 1.3.2, und nicht die 1.3.1
Hast du Probleme mit "sudo apt update; sudo apt dist-upgrade"?

von Mutluit M. (mutluit)


Bewertung
0 lesenswert
nicht lesenswert
2⁵ schrieb:
> Mutluit M. schrieb:
>> fluid startet normal und im About wird Version 1.3.1 angezeigt
>>
>> $ fltk-config --version
>> 1.3.1
>
> Hm... unabhängig davon, dass Debian jessie jetzt doch etwas älter ist,
> ist die Version von fltk-1.3 selbst für jessie zu alt:
>
> Gugst du: https://packages.debian.org/search?keywords=fltk
>
> Paket libfltk1.3-dev
> jessie (oldstable) (libdevel): Fast Light Toolkit - development files
> 1.3.2-6+b1: amd64 armel armhf i386
> stretch (stable) (libdevel): Fast Light Toolkit - development files
> 1.3.4-4: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
>
> D.h. die letzte Release für jessie war die 1.3.2, und nicht die 1.3.1
> Hast du Probleme mit "sudo apt update; sudo apt dist-upgrade"?

Ja, nach einem upgrade sind sie bei mir jetzt auch 1.3.2:
# dpkg -l | grep -i fltk
ii  fltk1.3-doc               1.3.2-6      all    Fast Light Toolkit - documentation
ii  libfltk-cairo1.3:amd64    1.3.2-6+b1   amd64  Fast Light Toolkit - Cairo rendering layer support
ii  libfltk-forms1.3:amd64    1.3.2-6+b1   amd64  Fast Light Toolkit - Forms compatibility layer support
ii  libfltk-gl1.3:amd64       1.3.2-6+b1   amd64  Fast Light Toolkit - OpenGL rendering support
ii  libfltk-images1.3:amd64   1.3.2-6+b1   amd64  Fast Light Toolkit - image loading support
ii  libfltk1.1:amd64          1.1.10-19+b1 amd64  Fast Light Toolkit - shared libraries
ii  libfltk1.3:amd64          1.3.2-6+b1   amd64  Fast Light Toolkit - main shared library
ii  libfltk1.3-dev            1.3.2-6+b1   amd64  Fast Light Toolkit - development files

Da ist noch eine uralte Version 1.1, muss noch checken von welchem 
Package dies noch gebraucht wird.

: Bearbeitet durch User
von Alexander H. (maystorm)


Bewertung
0 lesenswert
nicht lesenswert
Schönes Projekt! Sehr hilfreich für einen ATmegaXX-Anfänger. Daumen 
hoch!

von Thomas O. (kosmos)


Bewertung
0 lesenswert
nicht lesenswert
wäre es möglich das ganze für einen ARM zu kompilieren oder ist das nur 
für x86 möglich?

von Ingo W. (uebrig)


Bewertung
0 lesenswert
nicht lesenswert
Zummindest auf RasPi, unter RaspBian, hab ich ihn schon laufen lassen.
In diesem Falle, vor Ort kompiliert.

: Bearbeitet durch User
von Thomas O. (kosmos)


Bewertung
0 lesenswert
nicht lesenswert
@Ingo W.:

Kannst du mir erklären wie man soetwas neu kompiliert, denke das würde 
auch andere hier interessieren. Mit nen Raspberry Pi einen AVR Simulator 
nutzen zu können.

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Thomas O. schrieb:
> Mit nen Raspberry Pi einen AVR Simulator nutzen zu können.

Es wäre schön, wenn das ginge, aber die Performance des Raspi reicht 
wahrscheinlich bei weitem nicht aus, um eine einigermaßen akzeptabel 
schnelle Simulation damit hinzubekommen.

von Ingo W. (uebrig)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab es gerade auf dem Raspi noch einmal getestet.
Hier war das FLTK schon installiert, wo das noch nicht erfolgt ist, 
erfolgt das mit

sudo apt-get install libfltk1.3-dev

dann geht man in das  "src"-Verzeichnis und ruft mit

./c

das Shell-Script auf, in welchem die Kompilierung gestartet wird.
Auf meinem alten Raspi1B, hat das fast eine Minute gedauert.
Beim schrittweisen abarbeiten des Programms merkt man schon eine trägere 
Reaktion, als auf einem "großen". Offensichtlich erfordert die 
Aktualisierung der Anzeigen etwas Aufwand, der aber auch von der Anzahl 
und Größe der Fenster abhängig ist.
Wenn man die Simulation ohne Bildschirmaktualisierung laufen lässt (step 
over oder run), entspricht die Geschwindigkeit der Simulation bei mir 
etwa einem AVR mit 2MHz Taktfrequenz

von Ingo W. (uebrig)


Bewertung
0 lesenswert
nicht lesenswert
Thomas O. schrieb:
> @Ingo W.:
>
> Kannst du mir erklären wie man soetwas neu kompiliert, denke das würde
> auch andere hier interessieren. Mit nen Raspberry Pi einen AVR Simulator
> nutzen zu können.

Ja, ich werde die Anleitung in diese Richtung ergänzen, nachdem klar 
ist, dass es möglich und sinnvoll ist.

von Ingo W. (uebrig)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe im Abschnitt "Installation->Linux", die Erstellung auf dem RasPi 
mal etwas ausführlicher beschrieben. Die alte "iodefs", habe ich nochmal 
mit tar gepackt, damit sie, wie in der Anleitung, gleich ausgepackt 
werden kann.

von Alexander H. (maystorm)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Ingo,

habe ich das richtig verstanden, dass das Source-Fenster auch das 
originale C-Programm anzeigen kann, wenn die ELF-Datei aus C-Sources 
generiert wurde?

Was müsste ich beachten, damit das klappt?

Vielen Dank im Voraus!
Alexander

von Ingo W. (uebrig)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Alexander,
wenn die ELF-Datei, die entsprechenden Debug-Informationen enthält, kann 
der Simulator die entsprechende Quelldatei/Zeile laden/raussuchen. In 
dem Beispielarchiv von 
Beitrag "Re: AVR Simulator mit grafischer Benutzeroberfläche für Linux" ist ein 
GCC-Beispiel drin, mit dem ich das mal getestet hatte, im "c"-Script 
sind die passenden Kommandozeilenparameter für Compiler/Linkeraufruf. 
Gegebenenfalls kann man auch noch die Includeverzeichnisse mit angeben.
Ist aber schon ein Weilchen her, das ich das ausprobiert habe, für avr 
mache ich sonst überwiegend asm.

von Alexander H. (maystorm)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Ingo,

habe mir gleich mal die "avr-gcc_sample.zip" gezogen. In dem c-Skript 
werden leider nur *.S-Dateien kompiliert und gelinkt:
#!/bin/bash

# Assembling: main.S
avr-gcc -c -mmcu=atmega8 -I. -x assembler-with-cpp -Wa,-adhlns=main.lst,-gstabs  -DF_OSC=12000000 main.S -o main.o

# Assembling: tnarx.S
# avr-gcc -c -mmcu=atmega8 -I. -x assembler-with-cpp -Wa,-adhlns=tnarx.lst,-gstabs  -DF_OSC=12000000 tnarx.S -o tnarx.o

# Assembling: i2c.S
# avr-gcc -c -mmcu=atmega8 -I. -x assembler-with-cpp -Wa,-adhlns=i2c.lst,-gstabs  -DF_OSC=12000000 i2c.S -o i2c.o

# Linking: main.elf
avr-gcc -mmcu=atmega8 -I. -gdwarf-2   -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wa,-adhlns=main.o  -std=gnu99 -DF_OS
C=12000000 -MD -MP -MF .dep/main.elf.d main.o --output main.elf -Wl,-Map=main.map,--cref    -lm

# Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex

# Creating load file for EEPROM: main.eep
# avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex main.elf main.eep

# Creating Extended Listing: main.lss
# avr-objdump -h -S main.elf > main.lss

# Creating Symbol Table: main.sym
# avr-nm -n main.elf > main.sym

avr-size main.elf

Und mit Assembler-Dateien klappt die Source-File-Ausgabe.

Ich hab dann mal "make all" im gleichen Verzeichnis ausgeführt; damit 
wird offenbar die 'main.c' anstatt 'main.S' kompiliert und gelinkt. Aber 
dann bekomme ich auch leider nicht die C-Sourcedatei angezeigt.

von Alexander H. (maystorm)


Bewertung
0 lesenswert
nicht lesenswert
Doch, jetzt klappt's!!

von Ingo W. (uebrig)


Bewertung
0 lesenswert
nicht lesenswert
Alexander H. schrieb:
> Doch, jetzt klappt's!!

Bin auch gerade ins Zweifeln gekommen, weil schon zu lange her:
Während der ganzen Initialisierungen aus dem Laufzeitsystem, gibt es 
noch keinen Quelltext. Erst wenn main() in Sicht kommt. Wenn man die 
überspringen möchte, hilft der "m()"-Button.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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