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)
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.
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.
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.
> 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.
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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...)
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.
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.
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.
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...
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.
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.
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.
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.
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 …
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 :)
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.
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.
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?
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.
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.
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...
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.
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.
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)
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.
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten