Hallo zusammen,
ich wurde ebenfalls vom Padauk Mini-Hype erfasst und ich baute mir den
"easy-pdk-programmer". Da mir die Bedienung über die Komandozeile auf
Dauer lästig wurde, habe ich eine kleine GUI für das easy-pdk-programmer
Programm und den SDC Compiler erstellt. Diese wollte ich kurz einmal
vorstellen.
Bisher umfasst es die Funktionen:
- Kompiliern von C Datein
- Ermittlung des Speicherverbrauchs des Programms
- Proben des uC
- Löschen des uC
- Flashen des uC
Dabei wird auf die bestehenden Programme "easypdkprog.exe" und
"sdcc.exe" zurückgegriffen. Der Pfad zu diesen, kann zu Beginn
individuell konfiguriert werden.
Derzeit stehen die uC 'PMS150C', 'PFS154' und 'PFS173' zur Auswahl,
jedoch wäre es kein Problem, es um weitere von beiden unterprogrammen
unterstüzte Controller zu erweitern.
Geplant ist jetzt noch eine dynamische Programmanpassung, mit der es
möglich sein soll, den Wert einer Konstanten mit jedem Flashzyklus zu
verändern. Soll soll zB. einfach eine Seriennr oder änliches in den uC
eingebracht werden können ohne jedes mal die Konstante anzupassen.
Bsp.:
#define ADRESSE_FUNK 0
In GUI eingestellt ADRESSE_FUNK bei jedem Flashen um 1 erhöhen
=> ADRESSE_FUNK 0 in uC1
ADRESSE_FUNK 1 in uC1
ADRESSE_FUNK 3 in uC1
...
Die Operationen'+', '-', '*' und '/' sollen so mit beliebigen Zahlen
möglich sein.
Weiter wäre es möglich auch noch das Lesen des uC mit der GUI zu
verknüpfen.
Ich möchte jetzt hier feststellen, inwiefern Interesse daran besteht,
da ich dann das Projekt evtl auf Github stelle.
Ich meinte nicht Github, ich meinte dein Programm!
Wenn du einen Compilerlauf startest, lt. deinem Screenshot mit "Build",
welche Optionen hat dein "Build" ?
Gibst du die Parameter aus deiner GUI mit? Hast du eine
Konfigurationsdatei für diesen Build?
Sagen wir, du hast C-Funktionen geschrieben, die du immer wieder mal
brauchen könntest, sagen wir UART-Funktionen. Die lagerst du im
Normalfall in eine uart.h und eine uart.c aus.
Wie sagst du deinem "Build", dass er diese Dateien mit einbinden soll
(hinzulinken)?
Im Normalfall wird das bei einem Buildvorgang dem Linker mitgeteilt (das
kann sdcc sein oder auch sdld), der dann alle übersetzten Programme
"zusammen bindet" und dadurch ein ausführbares Programm erstellt.
Puristen (nicht nur die, andere auch) verwenden hierfür gerne ein
Makefile oder lassen sich ein solchiges erstellen.
Ein Beispiel:
Du hast ein Programm (das die main enthält) namens ntc_vers_02.c und
dieses benötigt andere Dateien die eingebunden werden sollen: delay.c,
uart.c, adc_pfs154.c und seg7mpx_dig2.c
Alle Dateien müssen also zuerst zu einer Objektdatei übersetzt werden
(die für sich noch kein lauffähiges Programm darstellen), die bei SDCC
die Endung .rel haben (aus delay.c wird bspw. dann eine delay.rel
generiert):
Wenn deine GUI dieses nicht vorsieht (egal ob über eine
Konfigurationsdatei, ein Makefile oder durch zusammenführen) dann ist
das nicht so sonderlich brauchbar.
In dem Screenshot oben (aus meiner TUI) kannst du vllt. besser sehen was
ich meine, auch wenn dieser Screenshot beim Klicken auf Generate ein
Makefile für PFS erstellt... bei dir wäre das der Build-Button.
Dein Build-Button müßte dann zusätzlich neben den hinzu zu linkenden
Dateien auch noch das Hauptprogramm (welches die main enthält)
einbinden.
Bei mir wird "nur" ein Makefile erstellt, ein Ordner in dem das Projekt
abgelegt werden soll und ein Template, das zu bearbeiten ist.
Ach so, das war mir bisher gar nicht bewusst.
Mein Programm führt beim Build einfach nur
sdcc -c -mpdk14 -DPFS154 -program.c
aus. Ich verwende in meinen Padauk programmen aber auch header und da
gab es bisher keine probleme
Tobias schrieb:> aus. Ich verwende in meinen Padauk programmen aber auch header und da> gab es bisher keine probleme
Na ja, dann hast in deinen Header nur Definitionen und Makros oder (was
man nur in Ausnahmefällen tun sollte) auch Programmcode.
Programmcode gehört allerdings in eine C-Datei und NICHT in den Header
(gab es hier genügend Diskussionen, bspw. ob Konstante dort hin dürfen
oder nicht).
Ein Beispiel:
Du schreibst Funktionalität für den I2C Bus. Dort hast du dann so etwas
wie ein i2c_start, i2c_stop, i2c_write, i2c_read etc.
Dann hast du vllt. einen I2C-Baustein LM75 (Temperatur) und du schreibst
ein Softwaremodul dafür, das dann lm75.c benannt wird. Innerhalb dieser
Datei bindest du jetzt eben seinerseits die i2c.c ein, weil das die
Schnittstelle zu dem Baustein ist.
Dann hast du noch einen I2C-Portexpander pcf8574. Also schreibst du eine
pcf8574.c in der du wiederum i2c.c einbindest.
Würdest du die Funktionen (Programmcode) von i2c.c im Header ablegen,
würdest du die Funktionen 2 oder mehrfach einbinden und hättest zum
einen (wenn es funktionieren würde, was es nicht tut) Speicherplatz
verschwendet, zum anderen (was schlimmer ist) hättest du Funktionen mit
gleichem Namen 2 mal (oder mehr) eingebunden. Dein Compiler / Linker
wird meckern.
Natürlich kannst du auch ohne zusätzliche Bibliotheken und .c / .h
Softwaremodule Programme schreiben (und jeden Quellcode in die Datei
einfügen, die die main hat), aber ab einer bestimmten Größe wird das
unhandlich ...
----------------------------
Hm, nicht böse sein, aber du solltest noch einmal lesen, wie C
funktioniert (im speziellen compilieren / linken). Hier meine ich jetzt
nicht die Syntax von C, sondern das Zusammenspiel von Präprozessor,
Compiler und Linker.
Bevor du das nicht verinnerlicht hast, solltest du dich nicht an einer
GUI versuchen.
Na ja, ich weis, dass ich über die Hintergrundarbeiten in C nicht
besonders viel weis, also das genaue Zusammenspiel zwischen
Präprozessor, Compiler und Linker. Mein Ziel war fürs erste nur von der
Komandozeile weg zu kommen. Ich hatte nicht vor etwas IDE ähnliches zu
schreiben, va in Anbetracht der Situation, dass die Padauks eh nur für
kleinere Sachen da sind und von daher auch nicht so viele Funktionen
anfallen sollten, die man dann extern ablegt.
Das Kompilieren wuerde ich nicht in das Tool integrieren, sondern in der
IDE / im Editor durchfuehren. Normalerweise gibt es dort die
Moeglichkeit eine Kommandozeile abzulegen, die dann auf Knopfdruck bzw.
Tastenkombination aufgerufen wird.
Dann bliebe noch ein reines Flashtool, was mir ganz sinnvoll erscheint.
Mein Programm selber kompiliert ja auch nicht. Es greift nur auf sdcc zu
und schreibt für einen die Komandobefehle.
Ich würde das schon drin lassen, da sich so dann auch einfach die
Funktionalität integrieren lässt, die ich am Anfang des Artikels
erläutert hab. Also eine dynamische Konstantenenanpassung.
Es ist schließlich mit meinem Tool auch möglich, nur zu flashen.
Tommi schrieb:> Dann bliebe noch ein reines Flashtool, was mir ganz sinnvoll erscheint.
Sehe ich auch so.
Siehe AVRDUDE.
Es wäre halt hübsch, wenn man GUI und Kommandozeile nutzen kann, und
einem in der GUI gleich anzeigt, zu welcher Kommandozeile die gewählten
Optionen führen.
Dass es statt der HEX Datei auch eine einzelne c Datei annehmen kann und
die mit installierten sdccc gleich in die hex übersetzt, ist nett, aber
nicht lebenswichtig.
Sprich: wenn kein sdcc gefunden wird, geht es halt nicht, wäre
verschmerzbar.
Tobias schrieb:> Ich hatte nicht vor etwas IDE ähnliches zu> schreiben,
das ist auch absolut ne Menge Arbeit, von einem alleine schier nicht
schaffen (ich werkel an meiner IDE schon Jahre und immer fällt mir etwas
neues und anderes ein)
Tobias schrieb:> dass die Padauks eh nur für> kleinere Sachen da sind und von daher auch nicht so viele Funktionen> anfallen sollten
das würde ich so nicht unterschreiben: ein kleineres Projekt, oben hast
du die Compilerangaben für ein "Temperaturschätzometer" gesehen gehabt,
hat in sich auch schon etliche Funktionen (ich weiß nicht wieviele
insgesamt, ich habe sie nicht gezählt).
Nur weil der Flashspeicher und noch mehr der RAM-Speicher begrenzt ist,
heißt das nicht, dass nicht viele Funktionen anfallen. Ich würde sogar
sagen, dass in manchen Fällen sehr viele Funktionen anfallen, weil man
hier etwas aufteilt, das man zuvor als ganzes gelassen hat und dann
bisweilen eine Funktionalität mehrfach implementiert hat.
Tobias schrieb:> Na ja, ich weis, dass ich über die Hintergrundarbeiten in C nicht> besonders viel weis, also das genaue Zusammenspiel zwischen> Präprozessor, Compiler und Linker. Mein Ziel war fürs erste nur von der> Komandozeile weg zu kommen.
Ich würde an sich sagen: Gerade wenn man beim Zusammenspiel von
Compiler, Präprozessor und Linker noch nicht besonders viel weiß macht
es Sinn, sich mit der Komandozeile zu beschäftigen weil man dort besser
sieht, was vor sich geht.
MaWin schrieb:> Es wäre halt hübsch, wenn man GUI und Kommandozeile nutzen kann, und> einem in der GUI gleich anzeigt, zu welcher Kommandozeile die gewählten> Optionen führen.
Absolut richtig: die Kommandozeile um etwas in einer IDE oder im
Makefile zu integrieren, eine GUI wenn man nur ein bereits bestehendes
Hex-File flashen mag.
Tobias schrieb:> Mein Programm selber kompiliert ja auch nicht.
Doch ! Tust du wie man im zweiten Screenshot von dir sieht. Da
compilierst du eine Datei namens touch.c (und schreibst ja auch "file
succesfully compiled".
Tobias schrieb:> Es greift nur auf sdcc zu> und schreibt für einen die Komandobefehle.
Du kannst nicht auf den sdcc "zurückgreifen" ohne dass er etwas
kompiliert oder linkt. Selbst dann wenn keine Ausgabedatei generiert,
compiliert oder linkt sdcc. Genau das ist seine Aufgabe und etwas
anderes kann er nicht.
---------------------------------
: - ) ich lass dich mal werkeln. Du wirst noch viele Ideen mit deiner
GUI haben (und auch immer wieder viel verändern). Dann wirst du bei der
Verwendung feststellen, was sinnvoll ist, was nicht und was noch fehlt!
So ging und geht mir das auch immer.
Schön, dass du deinen Spaß daran hast und ich hoffe, du bleibst bei
deinem Kenntnisstand nicht stehen.
Vllt. zeigst du dann auch hier mal die Entwicklungsfortschritte.
Gruß,
Ralph
Ralph S. schrieb:> : - ) ich lass dich mal werkeln. Du wirst noch viele Ideen mit deiner> GUI haben (und auch immer wieder viel verändern). Dann wirst du bei der> Verwendung feststellen, was sinnvoll ist, was nicht und was noch fehlt!
Ja, vermutlich wird es so sein und das ganze entwickelt sich Stück für
Stück weiter.
Tobias schrieb:> Eine Komandizeile einzufügen wäre kein Problem. Die hätte dann> halt nur nicht die autovervollständigung der richtigen Komandozeile
Andersrum: das Programm (oder ein zusätzlich geschriebenes welches
denselben Kern verwendet) mit allen Parametern auch über die
Kommandozeile aufrufbar zu bekommen, z.B. aus einem makefile heraus oder
einem Editor als external tool, ohne GUI, eben wie avrdude.
Hast du dir offenbar nichtmal angesehen.
Ralph S. schrieb:> Screenshot oben (aus meiner TUI)
Oh, Turbo Vision. Damit begann meine berufliche Karriere. Das Konzept
gefiel mir, wurde aber rasch links und rechts von grafische Oberflächen
überholt.
Tobias schrieb:> Ja, vermutlich wird es so sein und das ganze entwickelt sich Stück für> Stück weiter.
Kleiner Exkurs:
Wenn ein Programm sich aus mehreren C-Files zusammensetzt, dann
geschieht die Übersetzung in mehreren Schritten.
Vereinfacht sieht das so aus:
1
cc -c a.c
2
cc -c b.c
3
cc a.o b.o -o pgm
Der Schalter -c besagt, dass der Source a.c zwar kompiliert, aber nicht
gelinkt werden soll. Dadurch wird in Schritt 1 die Objekt-Datei a.o
erzeugt. Schritt 2 erzeugt b.o.
Im letzten Schritt werden dann alle Objekt-Dateien zusammengelinkt und
das Executable/Binary namens "pgm" erzeugt. Der cc erkennt automatisch
an der Dateiendung ".o", dass hier gelinkt und nicht kompiliert werden
soll.
P.S.
Ja, ich weiß, dass man auch verkürzt
1
cc a.c b.c -o pgm
schreiben kann. Wenn aber nachher die GUI etwas schlauer ist und
erkennen kann, welche c-Datei neuer ist als die o-Datei und nur diese
neu übersetzt, geht das insgesamt wesentlich flotter. Übrigens arbeitet
nach diesem Prinzip auch das altbewährte "make".
Stefan ⛄ F. schrieb:> Oh, Turbo Vision. Damit begann meine berufliche Karriere. Das Konzept> gefiel mir, wurde aber rasch links und rechts von grafische Oberflächen> überholt.
Zur heutigen Zeit heißt das "Free Vision" und ist eine bearbeitete,
modifizierte und neu übersetzte Weiterentwicklung von Turbo Vison (wobei
"neu" extrem relativ ist, es wurde Ewigkeiten daran nichts gemacht und
am schlimmsten ist, dass Free Vision das Terminal von Turbo Vision nicht
hat).
Das ganze ist im FreePascal Paket enthalten und von daher mußte das eben
in FreePascal geschrieben werden. Es gibt zwar auch eine C-Version der
von ehemals Borland freigegebenen Turbo-Vision Bibliothek, aber die
bekomme ich nicht ohne großen Aufwand übersetzt.
Meine IDE ist vllt. zu 30% "meine" IDE, einen großen Teil habe ich der
FreePascal Textmode-IDE übernommen und einiges angepasst.
Der Vorteil war dann, dass ich hier den Editor nur bearbeiten mußte für
bspw. Syntaxhighlighting in C, Mikrosoft Kommandos - weil man die so
kennt - für Copy & Paste (STRG-C / STRG-V).
Die ganze IDE hat den Vorteil, dass sie extrem schnell ist, manche Dinge
zu Bearbeiten sogar leichter sind als bspw. bei Geany und sie läuft auf
den ältesten Gurken. Sogar auf einem Raspberry PI-Zero läuft das noch
richtig flott, so dass man auf dem Pi-Zero Programme auch für einen
STM32 bspw. entwickeln könnte.
Außerdem hat es den Vorteil, dass es (ich bin unter Linux) keine
dependencies gibt, es genügt das einfach irgendwo hin zu kopieren und es
funktioniert.
Im Normalfall habe ich so eine generelle IDE auf der Konsole (ich habe
sie CIDE getauft) und habe daraus eine spezielle Version für die Padauks
gemacht und meinen Free Vision Makefile Generator mit da integriert.
Normalerweise war das bei mir getrennt. In diesem Stil gibt es dann noch
ein Flashershield für Arduino-Uno, das ein paar PIC16F, AT89S52, AVR's
flashen kann, alles in dem FreeVision Stil.
Klappt absolut super, sodass ich damit wirklich auch entwickle.
Deswegen sitz ich auch hier und kämpfe verbissen mit ATmega328 um den zu
überreden, dass er PADAUK Controller zuverlässig (das ist das Stichwort)
flashen kann, damit ich mein Flashershield überarbeiten kann und der
dann eben auch PFS154 kann.
Ich mag dieses Turbo Vision / FreeVision bis heute. Es ist so herrlich
schön alles ohne Schnickschnack zu haben, nachdem eine Toolchain
eingerichtet ist und ein universeller Makefile-Rumpf erstellt ist kann
man super schnell damit anfangen zu werkeln.
Ich bin ja auch immer wieder am überlegen, das ganze nach Lazarus zu
portieren, aber dann benötigt es halt wirklich den Desktop und wirklich
wollen mag ich das nicht.
Und glaub mir: Unter Lazarus wäre das ganze einfacher, aus heutiger
Sicht ist die Object-Hierarchie von FreeVision schon sehr "begrenzt",
Lazarus würde da mehr Spielraum geben und allen das Designen der Fenster
wäre um ein vielfaches einfacher, weil es eben "visual" geschieht und
nicht jede Koordinate deiner Dialogs ausprobiert werden muß.
Hallo zusammen :)
Ich dachte, poste jetzt mal ein Update von meiner GUI. Ich habe mir eure
Bermerkungen zu den Quelldatein jetzt auch mit umgesetzt. Jetzt können
in das Project auch .c datein für ausgelagerte Funktionen mit angeben
werden. Zum Schluss wird dann alles gemeinsam compiliert.
Lasst mich gerne wissen, was ihr jetzt davon haltet und ob ihr noch
Anregungen für mich habt.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang