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:
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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 …
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.
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?
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.
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.
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...
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.
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.
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.
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)
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.
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.
tuidude_screenshot.png
(54 KB)
tuidude_screenshot2.png
(65 KB)
