Forum: Projekte & Code tuidude - Textuserinterface für AVRDUDE unter Linux


von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

Nachdem ich mich in der jüngeren Zeit mit den "neueren" ATtinys Series-0 
und 1 beschäftige hab ich festgestellt, dass mein selbstgestricktes Tool 
zum Flashen und vor allen Dingen zum Setzen der Fuses für diese neue 
Generation nicht mehr ausreichend ist.

Also habe ich das erweitert und grundsätzlich mir gedacht, dass es 
eeeeventuell für andere die auch unter Linux werkeln, hilfreich sein 
kann.

Ich für mich verwende immer auch gerne die Linux-Konsole (und habe 
tatsächlich auch einen Linux-Rechner, auf dem kein Desktop installiert 
ist), möchte aber manchmal doch nicht auf "Fenstertechnik" verzichten 
und so bin ich seit anbeginn der Turbo Pascal 6.0 / Borland Pascal 7.0 
Zeiten von vor 30 Jahren ein Fan der TurboVision Libraries (unglaublich 
wie lange das her ist).

Unter Linux existiert der Free-Pascal Compiler, der das Fundament von 
Lazarus ist, und der eine portierte Version von Turbovision (von den 
Borland Produkten) mitbringt, die aber anscheinend niemand mehr nutzt, 
oder auch nie genutzt hat.

Ich persönlich arbeite sehr gerne damit, kann ich doch auf der Konsole 
ansatzweise einen ähnlichen Komfort bei Programmen haben, die ansonsten 
nur unter einem Desktop möglich sind. Außerdem sind die Programm 
gemessen an heutigen Desktopmonstern schön handlich klein.

TUIDUDE wird mit dem ersten Start im Homeverzeichnis in .config ein 
Unterverzeichnis namens tuidude_101.conf anlegen. Dort werden die 
Einstellungen der Dialogfenster von TUIDUDE gespeichert.

Natürlich hätte ich mein TUIDUDE auch als GUIDUDE unter Lazarus 
schreiben können, aber zum einen habe ich schon einige Projekte mit 
FreeVision realisiert, die dann eben nur entsprechend abgeändert / 
modifiziert werden müssen.

Das ist auch der Grund, warum das ganze in Pascal und nicht in C / C++ 
realisiert ist (auch wenn es die FreeVision als Libraries für GCC gibt).

Weitere Entscheidungen / Einschränkungen sind:

- FreeVision selbst baut auf NCurses auf und ist dieses nicht im 
Linuxsystem verfügbar funktioniert das Programm nicht. Ich weiße deshalb 
darauf hin, weil ein anderer User des Forums hier Probleme damit hatte, 
ein FreeVision Programm unter Linux zum Laufen zu bekommen, weil die 
Abhängigkeiten zu NCurses bei seinem Linux scheinbar nicht installiert 
waren. Ich hatte immer geglaubt, dass selbst bei sehr kleinen oder 
abgespeckten oder Livesystemen zumindes NCurses installiert ist.

Benötigt werden libreadline.so.6 und libtermcap.so.2 !
Sollte tuidude deswegen nicht gestartet werden, so müssen im 
Bibliothekenverzeichnis

/lib64
oder in
/usr/lib64

entsprechende Links erstellt werden. Allerdings ist das bisher bei den 
von mir weitergegebenen FreeVision Programmen erst einmal geschehen, 
dass das Programm wegen fehlender Libraries nicht gestartet werden 
konnte. Im Normalfall sollte das Programm "einfach" so starten

- TUIDUDE wurde mit FreePascal Version 2.6.4 kompiliert und ich weiß 
nicht, ob das ohne Änderungen mit der neueren Version 3.x übersetzt 
werden kann. Das liegt daran, dass ich mir die neuere Version nicht 
installieren mag, weil ich dann nicht weiß, ob meine Pascal und 
Lazarus-Projekte (die ich nur sporadisch verwende und anpasse) dann noch 
funktionieren. So lange also meine Programme so laufen wie sie sollen, 
lasse ich von einem neueren Compiler die Finger: Never touch a running 
system

--------------------------------------------------

Installation:

Eigentlich ist das Wort "Installation" viel zu Wortgewaltig, denn es 
bedarf lediglich ein kopieren der Datei tuidude in einen Ordner, der 
im Systemzugriff liegt, das heißt, von dem aus Programme automatisch 
gestartet werden können.

Bei mir ist das /usr/local/bin

TUIDUDE ist ene Oberfläche für AVRDUDE und erwartet von daher ein im 
Zugriff liegendes AVRDUDE. Bei mir ist es die Version 6.3 mit einem 
geänderten avrdude.conf.

Ein geändertes avrdude.conf ist dann notwendig, wenn man (wie ich) die 
tinyAVR(R)-Series 0/1 über einen jtag2updi Programmer flashen mag (der 
Grund, warum ich mein TUIDUDE überarbeitet hatte). Der jtag2updi 
Programmer ist nichts anderes als ein Arduino Uno / Nano + einem 4,7 
kOhm Widerstand + Firmware.

