Announcement: there is an English version of this forum on 
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.
Angehängte Dateien:
-
Padauk_GUI_1.PNG
31,3 KB -
Padauk_GUI_2.PNG
29 KB
... nicht vergessen, welche Quelldateien oder "echte" Libraries hinzu zu linken sind.
Was meinst du damit genau? Ich habe Github bisher noch nie verwendet.
Angehängte Dateien:
-
pfside_screenshot.png
85,2 KB
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.
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.
Eine Komandizeile einzufügen wäre kein Problem. Die hätte dann halt nur nicht die autovervollständigung der richtigen Komandozeile
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".
:
Bearbeitet durch Moderator
Beitrag #6482854 wurde von einem Moderator gelöscht.
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ß.
Thread beobachten
Seitenaufteilung abschalten