Guten Tag, ich suche Hilfe in Bezug auf den SSD1309 mit 128x64 OLED Display. Dort habe ich in eine Bibliothek aus dem Netz eine Schriftart drin. Die funktioniert. Aber wie kann ich selber weitere Schriftarten machen? Mir geht es gar nicht um spielerei sondern ich möchte kleinere Schriften und BOLD Schriften haben. Die immer in 1 Zeile passen, so wie ich das verstanden habe wird das sonst kompliziert, wenn man Schriften über mehrere Zeilen macht. Wird aber auch zu groß. Spannende Frage wäre aber noch: Wenn man kleine Schrift macht, wie kann ich in eine Zeile quasi 2 Zeilen der kleinen Schrift schrieben ?
Fred schrieb: > Aber wie kann ich selber weitere Schriftarten machen? Wenn man ein bissel nachdenkt, ist das Selbermachen von Fonts für solche Displays, die im Vergleich zum Bildschirm des PC recht winzig sind, gar nicht so schwer. Es ist im Grunde nur eine Fleißarbeit. Die eigentliche Frage ist eher, wie die Benutzung so eines Displays denn organisiert ist. Am besten geht das, wenn man sich im RAM seines µC einen Bildspeicher einrichtet, sozusagen eine virtuelle Zeichenfläche. Auf der einen Seite ist der eigentliche Displaytreiber, dessen Aufgabe hauptsächlich darin besteht, den Inhalt des Bildspeichers in das Display zu transferieren und auf der anderen Seite ist das GDI, also die Grafikroutinen, die das Zeichnen von Linien, Setzen von Pixeln, Füllen von Flächen, Zeichnen von Grafiken und eben das Zeichnen von Textzeichen erledigen. Für das Zeichnen von Textzeichen braucht so eine Zeichenroutine eben einen Font je nach Geschmack des Programmierers. Man hat also 3 verschiedene Dinge: - den Displaytreiber - das GDI - die Fonts Damit sind diese Dinge soweit voneinander entkoppelt, daß man sie einigermaßen separat voneinander verwenden kann. Der Displaytreiber paßt nur zu dem Display, wofür er gemacht ist, das GDI hat mit dem Display kaum etwas zu tun, sondern braucht nur die virtuelle Zeichenfläche und bei Farbdisplays eben noch die Behandlung von Farben, die bei Monochromdisplays auf 3 "Farben" zusammenschrumpfen: schwarz, weiß und invertieren. Und der Font braucht nur sein für alle Textgrößen und Formen gleiches Interface zum GDI hin. Damit ein GDI eben verschiedene Fonts verwenden kann. Und wenn du hier im Forum ein wenig suchst, dann findest du auch Beiträge zum Selbermachen von Fonts (in unterschiedlichen Stufen der Verwendbarkeit). Meinen Senf zum Thema hänge ich dir hier dran. Sollte eigentlich selbsterklärend sein. W.S.
Fred schrieb: > Aber wie kann ich selber weitere Schriftarten machen? Wenn du sowas einfach kopiert hast, musst du erst mal verstehen, wie die Software mit der vorhandenen Schrift funktioniert und wie die Zeichen des Fonts gespeichert sind. Kein Verständnis -> keine Schrift. Fred schrieb: > Spannende Frage wäre aber noch: Wenn man kleine Schrift macht, wie kann > ich in eine Zeile quasi 2 Zeilen der kleinen Schrift schrieben ? Das Display hat ja garkeine Zeilen, sondern 64 Pixel senkrecht. In welche Zeilen das eingeteilt wird, wenn überhaupt, ist eine Frage der Software. Im Prinzip kann man ein Zeichen an eine beliebige Stelle auf dem Display schreiben, senkrecht und waagrecht. Georg
W.S. schrieb: > Wenn man ein bissel nachdenkt, ist das Selbermachen von Fonts für solche > Displays, die im Vergleich zum Bildschirm des PC recht winzig sind, gar > nicht so schwer. Es ist im Grunde nur eine Fleißarbeit. > > Die eigentliche Frage ist eher, wie die Benutzung so eines Displays denn > organisiert ist. Am besten geht das, wenn man sich im RAM seines µC > einen Bildspeicher einrichtet, sozusagen eine virtuelle Zeichenfläche. Zuvor muß man sich überlegen, wie viel RAM benötigt wird, ob der µC genug davon hat. Ich habe mit einem Arduino (AT328) eine Bruchlandung gedreht, die SSD-Library frisst dermaßen viel Ressourcen, dass meine Hauptanwendung abstürzt.
Georg schrieb: > Fred schrieb: >> Aber wie kann ich selber weitere Schriftarten machen? > > Wenn du sowas einfach kopiert hast, musst du erst mal verstehen, wie die > Software mit der vorhandenen Schrift funktioniert und wie die Zeichen > des Fonts gespeichert sind. Kein Verständnis -> keine Schrift. > > Fred schrieb: >> Spannende Frage wäre aber noch: Wenn man kleine Schrift macht, wie kann >> ich in eine Zeile quasi 2 Zeilen der kleinen Schrift schrieben ? > > Das Display hat ja garkeine Zeilen, sondern 64 Pixel senkrecht. In > welche Zeilen das eingeteilt wird, wenn überhaupt, ist eine Frage der > Software. Im Prinzip kann man ein Zeichen an eine beliebige Stelle auf > dem Display schreiben, senkrecht und waagrecht. > > Georg Verstanden habe ich das schon. Das ist vertikal und du hast halt 8px und die aktuelle Schrift ist 8 "Zeilen" breit, also 8px hoch und 8px breit. Den Aufbau habe ich verstanden. Das Display selber hat pages mit 8 px (deswegen auch die Schrift). 8 Zeilen also (8x8 = 64). Das ist bisschen das Problem. Wäre das nicht so, könnte man freier agieren, macht man eine Schrift > 8px höhe muss man halt auf 2 pages aufteilen. Verstehe ich auch ist aber unschön. Ich brauche aber auch nur kleinere Schriften. Spannend ist dann aber wie man das unterteilt, bspw. aus einer Page 2 Zeilen machen
Manfred schrieb: > W.S. schrieb: >> Wenn man ein bissel nachdenkt, ist das Selbermachen von Fonts für solche >> Displays, die im Vergleich zum Bildschirm des PC recht winzig sind, gar >> nicht so schwer. Es ist im Grunde nur eine Fleißarbeit. >> >> Die eigentliche Frage ist eher, wie die Benutzung so eines Displays denn >> organisiert ist. Am besten geht das, wenn man sich im RAM seines µC >> einen Bildspeicher einrichtet, sozusagen eine virtuelle Zeichenfläche. > > Zuvor muß man sich überlegen, wie viel RAM benötigt wird, ob der µC > genug davon hat. > > Ich habe mit einem Arduino (AT328) eine Bruchlandung gedreht, die > SSD-Library frisst dermaßen viel Ressourcen, dass meine Hauptanwendung > abstürzt. Kein Problem. Xmega256A3U
Adafruit_GFX, hat viele Fonts in beliebiger Größe und auch einen Converter. Es gibt sogar eine Website über die man die TTF auswählen und auf dem Oled virtuell darstellen kann. http://oleddisplay.squix.ch/#/home
:
Bearbeitet durch User
Tuffi schrieb: > Verstehe ich auch ist aber unschön Der Zweck des Programmierens ist nicht Schönheit sondern Funktion. Für eine beliebige Position muss man u.U. 2 x waagrecht und 2 x senkrecht schreiben, na und. Es ist doch von vornherein klar dass in eine 8x8 Einteilung auf die einfache Art eben nur dieser 8x8 Font passt und sonst keiner. Selbst wenn man jedes Pixel einzeln schreibt, es interessiert nur was auf dem Display erscheint. Georg
Georg schrieb: > Tuffi schrieb: >> Verstehe ich auch ist aber unschön > > Der Zweck des Programmierens ist nicht Schönheit sondern Funktion. Für > eine beliebige Position muss man u.U. 2 x waagrecht und 2 x senkrecht > schreiben, na und. Es ist doch von vornherein klar dass in eine 8x8 > Einteilung auf die einfache Art eben nur dieser 8x8 Font passt und sonst > keiner. Selbst wenn man jedes Pixel einzeln schreibt, es interessiert > nur was auf dem Display erscheint. > > Georg Ja das stimmt. Was ich meine, bzw. wo mein Krampf gerade drin steckt ist: 1. Font erstellen der so aufgebaut ist, wie der, der bereits funktioniert. 2. Anzeige auf dem Display. Vermutlich macht das mit dem virt. Puffer am meisten Sinn. Dann die Schrift OR verknüfen vorher den Text & damit der plain ist. Wenn man bspw. 4x4 font hat. Damit man das in 2 Zeilen bekommt. Sonst geht das ja nicht, da die Schrift darüber ja verschwinden würde Kernproblem gerade ist ehrlich gesagt die Schrifterzeugung. Adafruit habe ich auch gefunden aber die basieren immer auf 8px und sind dann zu groß oder ich habe da irgendwelche Fragmente irgendwie verstehe ich das da noch nicht
Die Adafruit Schriften sind irgendwie sehr komplex. Mit Sprungtablen etc. Anbei mal die, die bei der Lib bei war.
Tuffi schrieb: > Verstanden habe ich das schon. > ... > Das Display selber hat pages mit 8 px (deswegen auch die Schrift). 8 > Zeilen also (8x8 = 64). Das ist bisschen das Problem. Wäre das nicht so, > könnte man freier agieren, ... Hmm, ich denke, du hast es noch nicht verstanden. Das GDI hat ein Feld von 128x64 Pixeln (variiert je nachdem, was man für ein Display benutzen will), auf dem es lustig herummalen kann. Das Umsetzen eben dieses Feldes in den Controller des betreffenden Displays ist Aufgabe des Displaytreibers. Das GDI kann also im Rahmen der verfügbaren Pixel frei agieren und da spielen irgendwelche 'Pages' o.ä. des Displaycontrollers überhaupt keine Rolle. Bei dem Zeug, was ich weiter oben mal drangehängt habe, ist die Zeichenbreite variabel. Ein 'i' ist da zumeist schmaler als ein 'W'. Und das Ganze schert sich um irgendwelche Eigenheiten des konkreten Displays überhaupt nicht. Schlußendlich gibt es ein Muster aus gesetzten und nicht gesetzten Bits im Displayfeld, die anschließend ins eigentliche Display geschaufelt werden müssen. Wie, über welches Interface und in welchen Stücken das zu passieren hat, ist sowohl dem GDI als auch für den Font egal. W.S.
Tuffi schrieb: > Die Adafruit Schriften sind irgendwie sehr komplex. Mit > Sprungtablen etc. Anbei mal die, die bei der Lib bei war. Da gibt es zwei Font Systeme, aus dem Anhang ist noch das einfache mit fester Zeichgröße, dann gibt es noch die TTF die mit setFont() aktiviert werden.
Tuffi schrieb: > Die Adafruit Schriften sind irgendwie sehr komplex. Mit Sprungtablen > etc. Anbei mal die, die bei der Lib bei war. Naja, zumindest sind sie wohl weitgehend unkommentiert. Aber ein bissel komplex sind Fonts wohl immer, wenn sie flexibel sein sollen. Im Grunde hat man es da mit folgenden Dingen zu tun: 1. ein Fontheader. Der sagt, wie hoch der Font ist und welche Zeichen überhaupt drin sind. 2. für jedes Zeichen ein Zeichenheader, wenn die Zeichen unterschiedlich breit sein können. Dort stehen dann die Zeichenbreite und ein Zeiger oder Offset zu den eigentlichen Pixeln drin. 3. die Pixel der Zeichen. Bei primitiveren Fonts immer in Stücken zu einem Byte, sonst nur eben soviel Bytes, wie für die tatsächlich vom Zeichen benutzten Pixel benötigt wird. Das Ganze ist bei den hierzulande benutzten Schriften auf 8 Bit große Textzeichen (also ANSI im Prinzip) beschränkt, weil sonst der Platzbedarf (für 16 Bit Zeichen) recht schnell die Ressourcen von µC übersteigen würde. Den Chinesen würde das etwas weniger gefallen. Die müßten sich dann pro Zeichen ein entsprechendes Bildchen machen, was zumeist bei geringen Auflösungen wie 128x64 nicht gerade schön aussieht. W.S.
W.S. schrieb: > Naja, zumindest sind sie wohl weitgehend unkommentiert. > > Aber ein bissel komplex sind Fonts wohl immer, wenn sie flexibel sein > sollen. Das ist der Fluch der Copy & Paste "Programmierung". Macht man sich die Mühe die Schriftausgabe selbst zu programmieren kann man auf Verwaltungsangaben in der Fontdatei völlig verzichten, man weiss ja welchen Font man gerade verwendet - also müssen die Fontdaten nur aus den Pixeln für jedes Zeichen bestehen. Wie man die anordnet kann man sich selbst ausdenken, z.B. bei 5 x 7 einfach für jedes ASCII-Zeichen 7 Bytes in einem array. Mit Unterlängen 9 oder 10, sieht schöner aus. Die Pixeldaten kann man z.B. in C definieren:
1 | const unsigned char font[96][9] = {
|
2 | {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}, //
|
3 | {0x10,0x10,0x10,0x10,0x10,0x10,0x00,0x00,0x10}, // !
|
4 | {0x24,0x24,0x24,0x00,0x00,0x00,0x00,0x00,0x00}, // "
|
5 | {0xFE,0xEE,0x6C,0xAA,0xC6,0xAA,0x6C,0xEE,0xFE}, // #
|
6 | {0x10,0x38,0x54,0x92,0x92,0x92,0x54,0x38,0x10}, // $
|
7 | .... |
Egal wie, mehrere Fonts unterschiedlicher Grösse braucht schon eine Menge Speicherplatz, z.B. 256 x 7 = 1792 Bytes. Sollte aber heute kein Problem mehr sein, man muss halt einen geeigneten Controller nehmen. Georg
Georg schrieb: > Die Pixeldaten kann man z.B. in C definieren:
1 | // font.h
|
2 | #include <stdint.h> |
3 | |
4 | typedef enum fontbits_enum { |
5 | _____ = 32LL << 56, |
6 | ____O = 1LL << 56, |
7 | ___O_ = 2LL << 56, |
8 | ___OO = 3LL << 56, |
9 | __O__ = 4LL << 56, |
10 | __O_O = 5LL << 56, |
11 | __OO_ = 6LL << 56, |
12 | __OOO = 7LL << 56, |
13 | _O___ = 8LL << 56, |
14 | _O__O = 9LL << 56, |
15 | _O_O_ = 10LL << 56, |
16 | _O_OO = 11LL << 56, |
17 | _OO__ = 12LL << 56, |
18 | _OO_O = 13LL << 56, |
19 | _OOO_ = 14LL << 56, |
20 | _OOOO = 15LL << 56, |
21 | O____ = 16LL << 56, |
22 | O___O = 17LL << 56, |
23 | O__O_ = 18LL << 56, |
24 | O__OO = 19LL << 56, |
25 | O_O__ = 20LL << 56, |
26 | O_O_O = 21LL << 56, |
27 | O_OO_ = 22LL << 56, |
28 | O_OOO = 23LL << 56, |
29 | OO___ = 24LL << 56, |
30 | OO__O = 25LL << 56, |
31 | OO_O_ = 26LL << 56, |
32 | OO_OO = 27LL << 56, |
33 | OOO__ = 28LL << 56, |
34 | OOO_O = 29LL << 56, |
35 | OOOO_ = 30LL << 56, |
36 | OOOOO = 31LL << 56 |
37 | } fontbits_enum; |
38 | |
39 | typedef enum glyph_enum { |
40 | LATIN_SMALL_LETTER_SHARP_S = // 337 223 DF |
41 | _OO__ >> 56 | |
42 | O__O_ >> 48 | |
43 | O_O__ >> 40 | |
44 | O__O_ >> 32 | |
45 | O___O >> 24 | |
46 | O___O >> 16 | |
47 | O_OO_ >> 8 | |
48 | _____, |
49 | EURO_SIGN = // 244 164 A4 U+20AC |
50 | _OOOO >> 56 | |
51 | O____ >> 48 | |
52 | OOOO_ >> 40 | |
53 | O____ >> 32 | |
54 | OOOO_ >> 24 | |
55 | O____ >> 16 | |
56 | _OOOO >> 8 | |
57 | _____, |
58 | } glyph_enum; |
59 | |
60 | #define GLYPH(g) = (((g>>56)&1)<<7)|(((g>>48)&1)<<6)|(((g>>40)&1)<<5)|
|
61 | usw. |
62 | -----------------------------
|
63 | // font.c
|
64 | #include <stdint.h> |
65 | |
66 | static const uint8_t font[] = { |
67 | 'ß', GLYPH (LATIN_SMALL_LETTER_SHARP_S), |
68 | '€', GLYPH (EURO_SIGN), |
69 | };
|
Man braucht keinen Fonteditor und man kann GLYPH so definieren, dass ein 6x8 Font wie dieser in 5 statt in 8 Byte gespeichert wird. Oder "normal" in 8 Byte, die typedefs bleiben gleich.
Georg schrieb: > Das ist der Fluch der Copy & Paste "Programmierung". > > Macht man sich die Mühe die Schriftausgabe selbst zu programmieren kann > man auf Verwaltungsangaben in der Fontdatei völlig verzichten, man weiss > ja welchen Font man gerade verwendet... Das ist alles zu kurz gesprungen. Normalerweise hat eine Ausgaberoutine die Aufgabe, eine Zeichenkette auszugeben und zwar in einem der in der Firmware vorhandenen Fonts. Dazu muß sie zu jedem Textzeichen den zugehörigen Glyph finden. Wenn man nur einen Font und den auch noch mit fester Zeichenbreite verwendet, dann kann man mit einem Array arbeiten. In anderen Fällen braucht man sowohl Angaben zu generellen Fontdaten wie Höhe, Ascent usw. als auch Angaben zur jeweiligen Zeichenbreite und einen Zeiger zu dem zutreffenden Glyph. Und das alles hat nix mit copy&paste zu tun, sondern mit dem Verwalten von unterschiedlichen Fonts. Bauform B. schrieb: > typedef enum fontbits_enum { > ___ = 32LL << 56, > ____O = 1LL << 56, > __O = 2LL << 56,... Natürlich kann man alles auch noch viel komplizierter machen, als es sein muß. Wer gern Deklarations- oder Preprozessor-Akrobatik macht, ist herzlich eingeladen, es noch umständlicher zu machen. Und dann bitte 4 Fonts in die Firmware hinein, damit man etwas zum auswählen hat: Helvetika 12pt regular, Helvetika 12pt bold, Helvetika 14pt regular, Helvetika 14pt bold. und eventuell noch ein paar Symbole oder 25pt große Ziffern dazu, die Symbole jeweils 11 Pixel hoch und so etwa 25 Pixel breit. Mahlzeit! Man kann gar vieles tun, allerdings mit unterschiedlichem Ergebnis. W.S.
Beitrag #7102306 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
Adafruit_Fonts.jpg
210 KB
W.S. schrieb: > Und dann bitte 4 > Fonts in die Firmware hinein, damit man etwas zum auswählen hat: eine Fingerübung mit Adafruit_GFX und dem genannten Fontgenerator.
J. S. schrieb: > eine Fingerübung mit Adafruit_GFX und dem genannten Fontgenerator. Aber der liefert nicht sowas: Bauform B. schrieb: > typedef enum glyph_enum { > LATIN_SMALL_LETTER_SHARP_S = // 337 223 DF > OO_ >> 56 | > O__O_ >> 48 | > O_O__ >> 40 |... Gelle? W.S.
Mhm, soweit so gut soweit so schlecht. Es mag ja sein das es Bibliotheken gibt (Adafrut) und dafür Schriften und man kann ohne Verstand einfach alles zusammenklatschen. Schön. Aber ich würde das gerne optimaler und verständlicher haben. Der Treiber ist fertig für den SSD1309 der funktioniert und ich kann auch Pixel setzen oder halt auch die vorgegebene Schrift. Für mich würde es schon reichen, wenn ich eine Schrift hätte, die kleiner ist, wegen mir in 8 Bit gespeichert, Dann passe ich den Treiber an. Womit kann man denn Schriften erzeugen?
Tuffi schrieb: > Womit kann man denn Schriften erzeugen? Karopapier, Bleistift ... Gehirnschmalz. Eine Variante wurde Dir schon in der allerersten Anwort auf Deine Frage geliefert - im Zip-archiv "fonts_machen" ist ein Programm, das Textdateien in C-Source übersetzt. Die Textdateien musst Du Dir selbst basteln, in denen sieht es z.B. so aus:
1 | Ch_30: { "zero" }
|
2 | ...... |
3 | ...... |
4 | .MMM.. |
5 | MM.MM. |
6 | MM.MM. |
7 | MM.MM. |
8 | MM.MM. |
9 | MM.MM. |
10 | MM.MM. |
11 | .MMM.. |
12 | -- ...... |
13 | ...... |
14 | ; |
Das Tool im Zip-Archiv erzeugt daraus das hier:
1 | ... |
2 | 2, 12, 6, 12, /* CH_30 "zero" cnt= 9 ab 524*/ |
3 | ... |
4 | |
5 | /* CH_30 524 "zero" */ 0, 224, 108, 219, 182, 109, 155, 3, 0, |
Das erste ist eine Beschreibung des Zeichenaufbaus (es handelt sich schließlich um eine Proportionalschrift), das zweite sind die Bytes, aus denen sich das Bitmuster des Zeichens letztlich zusammensetzt. Und wie man mit diesen Fonts was anfängt, hat w.s. auch beschrieben, das steht in readme.c
Tuffi schrieb: > Womit kann man denn Schriften erzeugen? Eigenes Gehirn. Für so eine Liste wie auch derEgon beschreibt braucht man keinen Fonteditor, die Zeichen im Text zu editieren ist genausoviel Aufwand wie mit einem spezialisierten Editor, siehe Beispiel mit einem Font von mir. Einen Fonteditor der die Zeichen selber entwirft gibt es nicht. Georg
DerEgon schrieb: > Tuffi schrieb: > Das Tool im Zip-Archiv erzeugt daraus das hier: > ... > 2, 12, 6, 12, /* CH_30 "zero" cnt= 9 ab 524*/ > ... > /* CH_30 524 "zero" */ 0, 224, 108, 219, 182, 109, 155, 3, 0, > > Das erste ist eine Beschreibung des Zeichenaufbaus (es handelt sich > schließlich um eine Proportionalschrift), das zweite sind die Bytes, aus > denen sich das Bitmuster des Zeichens letztlich zusammensetzt. Jetzt habe ich das kapiert wie die Software geht, die startet nämlich nicht, ich hatte eine graphische Oberfläche erwartet. Gibt es da noch andere Programme? WO man bspw. Windows Font laden kann und dann pixelhöhe angibt? Das selber zu machen ist eine Arbeit für jemanden der Mutter und Vater erstochen hat. Dafür gibt es Computer die das berechnen und erzeugen können. Nachher, wenn ich bspw. 5x5 Schrift basiert auf 8px oder so habe, das bekomme ich dann hin das in den Treiber einzubauen.
Tuffi schrieb: > Gibt es da noch andere Programme? Für Geld gibt es alles: http://www.iseasoft.com/bitfontcreator.html
Tuffi schrieb: > ich hatte eine graphische Oberfläche erwartet. Gibt es da noch > andere Programme? Hoffnungsloser Fall, ich gebe auf. Georg
Tuffi schrieb: > ich hatte eine graphische Oberfläche erwartet Versuche das: Beitrag "Charaktergenerator"
Georg schrieb: > Tuffi schrieb: >> ich hatte eine graphische Oberfläche erwartet. Gibt es da noch >> andere Programme? > > Hoffnungsloser Fall, ich gebe auf. > > Georg Ne mal ernsthaft Georg. Zeit ist Geld. Wenn ich mir 3 Schriften erzeugen will und das für alle Buchstaben nach der Methode mache, sitze da ne Woche. Das ist doch auch überhaupt nicht zeitgemäß da muss es doch Generatoren geben. Oder alterntiv auch eine Software die 200€ kostet das ist immer noch weniger als sich da 2 Wochen hinzusetzen.
Tuffi schrieb: > sitze da ne Woche Nee, echt? Dann bist Du sehr gründlich. Tuffi schrieb: > Oder alterntiv auch eine Software die 200€ kostet das > ist immer noch weniger als sich da 2 Wochen hinzusetzen. Gibt es ja, hab' ich oben verlinkt. Kostet in der "Latin"-Version (für 256 Zeichen) auch nur 160 EUR. Die Unicode-Ausführung kostet knapp 200 EUR, aber die brauchst Du vermutlich nicht.
Tuffi schrieb: > ... die startet nämlich nicht,... Die startet schon, bloß du hattest nicht das Kommandozeilenfenster offen. > ... Das selber zu machen ist eine Arbeit für jemanden der > Mutter und Vater erstochen hat. Tja, das Schlaraffenland ist nicht ohne Grund von einer hohen Mauer aus Grießbrei umgeben - damit die allzu faulen Leute nicht hineinkommen. Ich hatte ja bereits weiter oben geschrieben, daß das eher eine Fleißarbeit ist. Und glaube du mal nicht, daß man mit einer maschinellen Umsetzung von TTF in kleine Pixelschriften wirkich gut fährt. Für TTF sind allemal bessere Grafikeigenschaften (höhere Auflösung und Grautöne bzw. Opazität) nötig, damit das gut aussieht. Sowas hat man bei einem monochromen 128x64 Display nicht. W.S.
die o.g. Website produziert die Fontdaten, auch die kleine Größe ist einstellbar und es kommt leserliches heraus. Natürlich sind die verschiedenen Styles dann nicht mehr sichtbar, aber immerhin. Wie aus der Tabelle dann die Glyphen zusammengesetzt werden steht im Code der Lib und die ist offen in Github. Die Zeichen werden in einen Buffer gerendert und der wird dann als Block oder bei dem kleinen SSD als Ganzes übertragen. Wenn man schon Routinen hat die das erledigen kann man die ja weiterbenutzen. Ich benutze die Lib auch nicht mit Arduino, das lässt sich schon auf andere OS oder Frameworks übertragen. Wenn der XMega in C programmiert wird ist es etwas aufwändiger das aus C++ herauszupulen, mit C++ ist es einfach schöner weil man mehrere Instanzen anlegen kann und das gleiche Interface für verschiedene Displays nutzen kann.
Ich habe jetzt Zeit gefunden, mich damit zu beschäftigen. Ich finde die Lösung mit dem "The Dot Factory" Generator genial. Genau sowas habe ich gesucht. Man kann dort Schriften von den Windows Fonts ziehen und noch Einstellungen vornehmen (gedreht usw). Das ist echt klasse. Mit meiner Funktion vom OLED draw_bitmap kann ich das problemlos darstellen. Ich schreibe mir jetzt noch eine Funktion wo ich die Schrift übergebe und der Rest dann selber im Hintergrund erfolgt. Aber der Ansatz ist da und damit kann ich bestens die Schriften erzeugen und nutzen. Vielen Dank für die Lösung !
Ich brauche doch noch einmal Hilfe. Mit den kleinen Schriften klappt das jetzt. Aber ab 7pt werden 2 Byte pro Zeile erzeugt. Als Beispiel hier 7pt Schrift "H":
1 | // @292 'H' (5 pixels wide)
|
2 | 0x3F, 0x80, // ####### |
3 | 0x04, 0x00, // # |
4 | 0x04, 0x00, // # |
5 | 0x04, 0x00, // # |
6 | 0x3F, 0x80, // ####### |
Wenn die 2. Zeile weglasse und ich nehme nur die erste, bekomme ich ein H wo oben ein Pixel fehlt. also addiere ich beide, passt das H. Das scheint bie der 7pt zu klappen. Wenn ich aber noch eins größer werde 8pt klappt das nicht mehr und bei 12pt habe ich 3 Bytes. Ich verstehe die Zuordnung der Bytes ehrlich gesagt nicht. Das nutzt nicht die 8px Höhe der Page. Kann mir da jmd. Tipp geben für die Umsetzung?
Korrektur/Nachtrag. Wenn ich vom o.g. Array das erste Byte nehme bekomme ich ein H dargestellt was unsymmetrisch ist. Oben fehlt eine Pixelreihe. Wenn ich das 2. Byte aufaddiere habe ich das selbe H nur das unten erst eine Reihe frei ist, dann die Pixel von der 0x80 kommen, also wie ein Doppelpunkt unter dem H. Was ich eigentlich bräuchte wäre, das 2. Byte an Bitstelle 0 setzen statt an Bitstelle 7. Mir ist nicht klar, wie ich das verarbeiten soll.
Settings: HeighY (Tightest), HeighX (Tightest). ORDER: LSB first, Flip/Rotate: 90, Generate Space Bitmap = YES Ich habe das eingestellt, damit scheint es zu funktionieren jetzt
Du solltest, damit Du siehst, was passiert, die Nullen nicht weglassen
1 | 0x3F, 0x80, // ####### 0011 1111 1000 0000 |
2 | 0x04, 0x00, // # 0000 0100 0000 0000 |
3 | 0x04, 0x00, // # 0000 0100 0000 0000 |
4 | 0x04, 0x00, // # 0000 0100 0000 0000 |
5 | 0x3F, 0x80, // ####### 0011 1111 1000 0000 |
Ein anderes Zeichen als ausgerechnet das symmetrische "H" wäre auch günstiger. Nimm mal ein "G" und poste das hier.
Tuffi schrieb: > Mir ist nicht klar, wie ich das verarbeiten soll. Was du immer mit Zeilen und dergleichen hast. Bei einem "Fußballfeld" von 128x64 Pixeln gibt es keine Zeilen. Und wenn der Font, den du dir ausgesucht hast, eben nur Daten im 8 Bit Raster kennt, dann wäre es für dich erstmal sinnvoll, das Texte gestalten und die verschiedenen Arten des Textschreibens auf einem Display etwas besser zu verstehen. Nur so, als Denkansaz: Es gibt (zumindest für europäische Schreibweise) eine gedachte Schreiblinie, wo die einzelnen Buchstaben draufstehen. Manche Buchstaben wie z.b. das 'g' gehen noch weiter nach unten, die Länge nach unten ist dann der Descent. Manche Buchstaben wie z.B. das 'h' und die Großbuchstaben gehen recht weit nach oben, das ist dann der Ascent. Aber oben drüber ist auf alle Fälle noch ein bissel Platz bis zur Zeile weiter oben. Alles zusammen ist dann die Fonthöhe, die eben auch diesen Platz mit einschließt. Und nun wunderst du dich, daß Fonts ab '7pt' mehr als 7 Pixel (vermutlich 9) belegen. Mich wundert das nicht, denn wenn der Font jeweils eine leere Pixelzeile oben und unten enthält als Abstand von den Nachbarzeilen und die Pixel immer in Stücken zu 8 Bit vorhält, dann braucht er eben 2 Byte für Fonts von 7pt bis 14pt, darüber hinaus dann 3 Byte usw. Das ist mMn. eine doch recht 'luftige' Weise, einen Font zu speichern. W.S.
Tuffi schrieb: > Was ich eigentlich bräuchte wäre, das 2. Byte an Bitstelle 0 setzen > statt an Bitstelle 7. Mir ist nicht klar, wie ich das verarbeiten soll. ein Verweise auf diese Lib wäre einfacher als dieses Ratespiel für die Zuschauer. Warum sind die Zeichen nicht frei positionierbar und warum ist die Zeichenbreite/höhe nicht einstellbar? Das sollte eine universelle Routine schon können. Die kleinen Displays kann man üblicherweise schnell beschreiben durch setzen eines Fensters, danach werden nur die Datenbytes nacheinander geschickt. Oder man baut zum Speicher sparen einen reinen Textmodus, dann braucht man nur Speicher für die Anzahl Zeichen die auf das Display passen sollen. Das ist aber unflexibler und bei den kleinen Oleds kostet ein Framebuffer für das ganze Display nur 1 kB, da ist eine beliebige Zeichenposition und Größe kein Problem. Also vielleicht erstmal analysieren wie die Lib arbeitet.
DerEgon schrieb: > Du solltest, damit Du siehst, was passiert, die Nullen nicht > weglassen > 0x3F, 0x80, // ####### 0011 1111 1000 0000 > 0x04, 0x00, // # 0000 0100 0000 0000 > 0x04, 0x00, // # 0000 0100 0000 0000 > 0x04, 0x00, // # 0000 0100 0000 0000 > 0x3F, 0x80, // ####### 0011 1111 1000 0000 > > Ein anderes Zeichen als ausgerechnet das symmetrische "H" wäre auch > günstiger. Nimm mal ein "G" und poste das hier. Ja habe ich dann auch gemerkt es steht auf dem Kopf. Es läuft jetzt im groben ich bin gerade dabei auch die fonts die aus mehr als 1byte bestehen noch zu verarbeiten dann posten ich die Bibliothek. Kann bestimmt auch jemand anderes verwenden.
Sodele. Das mit den Schriften funktioniert. Es ist wirklich so, wenn man komplett dynamisch sein will, muss man das mit dem Puffer machen und komplett übertragen, sonst hat man die Pages á 8 Bit. Schade iregndwie das die Controller das nicht selber umsetzen und man wie im Flash Baustein punktuell einen Pixel ansprechen kann.
Tuffi schrieb: > Schade iregndwie > das die Controller das nicht selber umsetzen und man wie im Flash > Baustein punktuell einen Pixel ansprechen kann. bei den größeren Farbdisplays ist das so, da braucht ein Pixel ja ein oder oder mehr Byte. Aber das pixelweise schreiben ist nicht effizient, es braucht ja jedesmal ein 'goto XY', wozu 7-8 Byte langsam übertragen werden müssen. Das Pixel setzen im internen SRAM des Controllers ist viel schneller, und wenn der Bereich dann noch per DMA rausgefeuert werden kann, dann kann die CPU schon wieder andere Dinge erledigen. Und Bereich löschen und Pixelweise drüberschreiben führt zu flackern wenn man es schnell zyklisch macht.
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.