Die Firmware jtag2updi für Arduino Uno / Nano gibt es hier als 
hex-Datei:

https://github.com/ElTangas/jtag2updi/tree/master/build

:-) natürlich kann die jtag2updi Firmware selbst auf einen Arduino Uno / 
Nano mittels Tuidude geflasht werden.

Um bspw. einen Arduino Uno mit Bootloader (außerhalb der Arduino IDE) zu 
flashen sind bspw. folgende Einstellungen in der Programmer-Config zu 
machen:
1
- Programmer : Arduino - Bootloader
2
- Baudrate   : 115200 (für UNO)
3
                57600 (für Nano, wenn der Bootloader nicht geändert wurde)
4
- ISP - ClkSpeed : -B 1
5
- Port       : ttyUSBx  (für Arduino Clone mit CH340 Chip)
6
             : ttyACMx  (für originalen Arduino)

von Hopper (Gast)


Lesenswert?

Krassfett Retro, Mann!

So sah doch schon die TurboVision-Oberfläche von Borland aus - vor über 
dreißig Jahren.

Boah. Fett.

von vancouver (Gast)


Lesenswert?

Eines der Tools für die Kernelkonfiguration in Linux sieht heute noch so 
aus, ebenso das Konfigurationstool für Armbian. Und das die Idee ist 
garnicht schlecht. Diese Textgui läuft sogar über ein UART-Terminal, und 
kein Mensch braucht eine echte grafische GUI um ein paar Optionen 
anzuhäkeln. Um eine Schraube in die Wand zu drehen, braucht man keine 
Tunnelbohrmaschine

Ob ich dafür jetzt Lazarus verwenden würde... hm. Es gibt doch bestimmt 
auch für C oder Python eine Library für Textguis.

von Benedikt M. (bmuessig)


Lesenswert?

Schaut wirklich gut und nützlich aus

von Ralph S. (jjflash)


Lesenswert?

vancouver schrieb:
> Ob ich dafür jetzt Lazarus verwenden würde... hm. Es gibt doch bestimmt
> auch für C oder Python eine Library für Textguis.

Na ja, ich habe ja auch nicht Lazarus verwendet sondern Pascal. Für C++ 
gibt es diese FreeVision Library wie geschrieben ja auch, aber ich hatte 
einfach über die Jahre hinweg immer wieder mal diese TUI verwendet und 
somit war etwas neues aufzusetzen mit Pascal einfacher (zumal das 
Bestandteil von FreePascal ist), als mit C++.

Python, auch wenn das viele machen, mag ich nicht wirklich. Mich stört 
einfach das Trennen von Funktionsblöcken über deren Einrückungen mittels 
Whitespaces.

von vancouver (Gast)


Lesenswert?

Ralph S. schrieb:
> Mich stört
> einfach das Trennen von Funktionsblöcken über deren Einrückungen mittels
> Whitespaces.

Mich auch, aber vorsicht, mit dieser Aussage ziehst du den bösen Blick 
der Python-for-everything-Fraktion auf dich, und das kann ziemlich 
ausarten.

Abgesehen davon verwende ich Python u.a. gerne um kleine GUIs zu 
schreiben, meistens mit TkInter. Geht schnell und ist sogar optisch 
halbwegs ansprechend.

von Zeitle (Gast)


Lesenswert?

> Schaut wirklich gut und nützlich aus

Weder gut, noch nützlich. Warum? Fuses z. B. bestehen aus mehreren Bits. 
Es ist sehr einfach jedes einzelne Bit mit seiner Funktion und dem Wert 
anzuzeigen.

von Benedikt M. (bmuessig)


Lesenswert?

vancouver schrieb:
> kleine GUIs

Dafür ist C# einfach unschlagbar.

Zeitle schrieb:
> Weder gut, noch nützlich.
> Jedes [...] einzelne Bit mit seiner Funktion und dem Wert anzuzeigen.

Das ist hart. Ein solches Feature ließe sich problemlos nachrüsten.
Zudem kann man die Lock-/Fusebytes mit dem Datenblatt auch gut selbst im 
Kopf oder Binärmodus des Taschenrechners zusammenbauen.

von Ralf H. (hilti68)


Lesenswert?

Hallo Ralph,

sehr schön. Kann man das auch selbst testen? Oder bin ich nur blind und 
sehe die Sourcen/Downloadmöglichkeiten nicht?

Zu avrdude:
Ich verwende die Version 7.1, da sind schon alle neuen AVRs eingepflegt:

https://github.com/avrdudes/avrdude

Viele Grüße

Ralf

: Bearbeitet durch User
von Ralph S. (jjflash)


Lesenswert?

Zeitle schrieb:
> Es ist sehr einfach jedes einzelne Bit mit seiner Funktion und dem Wert
> anzuzeigen.

Dann mach mal !!!

