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
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.
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
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
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.
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
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
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
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
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/
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.
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
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
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
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?
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
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?
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
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.
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:
1
avrsim.cpp: In function 'MyTable* cr_tab(int, int, int, int, Fl_Double_Window**, int, int, const char*)':
2
avrsim.cpp:397:1: warning: no return statement in function returning non-void [-Wreturn-type]
3
}
4
^
Das ist nicht gut, da die Funktion 3x aufgerufen wird:
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.
> 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?
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
1
ii fltk1.3-doc 1.3.2-6 all Fast Light Toolkit - documentation
2
ii libfltk-cairo1.3:amd64 1.3.2-6+b1 amd64 Fast Light Toolkit - Cairo rendering layer support
3
ii libfltk-forms1.3:amd64 1.3.2-6+b1 amd64 Fast Light Toolkit - Forms compatibility layer support
4
ii libfltk-gl1.3:amd64 1.3.2-6+b1 amd64 Fast Light Toolkit - OpenGL rendering support
5
ii libfltk-images1.3:amd64 1.3.2-6+b1 amd64 Fast Light Toolkit - image loading support
6
ii libfltk1.1:amd64 1.1.10-19+b1 amd64 Fast Light Toolkit - shared libraries
7
ii libfltk1.3:amd64 1.3.2-6+b1 amd64 Fast Light Toolkit - main shared library
8
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
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.
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).
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?
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).
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.
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?
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"?
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:
1
# dpkg -l | grep -i fltk
2
ii fltk1.3-doc 1.3.2-6 all Fast Light Toolkit - documentation
3
ii libfltk-cairo1.3:amd64 1.3.2-6+b1 amd64 Fast Light Toolkit - Cairo rendering layer support
4
ii libfltk-forms1.3:amd64 1.3.2-6+b1 amd64 Fast Light Toolkit - Forms compatibility layer support
5
ii libfltk-gl1.3:amd64 1.3.2-6+b1 amd64 Fast Light Toolkit - OpenGL rendering support
6
ii libfltk-images1.3:amd64 1.3.2-6+b1 amd64 Fast Light Toolkit - image loading support
7
ii libfltk1.1:amd64 1.1.10-19+b1 amd64 Fast Light Toolkit - shared libraries
8
ii libfltk1.3:amd64 1.3.2-6+b1 amd64 Fast Light Toolkit - main shared library
9
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.
@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.
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.
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
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.
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.
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
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.
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.
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.
Hallo,
auch wenn es hier seit ca. 3 Jahren keine Neuigkeitem mehr gab: Ich habe
gerade src_20190427-1040.tar.gz unter Debian 5.10.179-1 (2023-05-12)
x86_64 GNU/Linux compiliert und erhalte eine Warnung:
185|fl_alert("%s kann nicht geschrieben werden!",cp);
7
|~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
config.c um Zeile 185 sieht so aus:
1
char*cp;
2
intoffs;/* Höhe der Titelleiste */
3
cp=getConfigFileName();
4
if(!cp){
5
fl_alert("%s kann nicht geschrieben werden!",cp);
6
return;
7
}
Wenn cp Null ist macht die Ausgabe von cp doch auch keinen Sinn, weil cp
den Dateinamen nicht enthält? Ansonsten ist es glatt ohne weitere
Warnungen oder Fehler durchgelaufen.
Da fehlt tatsächlich eine Fehlerbehandlung.
bei mir im Arbeitsordner ist der Fehlerfall, dass "getConfigFileName()"
NULL zurückliefert, zummindest abgefangen.
1
voidwriteConfig(void){
2
FILE*f;
3
char*cp;
4
intoffs;/* Höhe der Titelleiste */
5
cp=getConfigFileName();
6
if(!cp)return;
7
f=fopen(cp,"w");
8
if(!f){
9
fl_alert("%s kann nicht geschrieben werden!",cp);
10
return;
11
}
in der readConfig, dito.
hier mal das aktuelle Quelltextarchiv.
Die fragliche Datei wurde am 11.11.2020 zuletzt geändert.
Ingo W. schrieb:> hier mal das aktuelle Quelltextarchiv.
Damit läuft es ohne Fehler oder Warnungen durch. Danke.
Gibt es die Dateien nur hier im Forum oder gibt es die noch auf einer
anderen Internetseite, z.B. git oder sourceforge?
Thread beobachten
Seitenaufteilung abschalten