Announcement: there is an English version of this forum on 
Hallo zusammen! Bisher hab ich zum Einstellen der Fuses, gern den AVR-Burn-O-Mat genutzt: http://avr8-burn-o-mat.aaabbb.de/avr8_burn_o_mat_avrdude_gui_en.php https://www.mikrocontroller.net/articles/Burn-o-mat Dieses Projekt wird allerdings anscheinend vom Entwickler nicht mehr weiter verfolgt, hier im Forum wurde bereits von Teilnehmern die Konfig weiter gepflegt, allerdings funktioniert die Abbildung der Funktionen zu den Fuses nur mit hart kodierten Modellen, lediglich die BOD-Funktion lässt sich über die Konfig modellieren. Daher hab ich das Programm mal angefangen nachzubauen. Hier lässt sich für jeden Controller individuell die Bedeutung der Fuses zu den Funktionsgruppen abbilden. Habe dies in der Konfig bereits für den Mega8 und Mega48 getan. Wenn alles so passt, dann kopiere ich dieses Modell in alle Controller, die auf diese Modelle verweisen und lege die restlichen Modelle neu an. Das Programm ist in C/C++ geschrieben, nutzt FLTK und sollte unter Windows und Linux funktionieren. Im win32bin-Archiv befinden sich die erforderlichen MinGW-Dlls, im Source-Archiv, befinden sich die Scripte, mit welchen das Programm compiliert wurde. Selbst benutze ich Linux, hab das Programm aber erfolgreich unter WinXP und Win7/64 getestet. mfG
Angehängte Dateien:
Oh, das klingt gut! Beim AVR Dude muss man ja inzwischen auch schon an der Config spielen zB für den neusten Mega88. Aber wieso haste dann nicht den Burn-O-Mat Sourcecode weitergepflegt, sondern nachgebaut?
Der ist in Java geschrieben, da müsste ich mich erstmal reinarbeiten, außerdem ist er so schon schwerfällig genug... Ein Hinweis noch: Prio hat für mich bisher der Fuseeditor, die "banalen" Funktionen für Flash/EEPROM funktionieren zwar, aber man hat keine Fortschrittsanzeige, die Ausgabe vom AVRdude erscheint erst, wenn er fertig ist, also nicht ungeduldig werden! Vielleicht kriege ich es hin, die Ausgabe von stderr (dorthin schreibt dude nämlich auch die Gutmeldungen) in eine Pipe umzuleiten um sie so, unverzüglich zur Ausgabe zu bringen. Das Lesen/Schreiben der Fuses geht ja so schnell, das es dort nicht nötig ist. mfG
Hab jetzt die gängigsten Typen vervollständigt. Hoffentlich nicht allzuviele Fehler drin, mfG
So, die Ausgaben vom AVRDUDE werden jetzt life im Ausgabefenster angezeigt. In der aktuellen XML (in beiden Archiven enthalten) sind die aktuellen Käfer jetzt komplett. Sollte Korrektur/Erweiterungsbedarf bestehen, dann bitte melden! mfG
Einen Fehler hab ich noch gefunden: bei EEPROM-Operationen wurde fälschlicherweise der unter Flash eingetragene Dateiname genutzt. Ist jetzt korrigiert. Desweiteren hab ich den voreingestellten Wert für die Dropdown-Felder mit dem Dateiformat von auto auf intel-hex geändert, da ich hier Probleme mit dem avrdude bei Auslesen und auto-format habe. mfG
Hallo, an die Linux Experte, wie starte ich das Program?
Hallo Juan, erstmal muss das Programm compiliert werden, dazu benötigt wird der gcc (auf den meisten Linuxen schon vorhanden), und die FLTK-Bibliothek. Auf Debian/Ablegern, installiert man die mit sudo apt-get install libfltk1.3-dev sudo apt-get install libx11-dev in anderen Distributionen wird die Vorgehensweise ähnlich sein. jetzt im src-ordner das "c"-script ausführen ./c dann steht das Kompilat im gleichen Ordner und kann mit ./fuseedit gestartet werden. Wie man zum bequemen Start dann eine Desktopverknüpfung oder einen Startmenüeintrag anlegt, hängt von der Distribution ab. Im Archiv befindet sich bereits eine kompilierte Programmdatei von Ubuntu 16.04. Wer selbiges nutzt und sich das selbstkompilieren sparen möchte, kann die Libs aus dem Anhang auspacken und nach /usr/lib/x86_64-linux-gnu verschieben (root-rechte erforderlich), ich empfehle aber die erstere Vorgehensweise https://de.wikipedia.org/wiki/Fast_Light_Toolkit mfG Edit: da war was beim Kopieren verloren gegangen
Hab mal versucht, die noch fehlenden/unklaren Informationen zusammenzutragen/klären. mfG
>an die Linux Experte, wie starte ich das Program? >>erstmal muss das Programm compiliert werden, dazu benötigt wird der gcc Siehst Du, genau da liegt der Vorteil von Java: drauf klicken, läuft.
Hallo R.M. bin erst wieder dran. Vielen Dank für das pdf Dokument, sieht gut aus. Ich habe Arch Linux, habe fltk und libx11 installiert aber beim kompilieren kommt: _ fuseedit.cpp:2:19: schwerwiegender Fehler: Fl/Fl.H: Datei oder Verzeichnis nicht gefunden #include <Fl/Fl.H> Also irgendwie passt mit "Fast Light Toolkit" bei mir leider nicht. Das kompilierte Datei von dir startet ohne Probleme aber wenn ich die fuse lesen will (STK500 Seriell) kommt folgende Fehlermeldung: _ avrdude: ser_open(): can't open device "/dev/tty0": Permission denied --- tty0 habe ich in config.txt eingestellt. AVRDUDE funktioniert problemlos über Terminal.
tty0 ist sicherlich nicht deine serielle Schnittstelle. Die dürfte eher ttyS0 oder ttyUSB0 heißen.
titty schrieb: > tty0 ist sicherlich nicht deine serielle Schnittstelle. > Die dürfte eher ttyS0 oder ttyUSB0 heißen. Verdammt!!! Da hast vollkommen Recht, bei config.txt anpassen habe ich natürlich die "S" gelöscht Wenn es richtig macht dann funktioniert auch!
Danke titty für den Einwurf! Bin selbst in die Falle getappt, da ich hier keine "echten" seriellen Schnittstellen habe, tty0 gibt es zwar, gehört aber wohl zu den virtuellen Konsolen. Habe die Vorbefüllung der Dropdowns jetzt so korrigiert, das sie mit ttyS0 beginnen. mfG
R. M. schrieb: > Habe die Vorbefüllung der Dropdowns jetzt so korrigiert, das sie mit > ttyS0 beginnen. Jap! Passt vielen Dank!
Angehängte Dateien:
Hallo R.M. Tolles Projekt! Ich habe Dein Programm zunächst unter Windows erfolgreich getestet und dann auch wie beschrieben auf Linux Mint 18 kompiliert und erprobt - ohne Probleme. Wenn ich das Gleiche allerdings mit Linux Mint 17.1 (LTS bis 2019) mache, bekomme ich beim Kompilieren diverse Fehlermeldungen (s. Screenshot). Woran könnte das liegen? Die aktuellen Pakete sind installiert. MfG
Hallo Thomas, es gibt anscheinend doch zwischen den im Umlauf befindlichen 1.3er Versionen noch Unterschiede, einige unterstützen das Deaktivieren von Elementen, einige nicht. Auf meinem "Windows (MinGW)-FLTK" habe ich das gleiche Problem gehabt und dahingehend umschifft, das ich um die relevanten Stellen #ifndef WIN32 // hier der Code #endif gebaut habe. Es geht hier eigentlich nur um die "Kindersicherung", das Deaktivieren der Fusebits, die mit "mode=Expert" markiert sind. Ich überlege, dies komplett aus dem Code zu entfernen, weils ohnehin nichts bringt. Als schnelle Lösung, hab ich in der "fuseedit.cpp", nach der Zeile 37 (wo die Windows/Linux-spezifischen includes eingebunden wurden, eine Zeile mit #define WIN32 1 eingefügt, damit sind die fraglichen Stellen ausgeschlossen. Mal nachdenken, wie ich damit langfristig umgehe... mfG
Thomas N. schrieb: > Wenn ich das Gleiche allerdings > mit Linux Mint 17.1 (LTS bis 2019) mache, bekomme ich beim Kompilieren > diverse Fehlermeldungen Hallo, die gleiche Fehlermeldung erhalte ich mit Debian jessie (nicht weiter verwunderlich, da Mint ein Debian Derivat ist): $> uname -a Linux deb10 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux $> aptitude show libfltk1.3-dev Package: libfltk1.3-dev State: installed Automatically installed: no Version: 1.3.2-6+b1 Priority: optional Section: libdevel Maintainer: Aaron M. Ucko <ucko@debian.org> Architecture: amd64 Uncompressed Size: 3,849 k $> ./c dialogs.fld: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 'fuseedit' 'fuseedit.cpp' -lfltk -lX11 fuseedit.cpp: In function ‘void cb_expert(Fl_Widget*, void*)’: fuseedit.cpp:100:53: error: ‘class Fl_Check_Button’ has no member named ‘set_active’ if(check->value()) fuses[byte].fuseBit[bit].btn->set_active(); ^ fuseedit.cpp:101:73: error: ‘class Fl_Check_Button’ has no member named ‘clear_active’ else if(fuses[byte].fuseBit[bit].mode) fuses[byte].fuseBit[bit].btn->clear_active(); ^ fuseedit.cpp: In function ‘void cb_fuseEdit(Fl_Widget*, void*)’: fuseedit.cpp:207:58: error: ‘class Fl_Check_Button’ has no member named ‘clear_active’ if(fuses[c].fuseBit[b].mode) fuses[c].fuseBit[b].btn->clear_active(); ^
Kann es vielleicht sein, dass eure FLTK-Versionen einfach zu alt sind und diese Funktion daher noch nicht enthalten ist? Gerade bei Debian sind die Pakete ja oft schon gut abgehangen...
Angehängte Dateien:
Das vermute ich auch, aber wegen der Sache würde ich jetzt keine Handstände machen und an der Paketverwaltung vorbei neue Versionen installieren das ist es nicht wert. Habe das Deaktivieren von Checkboxen jetzt ganz rausgenommen und stattdessen die Beschreibung der markierten Bits mit einer Warnmeldung garniert. Die potentiell gefährliche RSTDISBL-Fuse, hab ich jetzt mit in die GUI-Gruppen aufgenommen, mit der Markierung der riskanten Einstellung. Das sollte das Risiko etwas verringern. mfG
titty schrieb: > Gerade bei Debian > sind die Pakete ja oft schon gut abgehangen... Das hat seinen Grund. Deshalb heisst jessie auch "stable", es gibt auch "testing" und "unstable", wobei letzteres nicht heisst, dass das System instabil läuft, sondern nur, dass sich die Programme und Bibliotheken noch recht häufig ändern. Mit dem fuseedit.cpp vom 02.08.2016 20:00 läuft es jetzt bei mir. Das "Fuses-Fenster" bekomme ich nur mit <Shift-Alt-C> wieder zu. Fehlt da ein <close> und/oder <ok> Knopf?
Alexander S. schrieb: > Fehlt da ein <close> und/oder <ok> Knopf? Hab ihn mal schnell nachgerüstet. Hab bisher immer das X aus dem Fenstermenü genutzt, kann mich aber erinnern, das ich auch schon mit Debian-Versionen zu tun hatte, die das nicht hatten. Heiko L. schrieb: > Kannst du das nicht in github einpflegen? Lese ich mich mal rein.
R. M. schrieb: > Hab bisher immer das X aus dem > Fenstermenü genutzt, kann mich aber erinnern, das ich auch schon mit > Debian-Versionen zu tun hatte, die das nicht hatten. Danke. Das ist schon ok so und hat weniger mit Debian als mit meinem minimalistischen window-manager zu tun. Im Vergleich zu KDE, Gnome oder auch Xfce sind ion, larswm, und wmii schon minimalistisch. Ich benutze momentan dwm. Zitat: In contrast to ion, larswm, and wmii, dwm is much smaller, faster and simpler. http://dwm.suckless.org/ Sorry, leicht off-topic. Zurück zu fuseedit :-)
Alexander S. schrieb: > Sorry, leicht off-topic. Nee, nicht offtopic. Gefällt mir ganz gut, nicht mit Kanonen auf Spatzen zu schießen. Daher hab ich ja auch FLTK genommen und nicht, wie sonst die Mehrheit QT. mfG und gute Nacht!
Hallo R.M. habe soeben Deine Version von 21 Uhr auf Mint 17.1 kompiliert & getestet - Problem gelöst, besten Dank. MfG Thomas
Angehängte Dateien:
-
Screenshot1.png
220 KB -
Screenshot2.png
180 KB -
Screenshot3.png
180 KB
Hallo allerseits, da mich das Arbeiten mit fltk/fluid interessierte, habe ich mal versucht ein ganz einfaches Linux Interface für den TL866 µC Programmer zu erstellen. Das geht auch soweit ganz gut - also das Auslesen und Flashen der Speicherbereiche funktioniert. An einer Stelle bin ich aber bisher nicht weiter gekommen: Und zwar sendet das zugrunde liegende Konsolenprogramm Escape-Sequenzen, die zur Darstellung im Terminal gedacht sind und dort auch funktionieren. Wenn ich wie im Programm von R.M. die Konsolenausgabe in das FLTK Multiline Fenster umleite, werden diese Steuerzeichen natürlich nicht interpretiert sondern einfach ausgegeben (siehe Screenshots). Meine Frage an die C++ Experten: Wie kann ich den Datenstrom vor der Weiterleitung an das Multiline Fenster filtern? MfG Thomas
Hallo Thomas, in diesem Falle, müsste man sich hier um die Interpretation der Steuerzeichen selbst kümmern. Die Anzahl ist ja überschaubar, bzw. man muss ja nur die interpretieren, welche von dem Programm auch wirklich genutzt werden. Hatte auch schon mal daran gedacht, mich an einem Terminalprogramm zu probieren, da besteht das Problem ja auch in der gleichen Form. Für das FLTK böte es sich hier an, eine neue Klasse aus Fl_Text_Display abzuleiten, welche die putchar()-Funktionalität bereitstellt. mfG Edit: es sieht so aus, als ob es überhaupt nur 2 Steuerzeichen gibt: ^M ist eigentlich der Wagenrücklauf unter Windows -> postioniere Cursor auf den Anfang der aktuellen Zeile, könntest du durch '\n' ersetzen, das gibt dann zwar eine neue Zeile, ist aber besser lesbar, ^[[ mit einigen, eventuell unsichtbaren Zeichen, dient oft der Positionierung auf eine bestimmte Cursorposition.
Hallo, ich hatte zuvor die Terminal-Ausgabe in eine Datei umgeleitet: Jede Zeile die dort den prozentualen Fortschritt der Funktion ausgibt, beginnt mit 0A 1B 5B bzw. <LF><Esc>[. Selbst der einfache Austausch eines dieser Zeichen gegen ein '\n' ist mir nicht gelungen. Die folgenden Versuche sind zwar syntaktisch richtig, führen aber zu dem gleichen Kauderwelsch bei der Ausgabe:
1 | if (st1[0] == '\027') st1[0] = '\n'; |
2 | output->insert(st1,1); |
oder
1 | if (strcmp(st1, "\10\27[") !=0) output->insert(st1,1); |
Vielleicht könntest Du mal ein paar Code-Zeilen posten, wie es Deiner Meinung nach gehen müsste. Danke Thomas
ESC [K löscht den Rest der Zeile Thomas N. schrieb: > if (st1[0] == '\027' Das funktioniert deswegen nicht, weil das eine Oktalzahl ist. Und deren Wert ist nicht 27dez, sondern 23dez. C kennt keine dezimalen Char-Konstanten. Auch \10 ist eine Oktalzahl, das ist 8dez. Du musst entweder \33 und \12 oder die Hexdarstellung \x1b bzw. \x0a verwenden, damit Dein Vergleich funktioniert.
:
Bearbeitet durch User
Angehängte Dateien:
-
Screenshot4.png
28 KB
Da hast Du natürlich recht - manchmal hat man halt ein Brett vorm Kopf. Das abgeänderte Programm sieht jetzt schon ganz gut aus, wenngleich ich nicht weiss, woher die ^M Zeichen kommen. Der Datenstrom enthält nämlich keinerlei Carriage Returns. - Thomas
^M ist 0x0D, nicht 0x0A. 0x0A ist linefeed, nicht carriage return
Angehängte Dateien:
Jetzt benötige ich nochmal den Rat der Linux Experten: Zwischenzeitlich habe ich das aktuelle Linux Mint 20 installiert und das entsprechende fltk / fluid aus der Paketverwaltung. Das Compiler Skript läuft ohne Fehler durch; es erzeugt allerdings jetzt eine Datei vom Typ "Gemeinsame Bibliothek", die sich per ./name aus dem Terminal auch starten lässt, aber kein direkt startbares Programm mehr. Vermutlich fehlt da noch ein weiterer Linker-Lauf bzw. Bibliotheks-Module? - Thomas
Thomas N. schrieb: > die sich per ./name aus dem Terminal auch starten lässt, > aber kein direkt startbares Programm mehr. Wenn es mit ./name startbar ist, ist es ein fertiggebautes Programm, und ich würde gucken, warum dein Dateimanager es falsch anzeigt.
Das Problem scheint wohl tiefer zu liegen. Beim Googeln bin ich auf folgenden Beitrag gestoßen: https://forum.ubuntuusers.de/topic/caja-will-keine-programme-ausfuehren/ Ganz unten heißt es dazu: "GCC creates a shared object instead of an executable binary Bei g++ heisst es dazu: -pie Produce a position independent executable on targets which support it. For predictable results, you must also specify the same set of options that were used to generate code (-fpie, -fPIE, or model suboptions) when you specify this option." Wenn ich diesen Schalter von Hand ergänze bekomme ich aber immer noch kein Binary.
Thomas N. schrieb: > Wenn ich diesen Schalter von Hand ergänze bekomme ich aber immer noch > kein Binary. passt halt nicht zu: Thomas N. schrieb: > es erzeugt allerdings jetzt eine Datei vom Typ "Gemeinsame > Bibliothek", die sich per ./name aus dem Terminal auch starten lässt → meine Interpretation ist weiterhin: Anzeigeproblem deines nicht näher genannten Filemanagers. Um Klarheit zu schaffen: was sagt ›file‹ zur betreffenden Datei?
Thomas N. schrieb: > Das Compiler Skript läuft ohne > Fehler durch; es erzeugt allerdings jetzt eine Datei vom Typ "Gemeinsame > Bibliothek", die sich per ./name aus dem Terminal auch starten lässt, > aber kein direkt startbares Programm mehr. Das ist dann aber schon ein funktionsfähiges Programm. Jack V. schrieb: > → meine Interpretation ist weiterhin: Anzeigeproblem deines nicht näher > genannten Filemanagers. Um Klarheit zu schaffen: was sagt ›file‹ zur > betreffenden Datei? Der Dateityp dürfte ELF sein, was sowohl Bibliotheken, als auch Programme beinhaltet. https://de.wikipedia.org/wiki/Executable_and_Linking_Format Wenn Thomas das Programm einfach über die Kommandozeile starten möchte, scheitert er wahrscheinlich daran, dass es nicht im Suchpfad steht. Das könnte man über ein shellscript in $HOME/bin oder über einen Starter in $HOME/.local/share/applications/ erledigen. Dann kann das Programm auch über die grafische Oberfläche gestartet werden. Hab mal meinen Starter angehängt, hier müssten noch die Pfade ins Programmverzeichnis und ggf zum Icon (bei mir von einem anderen Programm) angepasst werden. https://wiki.ubuntuusers.de/.desktop-Dateien/
Filemanager ist Caja 1.24.0 Ergebnis von >file< thomas@thomas-ESPRIMO-Mobile-V6535:~/Fluid_work$ file fuseedit fuseedit: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=5903c02d0488763cad1d0f1214f8e5e6c7739e29, for GNU/Linux 3.2.0, stripped thomas@thomas-ESPRIMO-Mobile-V6535:~/Fluid_work$ Mittlerweile bin ich aber schon einen kleinen Schritt weiter: Wenn ich die von der Compiler-Shell generierte Zeile zur Codeerzeugung kopiere und ganz am Anfang hinter g++ den Schalter -no-pie ergänze und das Kommando neu absetzte, erhalte ich das gewünschte Binärfile. Ergebnis von >file< dann: thomas@thomas-ESPRIMO-Mobile-V6535:~/Fluid_work$ file fuseedit fuseedit: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=846360367b273ae06fd3441c18ecc7d06156d6be, for GNU/Linux 3.2.0, with debug_info, not stripped thomas@thomas-ESPRIMO-Mobile-V6535:~/Fluid_work$ Also müsste man wohl eine entsprechende Änderung in der fltk-config vornehmen, nur wie ?
Angehängte Dateien:
Mit angepasster fltk-config wie im Screenshot dargestellt funktioniert es nun wie gewohnt. - Thomas
Ingo W. schrieb: > Der Dateityp dürfte ELF sein, was sowohl Bibliotheken, als auch > Programme beinhaltet. Es gibt aber halt ’nen Unterschied zwischen „shared object“ und „executable“, deswegen fragte ich die Ausgabe an. Meinem Verständnis nach sollte sich ein shared object nicht direkt ausführen lassen, deswegen meine Verwirrung, die eigentlich immer noch besteht: eigentlich sollte der Versuch des Ausführens einer Lib direkt in einem Segfault enden. Ingo W. schrieb: > Wenn Thomas das Programm einfach über die Kommandozeile starten möchte, > scheitert er wahrscheinlich daran, dass es nicht im Suchpfad steht. … war hier irrelevant, weil er’s mit relativer Pfadangabe aufgerufen hat: ./name Wie auch immer – gut, dass es gefixt ist. Wenn’s zu dem Programm irgendwo ’n Git-Repo gäbe, könnte man’s dort einbringen – ob R.M. hier noch mitliest?
Beitrag #6353607 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.