Vor 3 oder 4 Jahren hatte ich versucht, anhand der "Partdescription 
Files" (sind XML Dateien) des Atmelstudios einen Fusecalculator wie der 
bekannte Online AVR(R) Fusecalculator

https://www.engbedded.com/fusecalc/

zu programmieren.

Die schiere Vielfalt und die doch oft vorhandenen Unterschiedlichkeiten 
der Bitpositionen, vor allem wenn man nicht nur die Bits bspw. CKSEL1 / 
CKSEL2 / CKSEL3 eines Atmega anzeigen möchte, sondern per Text anzeigen 
möchte dass:
1
CKSEL0 = 1
2
CKSEL1 = 0
3
CKSEL2 = 1
4
CKSEL3 = 1
5
6
der Einstellung:
7
Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 0 ms

entspricht.
Um das jetzt für jeden Verfügbaren AVR-Controller zu machen muß man nun 
die komplette Liste der XML-Dateien parsen, im Grunde genommen speziell 
einen XMl-Interpreter für diese Daten schreiben um diese dann TUIDUDE 
hinzuzufügen. Angefangen hatte ich damit, aber mir ist dann immer mehr 
die Lust darauf vergangen, weil:

- der Aufwand hierfür wurde deutlich größer als die der TUI
- mit dem Online Fusecalculator gibt es schon eine Möglichkeit sich 
genau die Hexwerte für die Bytes rechnen zu lassen (was meine Motivation 
dann gegen 0 tendieren lies). Es sollte ja nur eine einfache Möglichkeit 
geschaffen werden, nicht immer den Rattenschwanz von Parametern auf der 
Konsole eingeben zu müssen, die AVRDUDE verlangt.

Ein einfaches Dialogfeld, das nur die Namen der Bits der Fuses 
beschreibt war nicht sinnvoll, weil man nicht wirklich (also ich nicht) 
auswendig z.Bsp. welche Kombination der Bodlevel Bits benötigt wird um 
eine Brownout Detection von 2,7V an einem ATtiny2313 einzustellen!

Zudem verwende ich (und wahrscheinlich viele andere auch) immer wieder 
dieselben Chips mit denselben Fuseseinstellungen die man dann eben 
flasht (bspw. Fuseseinstellungen für einen Optiboot-Bootloader).

Angedacht habe ich, dass man vllt. eine Art Template hinzufügt mit einem 
Beschreibungstext und die Fuses Einstellungen für verschiedene 
Gegebenheiten dann abspeichern kann. Ob ich das allerdings realisiere 
weiß ich nicht, weil ich in meinen Projekten in aller Regel als 
Kommentar hinterlege, welche Fuses Einstellung  (als Hex-Byte Werte) zu 
machen sind.

Scheinbar sind die Fuseseinstellungen (kann ich nicht mit Bestimmtheit 
sagen) für die tinyAVR(R) 0/1-series besser in ihrer Durchgängigkeit und 
ein Bestimmen der Bedeutung ist einfacher zu bestimmen. Für die 
klassischen Controller ist das jedoch nicht so ganz so einfach und von 
daher einen großen Dank (unbekannterweiße) an  Dipl.-Ing. Mark 
Hämmerling der den Fusecalculator online gestellt hat.

von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

Ralf H. schrieb:
> Kann man das auch selbst testen? Oder bin ich nur blind und
> sehe die Sourcen/Downloadmöglichkeiten nicht?

Ich
...
bin
...
blind
...
und
...
blöde

... und alles gleichzeitig !

Ich habe schlicht vergessen die ZIP-Datei mit anzuhängen, was hiermit 
erfolgt (die Sourcen und ein Binary sind darin natürlich enthalten)

Ob in AVRDUDE 7.1 der jtag2updi Programmer mitenhalten ist, weiß ich 
nicht, aber das wirst du schon selbst wissen. Normalerweise sollte das 
auch mit Ver. 7.1 funktionieren, da TUIDUDE den AVRDUDE ja nur aufruft.

von Norbert (Gast)


Lesenswert?

vancouver schrieb:
> Ob ich dafür jetzt Lazarus verwenden würde... hm. Es gibt doch bestimmt
> auch für C oder Python eine Library für Textguis.

Die nennen wir seit gefühlt einem halben Jahrhundert ›curses‹ bzw. 
›ncurses‹

Für Assembler-Programmierer, für C-Programmierer, für C++-Programmierer, 
für Lua-Programmierer, für Python-Programmierer, für Ruby-Programmierer, 
für OCaml-Programmierer, für Perl-Programmierer
und bestimmt auch noch einen Sack voll Anderer.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Was ich mir (als Ko-Autor von AVRDUDE) wünschen würde: statt den 
…zigsten Wrapper um die AVRDUDE-Kommandozeile zu bauen, die nie dafür 
gedacht gewesen ist, dass das jemand maschinell bedient: endlich mal 
eine GUI/TUI, die die nun schon seit einiger Zeit existierende 
libavrdude als Backend benutzt.

