Forum: Mikrocontroller und Digitale Elektronik Padauk Graphical User Interface


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tobias K. (tobias-k)


Angehängte Dateien:

Lesenswert?

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.

von Ralph S. (jjflash)


Lesenswert?

... nicht vergessen, welche Quelldateien oder "echte" Libraries hinzu zu 
linken sind.

von Tobias (Gast)


Lesenswert?

Was meinst du damit genau?
Ich habe Github bisher noch nie verwendet.

von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

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):
1
sdcc -c -mpdk14 -DPFS154 -DF_CPU=8000000 --std-sdcc11 --opt-code-size -I../include ntc_vers_02.c -o ntc_vers_02.rel
2
sdcc -c -mpdk14 -DPFS154 -DF_CPU=8000000 --std-sdcc11 --opt-code-size -I../include ../src/delay.c -o ../src/delay.rel
3
sdcc -c -mpdk14 -DPFS154 -DF_CPU=8000000 --std-sdcc11 --opt-code-size -I../include ../src/uart.c -o ../src/uart.rel
4
sdcc -c -mpdk14 -DPFS154 -DF_CPU=8000000 --std-sdcc11 --opt-code-size -I../include ../src/adc_pfs154.c -o ../src/adc_pfs154.rel
5
sdcc -c -mpdk14 -DPFS154 -DF_CPU=8000000 --std-sdcc11 --opt-code-size -I../include ../src/seg7mpx_dig2.c -o ../src/seg7mpx_dig2.rel

Hier sind dann alle Teile des Programms übersetzt und du mußt dann einen 
Linkerlauf starten (hier linkt SDCC das Gesamtprogramm):
1
sdcc -mpdk14 -I../include --out-fmt-ihx ntc_vers_02.rel ../src/delay.rel ../src/uart.rel ../src/adc_pfs154.rel ../src/seg7mpx_dig2.rel

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.

von Tobias (Gast)


Lesenswert?

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

von Ralph S. (jjflash)


Lesenswert?

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.

von Tobias (Gast)


Lesenswert?

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.

von Tommi (Gast)


Lesenswert?

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.

von Tobias (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Tobias (Gast)


Lesenswert?

Eine Komandizeile einzufügen wäre kein Problem. Die hätte dann halt nur 
nicht die autovervollständigung der richtigen Komandozeile

von Ralph S. (jjflash)


Lesenswert?

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

von Tobias (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Stefan ⛄ F. (stefanus)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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".

: Bearbeitet durch Moderator
Beitrag #6482854 wurde von einem Moderator gelöscht.
von Ralph S. (jjflash)


Lesenswert?

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ß.

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.