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.phphttps://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
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
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 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
>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.
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
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...
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 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:
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.
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
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 ?
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?
Da hier vor Kurzem nachgefragt wurde, Beitrag "UPDI software" hab ich schon einmal den AT-Tiny-214 in die Konfigurationsdatei eingepflegt. Da die neuen Tinys (dem ersten Eindruck nach) das gleiche Layout der Fuses haben, dürfte sich die Erweiterung auf andere Typen hoffentlich auf Copy&Paste konzentrieren - mal sehen....