Sicher ist mit der Trennun noch nicht alles ideal (es gibt bspw. immer 
noch Aufrufe nach exit() drin), aber es hätte einige Vorteile – und wäre 
endlich mal ein Anfang. Beispielsweise hat man dann die Möglichkeit 
eigener Callbacks für die Fortschrittsanzeigen.

von Ralph S. (jjflash)


Lesenswert?

Jörg W. schrieb:
> Was ich mir (als Ko-Autor von AVRDUDE) wünschen würde: statt den
> …zigsten Wrapper um die AVRDUDE-Kommandozeile zu bauen

Oha, ich hoffe ich habe dich nicht verärgert! Natürlich gibt es zig 
Wrapper und nur aus dem Grund, weil mir keiner gefallen hat und das aus 
dem Desktop heraus für mich mit Kanonen auf Spatzen geschossen ist habe 
ich für mich (auf Konsole eben) das geschrieben.

Jörg W. schrieb:
> die die nun schon seit einiger Zeit existierende
> libavrdude als Backend benutzt.

Puuh, das habe ich mir angesehen und ist eine Herausforderung (vor allem 
dann, wenn ich das in Pascal machen möchte). Ein Konsolenprogramm soll 
es bleiben und von daher denke ich da schon eher noch einmal über ein 
reines NCurses nach.

Jörg W. schrieb:
> Beispielsweise hat man dann die Möglichkeit
> eigener Callbacks für die Fortschrittsanzeigen.

Das bspw. wäre etwas, was mir gefallen würde !

--------------------------

Jörg W. schrieb:
> um die AVRDUDE-Kommandozeile zu bauen, die nie dafür
> gedacht gewesen ist, dass das jemand maschinell bedient

:-) deswegen wird sich wohl auch noch keiner um die libavrdude gekümmert 
haben, weil das einfach nur genial für ein Makefile ist ... und in aller 
Regel hierfür auch mehr als nur ausreichend.

--------------------------

An dieser Stelle ein Dankeschön an Dich, dass es den AVRDUDE gibt

von Ralph S. (jjflash)


Lesenswert?

Ralph S. schrieb:
> Puuh, das habe ich mir angesehen und ist eine Herausforderung (vor allem
> dann, wenn ich das in Pascal machen möchte).

Jetzt habe ich mir libavrdude.h mal genauer angesehen und für mich 
festgestellt, dass es (zumindest für mich) unmöglich ist, das nach 
Pascal zu portieren. Hier stellt man fest: Pascal und C vertragen sich 
einfach nicht wirklich gut.

Aber, das wäre jetzt einmal etwas "nettes", so als "Herausforderung", 
das ganze mit FreeVision für C++ zu machen ... und schwups stelle ich 
fest, dass es die FreeVision Bibliothek nur für 32-Bit gibt.

Jetzt müßte man die von Borland / Embacadero freigegebenen Quellen vom 
ehemaligen Borland C++ zum GCC portieren um dann auch eine TVision in 64 
Bit zu haben.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ralph S. schrieb:
> Hier stellt man fest: Pascal und C vertragen sich einfach nicht wirklich
> gut.

Was genau ist daran das Problem?

von Ralph S. (jjflash)


Lesenswert?

Jörg W. schrieb:
> Was genau ist daran das Problem?

Ich habe mir libavrdude.h angesehen ... und das ist hoch umfangreich. 
Erstens weiß ich nicht genau was für was ist und zum zweiten ist es nie 
lustig aus Pascal heraus ein Systemprozess zu kontrollieren (zumindest 
für mich nicht).

Hier sieht man bei mir dann doch, dass es einen großen Unterschied 
macht, ob man hauptamtlich Programmierer ist oder eben nicht.

:-) also das Problem hieran bin dann ich und die wenige Zeit die ich 
habe. Vllt. wenn ich irgendwann einmal in Rente gehen kann. Im Moment 
bin ich gerade wieder satt mit meinem eigentlichen Hobby (malen und 
zeichnen) satt am Zeit vertrödeln.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ralph S. schrieb:
> Jörg W. schrieb:
>> Was genau ist daran das Problem?
>
> Ich habe mir libavrdude.h angesehen ... und das ist hoch umfangreich.

Naja, gut, ist halt alles rausgezogen, was im AVRDUDE-CLI drin ist und 
irgendwie nach draußen exponiert sein musste.

> Erstens weiß ich nicht genau was für was ist

Dafür kann man einfach in main.c des CLI gucken.

Ansonsten findest du natürlich auf jeden Fall bei uns 
AVRDUDE-Entwicklern (sind mittlerweile einige dazu gekommen) Hilfe, wenn 
du welche brauchst.

> und zum zweiten ist es nie
> lustig aus Pascal heraus ein Systemprozess zu kontrollieren (zumindest
> für mich nicht).

Was ist denn für dich ein "Systemprozess"?

