Ist es möglich, dass ein C-Programm (Visual C) zur Laufzeit eine weitere C-Datei mit Daten einbindet? Hintergrund: Ich programmiere ein Tool, welches Fontdateien in ein Format wandelt, das anschließend von meiner GLCD-Library auf einem ATmega verwendet werden kann. Es gibt aber mehrere Font-Dateien, die jeweils als C-Code vorliegen. Zur Laufzeit möchte ich nun eine dieser C-Dateien zur Verarbeitung auswählen können. Momentan ändere ich den Code meines Konverters und schreibe die jeweilige Font-Datei direkt in den Quellcode. Das funktioniert, ist aber eher unpraktisch. Mit der Forensuche habe ich ältere Threads gefunden, die das Thema behandeln. Leider geht es immer um C++. Da ich vor zwei Monaten meine erste Zeile C Code geschrieben habe, hilft mir das leider nicht weiter. Bis auf Weiteres reicht mir C vollkommen, C++ ist erstmal kein Thema. Die Font-Dateien werden von diesem Programm erzeugt: https://www.riuson.com/lcd-image-converter
Zur Compile-Zeit geht das. Könntest ggf über die MakeFiles steuern.
Erwin E. schrieb: > Tool, welches Fontdateien in ein > Format wandelt, das anschließend von meiner GLCD-Library auf einem > ATmega verwendet werden kann. Es gibt aber mehrere Font-Dateien, die > jeweils als C-Code vorliegen. Zur Laufzeit möchte ich nun eine dieser > C-Dateien zur Verarbeitung auswählen können Pointer?
Theoretisch ist es möglich zur Laufzeit eines C-Programmes ein weiteres C-Programm im Quellcode einzulesen, es zu interpretieren oder auch zu kompilieren und es auszführen resp. auf die darin enthaltenen Variablen zuzugreifen. Praktisch bedeutet das, einen Compiler oder Interpreter für C zu schreiben. Ausserdem muss man einen Loader dafür schreiben, denn Anwendungen ist, aus Sicherheitsgründen, auf modernen Betriebssystem nicht gestattet ihren eigenen Code zu modifizieren. Das erfordert auch Administratoren-Rechte, was eigentlich eher nicht zu empfehlen ist. Das Ganze ist in jedem Fall so aufwendig und erfordert soviel Wissen und Erfahrung, jedenfalls mehr, als man sich in 2 Monaten erwerben kann, dass sich eine andere Alternative eventuell zu erwägen lohnt. Der Quellcode des von Dir verwendeten Image-Converters ist lt. der Webseite offen. Es wäre also möglich, den Quellcode so zu verändern resp. zu erweitern, dass er als Ausgabe anstatt des Quellcodes, den Du erst noch umwandeln musst, gleich den passenden Code ausgibt. Das ist im Vergleich wesentlich weniger aufwendig und entspricht in etwa dem Aufwand, den Du schon für Deinen eigenen Konverter hattest und vor allem dem Wissen, das Du dafür brauchtest. Vermutlich kannst Du sogar Teile Deines eigenen Konverters dafür verwenden.
Theor schrieb: > Theoretisch ist es möglich zur Laufzeit eines C-Programmes ein weiteres > C-Programm im Quellcode einzulesen, es zu interpretieren oder auch zu > kompilieren und es auszführen resp. auf die darin enthaltenen Variablen > zuzugreifen. Ein Interpreter für C (und C++) wäre z.B. cling. Den kann man auch recht einfach in eigene Programme integrieren. https://cdn.rawgit.com/root-project/cling/master/www/index.html Es sollte sogar gehen, das komplette Programm in cling interpretiert laufen zu lassen. Ist allerdings alles etwas overkill, um eine als C-Code erzeugte Fontdatei einzulesen. Dafür sollte ja nur ein extrem reduziertes Subset von C nötig sein. > Praktisch bedeutet das, einen Compiler oder Interpreter für C zu > schreiben. Ausserdem muss man einen Loader dafür schreiben, denn > Anwendungen ist, aus Sicherheitsgründen, auf modernen Betriebssystem > nicht gestattet ihren eigenen Code zu modifizieren. Wie macht das dann ein JIT-Compiler?
:
Bearbeitet durch User
Hat Dein Programm eine Bedienoberfläche? Wenn ja, dann verwende alle fontdateien unter verschiedenen Namen und lass den Benutzer eine aussuchen. Wenn nein, ist dein Weg ok. Sorge nur dafür, dass builden schnell geht (makefile) und gut. Oder lass per Script für jeden Font ein eigenes Programm erzeugen. Also kopieren des ersten fonts zu font.c und dann make, danach die exe umbenennen gemäß dem fontnamen. Dann zweiten font kopieren zu font.c,...
Die Fontbeschreibung, auch wenn als C-Code vorliegend, umfassen bestimmt ausschliesslich Daten und keine Instruktionen. Also liegt der einfache Fall vor, dass zur Laufzeit nur (dynamische) Datenstrukturen gemäss Benutzerauswahl zu befüllen sind. Die Übung besteht also darin, die C-Quellcode-Fontdaten in ein anderes Format zu überführen, dass sich einfacher vom endgültigen Programm einlesen lässt. NB: niemand käme auf die Idee, z.B. ein Bücherverwaltungsprogramm so zu schreiben dass die Bücherdaten als Quellcode eingebunden wären...
Ben S. schrieb: > Sowas nennt man DLL Auf einem ATmega? Da sind mal wieder echte Helden unterwegs. Programmiersprachentheaterintendant schrieb: > Die Fontbeschreibung, auch wenn als C-Code vorliegend, umfassen > bestimmt ausschliesslich Daten und keine Instruktionen. Ja, wie man leicht durch Verfolgen des angegebenen Links feststellen kann. > Also liegt der einfache Fall vor, dass zur Laufzeit nur (dynamische) > Datenstrukturen gemäss Benutzerauswahl zu befüllen sind. Was habt ihr alle mit dem dynamischen Scheißdreck? A-T-M-E-G-A! Mikrocontroller ... verstanden? > Die Übung besteht also darin, die C-Quellcode-Fontdaten in ein anderes > Format zu überführen, dass sich einfacher vom endgültigen Programm > einlesen lässt. Nein, die Übung besteht darin mehrere der Font-Dateien in den Code zu kompilieren und zur Laufzeit durch einen noch zu wählenden Mechanismus (zum Beispiel einen Pointer auf die Datenstruktur), den gewünschten Font auszuwählen. Wenn man sie zusammen kompiliert müssen die die Datenstrukturen in den Fonts nur unterschiedliche Namen haben. Für Bonuspunkte: Den generierten C-Code so modifizieren dass er ins EEPROM gepackt wird um Flash zu sparen.
Hannes J. schrieb: > Auf einem ATmega? Da sind mal wieder echte Helden unterwegs. Scheinbar schon. Ihnen ist zumindest aufgefallen dass der TO von einem "Tool" spricht. Hannes J. schrieb: > Was habt ihr alle mit dem dynamischen Scheißdreck? > A-T-M-E-G-A! Und das ganze in der Rubrik "PC-Programmierung" eröffnet wurde ;-)
Hannes J. schrieb: > Ben S. schrieb: >> Sowas nennt man DLL > > Auf einem ATmega? Nein, auf einem PC. Erwin E. schrieb: > Hintergrund: Ich programmiere ein Tool, welches Fontdateien in ein > Format wandelt, das anschließend von meiner GLCD-Library auf einem > ATmega verwendet werden kann. Dieses besagte Tool soll offenbar nicht auf dem ATmega laufen, sondern nur Code für den ATmega erzeugen. >> Also liegt der einfache Fall vor, dass zur Laufzeit nur (dynamische) >> Datenstrukturen gemäss Benutzerauswahl zu befüllen sind. > > Was habt ihr alle mit dem dynamischen Scheißdreck? > > A-T-M-E-G-A! > > Mikrocontroller ... verstanden? Ganz ruhig.
Hannes J. schrieb: > Auf einem ATmega? Da sind mal wieder echte Helden unterwegs. Nix Atmega. Forum: PC-Programmierung. Der Author sagt: Erwin E. schrieb: > Ist es möglich, dass ein C-Programm (Visual C) zur Laufzeit eine weitere > C-Datei mit Daten einbindet? Erwin E. schrieb: > Ich programmiere ein Tool, welches Fontdateien in ein > Format wandelt, das anschließend von meiner GLCD-Library auf einem > ATmega verwendet werden kann. Er redet von einem Tool, einem Konverter. Nirgends steht, dass er auf einem Atmega zur Laufzeit irgendwelche C-Dateien austauschen möchte. Also schließe ich daraus, dass er eine Desktopanwendung meint.
:
Bearbeitet durch User
Ben S. schrieb: > Sowas nennt man DLL War auch mein erster Gedanke als ich von dynamischem "hinzufügen" gelesen habe. Programmiersprachentheaterintendant schrieb: > umfassen bestimmt ausschliesslich Daten und keine Instruktionen So sehe ich es auch. Die Zeichen und evtl noch ein paar Einstellungen. Ich würde es wie viele andere Programme auch machen und eine x_language.xml dazu legen die das Programm einliest beim Startup oder falls eine GUI vorhanden ist auch noch nach dem ändern der Einstellung.
> von MaWin (Gast) 14.04.2020 00:36 Ein Beitrag des Psychopathen der seinen Namen nicht kennt und stattdessen MaWin ins Namensfeld schreibt um mir seine Schwachsinnsantwort in die Schuhe zu schieben. Erwin E. schrieb: > Ist es möglich, dass ein C-Programm (Visual C) zur Laufzeit eine weitere > C-Datei mit Daten einbindet? Nein. Erwin E. schrieb: > Hintergrund: Ich programmiere ein Tool, welches Fontdateien in ein > Format wandelt, Fontdaten haben einen Vorteil: es sind Fazen. Die müssen nicht kompiliert werden. Die müssen (zur Lazfzeit) nur eingelesen werden. Wenn also das Programm irgendwas in der Art char font[256][8]; enthält, schreibt man das so (uninitialisiert) ins Programm und lässt das Programm am Anfang diese Daten von einer externen Datei einlesen f=open(argv[1],O_RDONLY|O_BINARY); read(font,256*8,f); Am einfachsten geht das wie oben, wenn in der fontfile.bin nicht dein C code zur font Datenstruktur steht, in der Art char font[256][8]= { {0x00,0x01,0x02,... sondern die Binärdaten direkt. Da du die Datei ja per Programm erzeugst, sollte das die leichteste Übung sein
MaWin schrieb: > Anderer Gast missbraucht meinen Namen im Thread. > > -> bitte löschen! Dann registriere dich doch endlich mal, meine Güte. Mimimi, ich möchte mich nicht registrieren, mimi dieser Registrationszwag, mimimi... bald gibts Impfzwang, weinst du dann auch so rum oder schreist du Hurra? Das wird im Gegensatz zu hier unter die Haut gehen und es gibt keinen Ausweg. Dann passiert sowas auch nicht. Meine Güte...
:
Bearbeitet durch User
> Hannes J. schrieb: >> Was habt ihr alle mit dem dynamischen Scheißdreck? >> A-T-M-E-G-A! Hier auf uC.net ist es ja schon bedrückend wie klein man sich die Programmierwelt in 8 Bit redet, aber das toppt es noch! Wie haben es bloss unsere "Altvorderen" auf C64, Apple][ & Co. geschafft, uns eine Grundlage zu hinterlassen... Ich schrieb "... (dynamisch) ..." in Klammern weil es zwar naheliegend sein könnte, letztlich aber bei 26 Buchstaben, 10 Ziffern ach was bei nichtmal 127 druckbare ASCII Zeichen es sich hier um eine kleine fixe Menge handelt. Das lässt sich ohne nennenswerte Einschränkungen garantiert auch auf AtMega umsetzten!
MaWin schrieb: >> von MaWin (Gast) 14.04.2020 00:36 > > Ein Beitrag des Psychopathen der seinen Namen nicht kennt und > stattdessen MaWin ins Namensfeld schreibt um mir seine > Schwachsinnsantwort in die Schuhe zu schieben. Genau. Keiner der vielen MaWins kennt Pointers weil... > Fontdaten haben einen Vorteil: es sind Fazen. Fazen? Schwachsinnsantwort, in der Tat. Sollte es sich jedoch als Parkinson herausstellen, wo das Zittern der Finger das Treffen der richtigen Tasten behindert, so bitte ich um Verzeihung. Ausserdem: > also das Programm irgendwas in der Art > > char font[256][8]; ...soll sowas ausgerechnet in C keine Pointers sein? Vielleicht sollte "MaWin" tatsächlich als String im Namensfeld unterbunden werden (wie andere Strings übrigens bereits sind) damit sowohl der originale (selbstbezeichnete) Schwachsinn wie auch die vermeintlich psychopatischen Klone anders bezeichnet daherkommen.
Rolf M. schrieb: > Theor schrieb: >> Theoretisch ist es möglich zur Laufzeit eines C-Programmes ein weiteres >> C-Programm im Quellcode einzulesen, es zu interpretieren oder auch zu >> kompilieren und es auszführen resp. auf die darin enthaltenen Variablen >> zuzugreifen. > > Ein Interpreter für C (und C++) wäre z.B. cling. Den kann man auch recht > einfach in eigene Programme integrieren. > https://cdn.rawgit.com/root-project/cling/master/www/index.html > Es sollte sogar gehen, das komplette Programm in cling interpretiert > laufen zu lassen. > Ist allerdings alles etwas overkill, um eine als C-Code erzeugte > Fontdatei einzulesen. Dafür sollte ja nur ein extrem reduziertes Subset > von C nötig sein. Auf Deine letzte Aussage, dass das ein unangemessen hoher Aufwand für eine C-Datei ist, die (vermutlich) lediglich Definitionen und Initalisierungen enthält, wollte ich eigentlich hinaus. Ich nehme an, das gilt auch für die Verwendung von cling. > Wie macht das dann ein JIT-Compiler? Es ist, dass beschrieb ich ja schon, wenn auch sehr grob (und nicht auf JITs bezogen) durchaus möglich ausführbaren Code programmatisch zu erzeugen und auszuführen. Nur nützt das alles dem TO, da wo er steht, nichts, denke ich. Wozu also darüber diskutieren, ob und wie es möglich ist ausführbaren Code zu erzeugen und auszuführen. Ich kann mir nicht denken, dass das für den TO, an der Stelle, an der er sich befindet, von Nutzen ist. Siehst Du das anders? Für eine sinnvolle Alternative halte ich das von anderen Antwortern genannte parsen der C-Deklaration und Initialisierungen zum Zwecke der Speicherung und Neu-Ausgabe. Allerdings ist das immer noch in gewisser Weise von hinten durchs Auge geschossen. Die Infrastruktur dazu muss ja in dem schon verwendeten Programm vorhanden sein. Aus meiner Sicht, ändert "man" den vorhanden Code so, dass er die Ausgabe in der gewünschten Form macht - und erfindet das Rad nicht neu. Als Anfänger lernt man so auch mal Code von einem anderen Autor verstehen und das in einer sinnvollen Anwendung. Von dieser Vorgehensweise würde ich allenfalls abraten, falls der Code zu unstrukturiert ist.
Programmiersprachentheaterintendant schrieb: > Das lässt sich ohne nennenswerte Einschränkungen garantiert auch auf > AtMega umsetzten! Atmegas haben verdammt wenig RAM und können den Flash nicht zur Laufzeit beschreiben. Ich sehe da ergo gleich 2 nicht-triviale Einschränkungen. Die Sache mit der C-Source hat ja grade den Zweck die Daten in den Flash packen zu können...
Jim M. schrieb: > Atmegas haben verdammt wenig RAM und können den Flash nicht zur Laufzeit > beschreiben. Was macht denn ein Bootloader sonst?
Angehängte Dateien:
-
SSD1306.PNG
68 KB
Vielen Dank für die rege Beteiligung, auch wenn man deutlich merkt, dass die Nerven bei vielen blank liegen... Die bisherigen Tipps führen mich leider nicht wirklich zum Ziel. Wobei ich annehme, dass es schlicht nicht so einfach geht, wie ich das gerne hätte. Ich erkläre das ganze jetzt noch etwas ausführlicher, falls es jemand interessiert: Meine AVR-Library benutzt Fonts zwischen 8 und 64 Pixeln Höhe. Es können beliebige Schriften genutzt werden, sowohl proportionale als auch unproportionale. Nun werden diese Fonts natürlich schnell riesengroß, wenn sie alle Zeichen enthalten, zu groß jedenfalls für sinnvolle Nutzung auf dem AVR. Trotzdem fehlt dann doch immer wieder das eine oder andere Sonderzeichen. Mein Ansatz ist nun, dass ich für jede Schriftgröße nur die Zeichen codiere, die im jeweiligen AVR-Projekt benötigt werden. Es können beliebige Sonderzeichen enthalten sein, solange sie im Windows Font enthalten sind. Da gibt es recht nützliche Zeichen und Pictogramme... LCD Font Creator erzeugt eine Datei "fontname.c" welche (auf ein Zeichen gekürzt) so aussieht:
1 | /*
|
2 | typedef struct {
|
3 | const uint8_t *data;
|
4 | uint16_t width;
|
5 | uint16_t height;
|
6 | uint8_t dataSize;
|
7 | } tImage;
|
8 | typedef struct {
|
9 | long int code;
|
10 | const tImage *image;
|
11 | } tChar;
|
12 | typedef struct {
|
13 | int length;
|
14 | const tChar *chars;
|
15 | } tFont;
|
16 | */
|
17 | |
18 | #include <stdint.h> |
19 | |
20 | #if (0x0 == 0x0)
|
21 | static const uint8_t image_data_tahoma24_0x20[21] = { |
22 | |
23 | 0x00, 0x00, 0x00, |
24 | 0x00, 0x00, 0x00, |
25 | 0x00, 0x00, 0x00, |
26 | 0x00, 0x00, 0x00, |
27 | 0x00, 0x00, 0x00, |
28 | 0x00, 0x00, 0x00, |
29 | 0x00, 0x00, 0x00 |
30 | };
|
31 | static const tImage tahoma24_0x20 = { image_data_tahoma24_0x20, |
32 | 7, 24, 8}; |
33 | #endif
|
34 | |
35 | static const tChar tahoma24_array[] = { |
36 | |
37 | #if (0x0 == 0x0)
|
38 | // character: ' '
|
39 | {0x20, &tahoma24_0x20}, |
40 | #else
|
41 | // character: ' ' == ''
|
42 | {0x20, &tahoma24_0x}, |
43 | #endif
|
44 | }
|
45 | |
46 | const tFont tahoma24 = { 136, tahoma24_array }; |
Diese Datei fontname.c benenne ich manuell in fontname.h um und include sie in mein Konvertier-Utility. Außerdem include ich noch eine einfache Tabelle selectchars.h (mit Excel erstellt), in der für jeden Zeichencode von 0..255 der gewünschte Unicode zugewiesen wird oder, falls das Zeichen nicht benötigt wird, 0x20. Dadurch kann ich beispielsweise einen 48px Font erzeugen, der nur die Symbole 0..9, C, ° enthält, wenn eine große Temperaturanzeige benötigt wird. Mein Konvertier-Utility erzeugt mir eine Font-Datei die so aussieht:
1 | typedef struct { |
2 | const uint8_t *data; |
3 | const uint8_t width; |
4 | } tImage; |
5 | |
6 | //Font tahoma24.h
|
7 | static const uint8_t image_data_tahoma24_0x20[] PROGMEM = { |
8 | // ascii 0x20
|
9 | 0x00, 0x00, 0x00, |
10 | 0x00, 0x00, 0x00, |
11 | 0x00, 0x00, 0x00, |
12 | 0x00, 0x00, 0x00, |
13 | 0x00, 0x00, 0x00, |
14 | 0x00, 0x00, 0x00, |
15 | 0x00, 0x00, 0x00 |
16 | };
|
17 | static const tImage tahoma24_0x20 PROGMEM = {image_data_tahoma24_0x20, 7}; |
18 | |
19 | static const tImage* const charset24[] PROGMEM = { |
20 | &tahoma24_0x20, // 0x20 ' ' |
21 | &tahoma24_0x21, // 0x21 '!' |
22 | ...
|
23 | &tahoma24_0x20 // 0xff 'ÿ' |
24 | };
|
Diese Datei kann ich in meiner Library verwenden. Nun geht es aber nicht um nur eine Font-Datei, weil die Library für jede benötigte Schriftgröße jeweils einen eigenen Font benutzen kann. Das jetzige Verfahren funktioniert, ist aber umständlich und fehleranfällig. MaWins Vorschlag, fontname.c zur Laufzeit einzulesen und zu Parsen wäre mir mit recht viel Mühe möglich. Ich erinnere mich dunkel, dass diese Technik in vielfältiger Form als Übungen im K&R enthalten waren, den ich vor bald 30 Jahren bis Kapitel 5 durchgearbeitet habe, bevor ich C zu Teufelswerk erklärt habe, um es nie mehr anzufassen. Bis heute hat es gedauert, dieses Trauma zu überwinden. :) Theor, den Source Code des 'LCD Font Converter' anzupassen, werde ich mit meinem Kenntnisstand nicht schaffen. Zumal das C++ ist. Wobei das natürlich klar der beste Weg wäre. Die eigentlich Library funktioniert übrigens, jedenfalls wenn/falls ich sie mit den richtigen Fonts füttere. Ein Beispiel liegt bei.
Erwin E. schrieb: > Zur Laufzeit möchte ich nun eine dieser C-Dateien zur Verarbeitung > auswählen können. Hat das einen tieferen Sinn, dass dies nicht zur Compile-Zeit geschehen darf?
Wo sollen die Daten denn liegen die zur Laufzeit 'umgeschaltet' werden? Wenn die ins Flash passen, macht es nur Sinn die auch gleich zu kompilieren+linken. Wenn die in einem externen Flash oder SD Karte liegen, dann ist ein binärformat auch pratkischer.
Mark B. schrieb: > Erwin E. schrieb: >> Zur Laufzeit möchte ich nun eine dieser C-Dateien zur Verarbeitung >> auswählen können. > > Hat das einen tieferen Sinn, dass dies nicht zur Compile-Zeit geschehen > darf? Hat er doch geschrieben: Er möchte nicht für jeden Font, den er einbinden möchte bzw. jedes mal, wenn darin ein Zeichen geändert wird, sein Tool neu compilieren müssen. Johannes S. schrieb: > Wo sollen die Daten denn liegen die zur Laufzeit 'umgeschaltet' werden? > Wenn die ins Flash passen, macht es nur Sinn die auch gleich zu > kompilieren+linken. Auf dem PC?
Erwin E. schrieb: > Vielen Dank für die rege Beteiligung, [...] > > Theor, den Source Code des 'LCD Font Converter' anzupassen, werde ich > mit meinem Kenntnisstand nicht schaffen. Zumal das C++ ist. Wobei das > natürlich klar der beste Weg wäre. > > [...] Dann würde ich raten, Lexas Vorschlag mit den Makefiles zu folgen. Das ist formal ein "sauberer" Weg. Vermutlich kennst Du Dich allerdings mit Makefiles nicht so gut aus. Nur muss man dazu sagen, dass Du letztlich irgendeine Kröte schlucken musst; will sagen: Um irgendwas "kompliziertes", sei es C++, Makefiles oder eben cling, Parser o.ä. kommst Du nicht herum, wenn Du die Methode ändern willst, so das sie universeller ist.
Erwin E. schrieb: > Ist es möglich, dass ein C-Programm (Visual C) zur Laufzeit eine weitere > C-Datei mit Daten einbindet? Ja. Stichworte sind dlopen bzw. LoadLibrary. Ich bezweifle aber, dass das auf einem AtMega einsetzbar ist. leo
Warum verwendest du kein Binär-Format? Alle Betriebssysteme haben solche Mechanismen (Bsp: TrueType-Font unter Windows). Du könntest selber eines entwickeln, das auf deine Ansprüche optimiert ist oder du suchst was existierendes. merciless
Rolf M. schrieb: > Hat er doch geschrieben: Er möchte nicht für jeden Font, den er > einbinden möchte bzw. jedes mal, wenn darin ein Zeichen geändert wird, > sein Tool neu compilieren müssen. Dann ist der sinnvolle Weg doch wohl, in einem Verzeichnis fertig kompilierte Dateien für die Fonts liegen zu haben, und diese je nach Auswahl zur Laufzeit zu laden. Zur Laufzeit etwas extra noch kompilieren zu wollen klingt jedenfalls ein wenig schräg.
:
Bearbeitet durch User
Danke für alle Anregungen! Ich werde mich an einem Parser versuchen. Eigentlich sollte das gar nicht so schwer sein, weil die Daten bereits weitgehend mundgerecht vorliegen.
Erwin E. schrieb: > Ich werde mich an einem Parser versuchen. Eigentlich sollte das gar > nicht so schwer sein, weil die Daten bereits weitgehend mundgerecht > vorliegen. Ein Parser ist ohne entsprechende Erfahrung deutlich schwieriger, als einen C-Compiler (incl. Präprozessor) parsen zu lassen und die Informationen in einem C-Programm zu verarbeiten. Wenn es gar nicht anders geht, ist es auch kein Problem, die gesammelten und verarbeiteten Infos in einem C-Format wieder auszuspucken.
cppbert schrieb: > Erwin E. schrieb: >> LCD Font Creator > > Link? Steht im Eröffnnungsbeitrag. Ganz, ganz nach oben scrollen... Die Software heisst korrekt "LCD Image Converter". Sorry, hab ich durcheinander gebracht. Das Programm erscheint mir teilweise etwas buggy, insbesondere der enthaltene Fonteditor, es ist aber trotzdem sehr gut nutzbar.
Erwin E. schrieb: > Die Software heisst korrekt "LCD Image Converter". Sorry, hab ich > durcheinander gebracht. Das Programm erscheint mir teilweise etwas > buggy, insbesondere der enthaltene Fonteditor, es ist aber trotzdem sehr > gut nutzbar. auf der Homepage steht:
1 | The transformation of the images to the source code is made by using templates. Therefore, by modifying the templates, you can change the format of the output within certain limits. |
warum machst du dir nicht ein einfaches Template das deine Daten simple ausspuckt?
sieht nicht so schwer aus - und dann einen trivialen Parser dazu https://www.riuson.com/lcd-image-converter/templates
Hannes J. schrieb: > Nein, die Übung besteht darin mehrere der Font-Dateien in den Code zu > kompilieren und zur Laufzeit durch einen noch zu wählenden Mechanismus > (zum Beispiel einen Pointer auf die Datenstruktur), den gewünschten Font > auszuwählen. sollte doch machbar sein solange der flash reicht fontdatatype SmallFont1[] PROGMEM = fontdatatype SmallFont2[] PROGMEM = extern uint8_t SmallFont1[]; extern uint8_t SmallFont2[]; myGLCD.setFont(SmallFont1); myGLCD.setFont(SmallFont2); muss man halt programmieren
cppbert schrieb: > warum machst du dir nicht ein einfaches Template das deine Daten simple > ausspuckt? Berechtigte Frage... Der Hauptgrund ist, dass ich es nicht geschafft habe, dass mir das Programm die Fontdaten in der korrekten Reihenfolge ausgibt. Ich brauche die Daten eines Zeichens spaltenweise, also von links nach rechts und von oben nach unten. Das geht durchaus, nur musste ich die einzelnen Bytes noch spiegeln, damit sie korrekt angezeigt werden. Also Bit 0 wird Bit 7, Bit 1 wird Bit 6 etc. Das ist mir im Font Creator nicht gelungen. Ich kann da nur die 'Laufrichtung' ändern, also von oben nach unten oder anderstherum. Für das Oled hat aber keine Option gepasst. Erst habe ich das Spiegeln der Bytes in meiner Ausgaberoutine gemacht. Das funktioniert, kostet aber unnötig Rechenzeit. Außerdem brauche ich für jeden Font eine Tabelle zur Umsetzung ASCII - Unicode. Im Extremfall könnte ich einen Font mit nur einem einzelnen Zeichen in der Library verwenden, ohne dass ich bei den Ausgabefunktionen darauf Rücksicht nehmen müsste. Fehlt ein zeichen, wird ein Defaultzeichen benutzt. Diese Tabelle müsste ich ohnehin für jeden Font eigenständig erzeugen, da helfen mir auch die Templates nicht (glaube ich). Meine Lib ist sinnfrei, wenn nur ein einzelner Font der Größe 8px mit den Standardzeichen gebraucht wird, weil jede Tabelle bereits 500 Bytes Flash Memory belegt. Bei größeren Fonts amortisiert sich das aber sehr schnell. Außerdem brauche ich so nur die Zeichen im Flash vorhalten, die im Projekt vorkommen. Und ich kann beliebige Sonderzeichen und Pictogramme verwenden und im Code einfach als Buchstaben schreiben. Oben auf dem Foto z.B. die Batterieanzeige oder den Lautsprecher. Last not least, das ist mein erstes Projekt in C. Hat also durchaus auch den Zweck, mich in C einzuarbeiten. Rant: Wer sich die (nicht-)Stringverarbeitung in C ausgedacht hat, sollte mit Katzendreck erschossen werden. :)
cppbert schrieb: > sieht nicht so schwer aus - und dann einen trivialen Parser dazu Genau daran bastle ich gerade. Auch ein trivialer Parser ist für einen C-Anfänger nicht unbedingt trivial. ;)
Erwin E. schrieb: > cppbert schrieb: >> warum machst du dir nicht ein einfaches Template das deine Daten simple >> ausspuckt? > > Berechtigte Frage... > Der Hauptgrund ist, dass ich es nicht geschafft habe, dass mir das > Programm die Fontdaten in der korrekten Reihenfolge ausgibt. Ich glaube, gemeint war nicht, dass die Daten direkt für den AVR ausgegeben werden sollen, sondern so, dass sie für dein Programm möglichst leicht zu parsen sind. Erwin E. schrieb: > Last not least, das ist mein erstes Projekt in C. Hat also durchaus auch > den Zweck, mich in C einzuarbeiten. Rant: Wer sich die > (nicht-)Stringverarbeitung in C ausgedacht hat, sollte mit Katzendreck > erschossen werden. :) Stringverarbeitung ist nicht grad die Stärke von C. Aber es war ja deine Wahl, ausgerechnet das zum Erlernen von C zu verwenden. Aber es hat auch was gutes: Wenn du damit klar kommst, hast du den schwierigsten Teil von C schon gemeistert - Pointer und Arrays.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.