Für mich wäre genau das, was du (und andere) jetzt machen, das Steuern 
eines separaten Prozesses. Der Zugriff auf die einzelnen Funktionen der 
Lib dagegen integriert das Ganze in den eigenen Prozess.

von Ralph S. (jjflash)


Lesenswert?

Jörg W. schrieb:
> Dafür kann man einfach in main.c des CLI gucken.

Schmunzeln muss: Da bin ich gerade schwer am schauen (und ich hatte mir 
vor einiger Zeit das schon einmal angesehen gehabt).

Ich bin sehr am Versuch des Nachvollziehens, was da genau gemacht wird. 
Höchstwahrscheinlich werde ich die Finger davon lassen. Allerdings lerne 
ich immer wieder manche Dinge, wie man etwas besser als ich machen kann 
(und das sind im Falle von AVRDUDE eine Menge Sachen). In allem merkt 
man, dass das ein über Jahre gewachsenes Projekt ist.

Ich bin immer wieder erstaunt darüber, wieviel Hirnschmalz da drin 
steckt und - ohne Lobhudelei - einen riesen Respekt davor hab, was du 
und andere da bewerkstelligen.

von Wf88 (wf88)


Lesenswert?

vancouver schrieb:
> Eines der Tools für die Kernelkonfiguration in Linux sieht heute
> noch so aus

Das ist menuconfig undnutzt ncurses direkt. Komplett anders. sieht 
vielleicht ansatzweise ähnlich aus.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ralph S. schrieb:
> Ich bin immer wieder erstaunt darüber, wieviel Hirnschmalz da drin
> steckt

Ja klar, das ist wirklich über viele Jahre gewachsen.

Es genügt auch erstmal, das Grundgerippe zu erfassen und die diversen 
Sonderfälle (oftmals bestimmte Optionen der Kommandozeile) außer acht zu 
lassen.

Ich kann auch mal versuchen, einen groben Ablaufplan zu zeichnen.

von c-hater (Gast)


Lesenswert?

Jörg W. schrieb:

> Was ich mir (als Ko-Autor von AVRDUDE) wünschen würde: statt den
> …zigsten Wrapper um die AVRDUDE-Kommandozeile zu bauen, die nie dafür
> gedacht gewesen ist, dass das jemand maschinell bedient: endlich mal
> eine GUI/TUI, die die nun schon seit einiger Zeit existierende
> libavrdude als Backend benutzt.

Hmm. Sollte auf jeden Fall machbar ein. Und je weniger C-Schweinereien 
es enthält, desto einfacher läßt es sich in anderen Umgebungen nutzen. 
Ich habe es mir noch nicht angesehen. Für wie "schweinisch" würdest du 
denn das Interface halten?

Ich meine: Die Tatsache, dass es niemand nutzen mag, deutet wohl 
möglicherweise doch irgendwie dezent darauf hin, dass da einige Böcke 
lauern (die C-Programmierern garnicht als solche bewusst werden, die 
haben halt eine sehr eigene Sicht auf die Dinge...)

Beitrag #7350012 wurde von einem Moderator gelöscht.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Das Interface ist natürlich aus einem "gewachsenen" Programm heraus 
separiert worden, das ist kein irgendwie auch nur ansatzweise designtes 
API. Um die Trennung zu verbessern, wurden ein paar Änderungen eingebaut 
(wie die Fortschrittsanzeige als Callback oder das Message-System), aber 
bevor wir da Nerven haben, auch noch die letzten Unsauberkeiten 
aufzuräumen, müsste sich schon erstmal jemand finden, der das ernsthaft 
verwenden will. Solange das AVRDUDE-CLI der einzige Nutzer der 
Bibliothek ist, hat da niemand Lust, zu viel weitere Arbeit nur ins 
Aufräumen zu stecken.

von Norbert (Gast)


Lesenswert?

Danke für's löschen, Jörg!

von Norbert (Gast)


Lesenswert?

Was ist los Jörg? Außer dem unnötigen Löschen keine weitere 
Meinungsäußerung? Ein wenig enttäuschend!

von c-hater (Gast)


Lesenswert?

Jörg W. schrieb:

> Das Interface ist natürlich aus einem "gewachsenen" Programm heraus
> separiert worden, das ist kein irgendwie auch nur ansatzweise designtes
> API.

Ja, das merkt man. Ich hab's mir jetzt mal im Detail angeschaut.

Insbesondere diese Linked-List-Implementierung ist ja wohl mehr als 
"strange". Absolut beschissen und idiotisch gekapselt. Im Prinzip ist 
sie so fast nur aus C-Programmen heraus benutzbar. Da haben alle Macros 
rauszufliegen! Sowas kann man doch keinem ernsthaft anbieten.

Und da sie offensichtlich ziemlich zentral ist, wiegt das sehr schwer.

Es gäbe darüber hinaus natürlich noch einige weitere Punkte zu 
bemeckern, aber gegenüber dem oben genannten verblasst das alles völlig. 
Ist im Vergleich etwa Bypass-OP vs. Behandlung eines Mückenstichs.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

c-hater schrieb:
> Da haben alle Macros rauszufliegen!

Nö, mit so einem Befehlston gewiss nicht.

Wie geschrieben, sowie sich jemand ernsthaft aufmacht, das zu nutzen, 
wird er bei den aktuellen Maintainern (inklusive mir) die Hilfe 
bekommen, die er braucht.

Nur auf blauen Dunst hin lohnt es aber nicht, noch mehr Arbeit dahinein 
zu investieren.

von c-hater (Gast)


Lesenswert?

Jörg W. schrieb:

> Nö, mit so einem Befehlston gewiss nicht.

Mein Gott, ich will das nicht und ich brauch' das nicht. Von mir aus 
kann das problemlos alles so bleiben, wie es ist. Ich wollte nur 
aufzeigen, woran eine breite Nutzung bisher wohl gescheitert sein 
könnte...

Über deren (für dich wohl: "vollkommen unverständliches") Ausbleiben 
übrigens DU dich beschwert hast...

Für mich ist es hingegen vollkommen verständlich, dass das Interface 
Scheiße ist. Weil: ich mache auch andere Sachen als C...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

c-hater schrieb:
> Ich wollte nur aufzeigen, woran eine breite Nutzung bisher wohl
> gescheitert sein könnte...

Das ist in erster Linie daran gescheitert, dass es bislang noch nichtmal 
jemand in Erwägung gezogen hat. Stattdessen basteln sie alle um die 
existierende CLI herum – was technisch noch viel größerer M*** ist als 
das schlechteste Library-API.

von Smith (Gast)


Lesenswert?

Hopper schrieb:
> Krassfett Retro, Mann!
> So sah doch schon die TurboVision-Oberfläche von Borland aus - vor über
> dreißig Jahren.
> Boah. Fett.

Genau das hab ich auch gerade gedacht. Damals wäre das eine Sensation 
gewesen. Inzwischen wurden allerdings grafikfähige Displays erfunden. 
Aber die Ewiggestrigen werden wohl nie aussterben.

von Luigi de'Teobaldi (Gast)


Lesenswert?

c-hater schrieb:
> Für mich ist es hingegen vollkommen verständlich, dass das Interface
> Scheiße ist. Weil: ich mache auch andere Sachen als C...

Ich würds ja anders formulieren: Weil du C nicht kennst, nicht kennen 
willst, und nicht kennen kannst. Von irgendwas hast du zwar vielleicht 
auch Ahnung, aber das behältst du seit Jahren für Dich. Nur deine 
völlige Unfähigkeit, selbst elementares C zu kapieren, die bläst du in 
alle Welt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Luigi de'Teobaldi schrieb:
> Weil du C nicht kennst, nicht kennen willst, und nicht kennen kannst.

Denke ich nicht.

Ich stimme ja auch durchaus zu, dass das API da drin alles andere als 
irgendwie schön entworfen worden ist. Wenn Ralph sich aufraffen möchte, 
die Library als Backend zu benutzen, bin ich mir sicher, werden wir da 
auch einen Weg finden.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

c-hater schrieb:
> Da haben alle Macros rauszufliegen!

Habe gerade mal nachgeschaut: die werden eh nur innerhalb der Bibliothek 
benutzt (im avrdude.conf-Parser). Daran scheitert es also bestimmt 
nicht, die Bibliothek zu nutzen …

von loeti2 (Gast)


Lesenswert?

Smith schrieb:
> Genau das hab ich auch gerade gedacht. Damals wäre das eine Sensation
> gewesen. Inzwischen wurden allerdings grafikfähige Displays erfunden.
> Aber die Ewiggestrigen werden wohl nie aussterben.

Das ist Steampunk und cewl :)

von Benedikt M. (bmuessig)


Lesenswert?

Smith schrieb:
> Aber die Ewiggestrigen werden wohl nie aussterben.

Schaut doch gut aus, ist übersichtlich und portabel. Dazu noch im 
Gegensatz zu Electron-Apps sogar noch schnell und kompakt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Benedikt M. schrieb:
> im Gegensatz zu Electron-Apps

:-))

von Ralph S. (jjflash)


Lesenswert?

Jörg W. schrieb:
> Wenn Ralph sich aufraffen möchte,
> die Library als Backend zu benutzen

ich leß jetzt schon seit 2 Tagen so in etwa libavrdude und grundsätzlich 
Quellcode. Mit Pascal mag ich das ganz sicher nicht machen, mit Lazarus 
(was ja ein "Delphi" und ein erweitertes Pascal somit ist) mag ich das 
auch nicht machen. Außerdem bin ich ein Konsolenfreund und von daher 
hätte ich so etwas schon gerne auch wieder in TurboVision gemacht. Also 
habe ich jetzt 2 Kriegsschauplätze (und verzettele mich wie immer) mal 
wieder: Ich bin am portieren der TurboVision nach GCC. Hier gibt es zwar 
einen Port, aber der ist so satt auf 32-Bit ausgelegt, dass einiges 
einfach zu instabil ist.

:-) von daher bin ich mir wirklich "nicht sicher" ob ich die Library als 
Backend verwenden mag. Aber vielen vielen vielen Dank für die angebotene 
Hilfe sollte mich das zu arg "jucken" und ich das machen wollen.

von Chris (Gast)


Lesenswert?

Hehe, ich freu' mich auch über die Screenshots - fühle mich gleich 
wieder angenehm an meine Jugend mit DOS 5.0, dem mitgelieferten Basic 
und natürlich auch Pascal erinnert! g Mittlerweile habe ich eine 
berufliche softwaretechnische Reise über Embedded- und 
Systemprogrammierung hinter mir, aber habe das mittlerweile größtenteils 
an den Nagel gehängt.

Und: mich "juckt" irgendwie, dass ein Maintainer des heutzutage ziemlich 
wichtigen avrdude-Tools sich eine breitere Verwendung (und ggf. 
Verbesserung) seiner Library-Schnittstelle wünscht.


Folgendes klingt jetzt vielleicht etwas despektierlich, aber bitte fühlt 
euch nicht angegriffen. Mich interessiert wirklich: wozu braucht man 
(heutzutage) eine GUI für avrdude? Ist es nicht so, dass Leute entweder 
einfach die Arduino-IDE benutzen, oder sich ein eigenes Buildsystem 
zusammenbasteln, wofür ein Kommandozeilen-tool genau das richtige ist?

In welchen Fällen hat man kein mit Buildsystem aufgesetztes Projekt und 
würde avrdude so spontan oder auch immer mal wieder für viele immer 
unterschiedliche Tasks benutzen wollen, ohne sich kurz vorher nochmal 
die Kommandozeilenparameter raussuchen zu wollen?

von DerEinzigeBernd (Gast)


Lesenswert?

Ralph S. schrieb:
> Ich bin am portieren der TurboVision nach GCC. Hier gibt es zwar
> einen Port, aber der ist so satt auf 32-Bit ausgelegt, dass einiges
> einfach zu instabil ist.

Was spricht dagegen, Dein Programm als 32-Bit-Programm zu schreiben? Ist 
ja nicht so, daß das mit gigantischen Unmengen von Speicher hantieren 
müsste, und die üblichen x64-Systeme sind sehr wohl in der Lage, 
32-Bit-Programme auszuführen.

Ansonsten wurde die Alternative ncurses ja schon erwähnt, das ist 
vielleicht der zukunftsträchtigere Ansatz.

von c-hater (Gast)


Lesenswert?

Jörg W. schrieb:

> Habe gerade mal nachgeschaut: die werden eh nur innerhalb der Bibliothek
> benutzt (im avrdude.conf-Parser).

Wenn das so ist, warum stecken sie dann in einer API-Deklaration? 
Interna haben darin nichts zu suchen. So ein Ansatz ist sinnvoll und 
deswegen auch absolut üblich.

Wenn die Benutzbarkeit des API wirklich nicht daran hängt, dann sollte 
ja nach den Gesetzen der Logik kein Problem sein, den Kram in eine 
zusätzliche linkedlist.h (o.s.ä.) auszulagern. Dann kann der conf-Parser 
das importieren, wenn er es braucht, in der API-Deklaration taucht aber 
nix Verwirrendes und für den eigentlichen Zweck letztlich Unnötiges mehr 
auf.

Das zu realisieren, wäre ja nicht mal als Programmieren zu bezeichnen, 
sondern eigentlich nur reine Textverarbeitung mit cut & paste.

von c-hater (Gast)


Lesenswert?

Jörg W. schrieb:

> Das ist in erster Linie daran gescheitert, dass es bislang noch nichtmal
> jemand in Erwägung gezogen hat. Stattdessen basteln sie alle um die
> existierende CLI herum – was technisch noch viel größerer M*** ist als
> das schlechteste Library-API.

Da ist schon was dran. Auch ich benutze (beruflich) an etlichen Stellen 
avrdude. Und auch auch habe das über das CLI adaptiert. Das lag aber vor 
allem daran, dass ich damals nicht einmal wußte, dass es ein 
lib-Interface dafür gab. Und wenn ich es damals gewußt hätte, hätte ich 
wohl nach dem ersten Blick da rein auch wieder das CLI-Interface 
gewählt...

von c-hater (Gast)


Lesenswert?

DerEinzigeBernd schrieb:

> Was spricht dagegen, Dein Programm als 32-Bit-Programm zu schreiben? Ist
> ja nicht so, daß das mit gigantischen Unmengen von Speicher hantieren
> müsste, und die üblichen x64-Systeme sind sehr wohl in der Lage,
> 32-Bit-Programme auszuführen.

Noch...

Das wird aber enden. Und das wird diesmal voraussichtlich schneller 
gehen als damals bei dem 16Bit-Kram.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

c-hater schrieb:
>> Habe gerade mal nachgeschaut: die werden eh nur innerhalb der Bibliothek
>> benutzt (im avrdude.conf-Parser).
>
> Wenn das so ist, warum stecken sie dann in einer API-Deklaration?

Weil diese linked list halt von Anfang an mit dabei war und diese APIs 
deklariert hat. Die Implementierung hatte Brian Dean bereits vor AVRDUDE 
gemacht und dann einfach mitgenommen. Klar könnte man die schöner 
machen, aber ehrlich: am ehesten macht sie den AVRDUDE-Maintainern 
selbst noch zu schaffen, weil das Debuggen damit etwas umständlich ist 
(man braucht im GDB Typecasts, wenn man auf den Inhalt der Liste 
zugreifen will). Ansonsten: never change a running system.

Wenn du genau guckst, siehst du auch, dass die Makros eh nur 
"convenience" sind, um Zugriffe auf die eigentlichen exportierten 
Funktionen zu vereinfachen. Selbst, wenn das bisherige CLI-Frontend sie 
nehmen würde, könnte man die also für ein anderes Frontend auch 
ignorieren.

von Ralph S. (jjflash)


Lesenswert?

DerEinzigeBernd schrieb:
> und die üblichen x64-Systeme sind sehr wohl in der Lage,
> 32-Bit-Programme auszuführen.

Unter Linux benötigt es ein "zweigleisiges Librarysystem" bei dem sowohl 
32 und 64 Bit Libraries vorgehalten und installiert sein müssen und 
genau das mag ich aber eher vermeiden.

Chris schrieb:
> Folgendes klingt jetzt vielleicht etwas despektierlich, aber bitte fühlt
> euch nicht angegriffen. Mich interessiert wirklich: wozu braucht man
> (heutzutage) eine GUI für avrdude? Ist es nicht so, dass Leute entweder
> einfach die Arduino-IDE benutzen, oder sich ein eigenes Buildsystem
> zusammenbasteln, wofür ein Kommandozeilen-tool genau das richtige ist?

:-) es ist ja keine GUI sondern eine TUI für die Konsole ist. Deine 
Frage ist berechtigt wozu man das braucht, denn entweder macht man das 
in einer Arduino-IDE (ich nicht) oder eben in einem eigenen Buildsystem. 
Ich "brauche" es selten, immer dann, wenn ich einfach nur fertige 
HEX-Files auf einen Controller aufspielen will und nicht immer den 
(notwendigen) Rattenschwanz an Parametern für AVRDUDE mit eingeben mag. 
Außerdem habe ich einen Spaß daran, sehr kleine (bezogen auf die 
Speichergröße) Anwendungen zu schreiben, die eben mittels Dialogboxen 
mit dem Anwender kommunizieren. Für solch kleine Programme wie einen 
Wrapper für AVRDUDE ersehe ich keinen Sinn, ewig große Programme 
einzusetzen, die 1000 Abhängigkeiten haben und bei der ein Programmierer 
zeigt, dass er mit QT5 umgehen kann.

Ich "liebe" kleine, schlanke Programme (und eigentlich ist ein 
TurboVision Programm für mich auch schon nicht mehr wirklich klein und 
schlank)

von Chris (Gast)


Lesenswert?

Ralph S. schrieb:
> Ich "brauche" es selten, immer dann, wenn ich einfach nur fertige
> HEX-Files auf einen Controller aufspielen will und nicht immer den
> (notwendigen) Rattenschwanz an Parametern für AVRDUDE mit eingeben mag.

Okay, vielen Dank für die entspannte Rückmeldung. :)

Zwischendurch eingefallen ist mir auch noch ein Einsatz als 
Programmierhilfe für Kleinserien, d.h. mehrere Boards programmieren 
indem man immer nur umsteckt und eine Taste drückt. Das ggf. noch 
kombiniert mit "Schmankerln" wie z.B. einer automatisch hochzählenden 
Seriennummer, Datum/Zeit, oder auch ein paar Zufallsdaten an wählbaren 
Speicherpositionen.

Vermutlich müsste man sich mal von den bereits existierenden 
GUI-Wrappern inspirieren lassen.
https://www.mikrocontroller.net/articles/AVRDUDE#GUIs



> Außerdem habe ich einen Spaß daran, sehr kleine (bezogen auf die
> Speichergröße) Anwendungen zu schreiben, die eben mittels Dialogboxen
> mit dem Anwender kommunizieren. (...)

Hehe, ich dachte mir schon, dass "Ich will mal wieder was im 
TurboVision-Style machen!" auch eine kräftige Motivation dazu war. ;)

Der Trend zu aufgeblähten Apps mit unzähligen Abhängigkeiten gefällt 
mich auch nicht so gut. Wobei es natürlich trotzdem schon gut ist, das 
Rad nicht immer wieder neu erfinden zu müssen. Die richtige Mischung 
machts.

Bitte 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
Noch kein Account? Hier anmelden.