Zeichensätze für DOGXL240

[Rudolph (Gast)]

Hi,

ich habe hier ein DOGXL240 und suche hier schon seit Stunden 
Zeichensätze die ich damit verwenden könnte.

Es gibt hier ein super Archiv unter 
Beitrag "LCD Schriftarten ( Fonts in veschiedenen Größen )".

Nur wie ich dort gerade gepostet haben scheinen die grösseren 
Vertikal-Fonts defekt zu sein.

Ich suche Zeichensätze in 8x16 und 24x32.
Oder auch 10x16.
Vorzugsweise als zwei-dimensionales Array.

Irgendwie finde ich fertig nur horizontal angeordnete Zeichensätze.

[Karl H. (kbuchegg)]

Ich hab mir hier aus dem Forum einen Font-Editor geholt, mit dem ich mir 
meine Fonts aus Windows-Fonts selbst erzeuge. Brauch ich sowieso, weil 
ich ein paar Sonderzeichen brauche, die in einem normalen Font nicht 
drinn sind.
Ausserdem geht es schneller als stundenlang nach Fonts suchen, für die 
man dann sowieso erst recht wieder eigene Anzeigeroutinen schreiben 
muss.

Hier die Routine, mit der ich dann einen einzelnen Buchstaben Pixel für 
Pixel hinmale. Leerzeichen werden extra behandelt, weil sie in den 
Fontdaten nicht drinnen sind.

// Das Header File wird vom FontTool erzeugt
#include "../Font/Trebuchet_20.h"

struct fontDesc_t* pFontDesc = &Trebuchet_20_Desc;

int LCDDrawChar( int left, int top, char c )
{
  int heightInPixel = pFontDesc->heightInPixel;
  int widthInPixel;
  int i;
  int firstPixelBitPos;
  unsigned char cu = (unsigned char)c;
  unsigned char* pDataStart = &(pFontDesc->pData)[pFontDesc->lastChar - pFontDesc->firstChar + 1];

  if( c == ' ' ) {
    BSP_LCD_SetFillColor( (uint32_t)0xFFFFFFFF );
    LCDFillRect( DISPLAY_OFFSET_X + CursorX * CellSizeX, DISPLAY_OFFSET_Y + CursorY * CellSizeY,
                 CellSizeX+1, CellSizeY+1 );
    return 3;
  }

  if( cu < pFontDesc->firstChar || cu > pFontDesc->lastChar )
    cu = '?'; // Assume exists everywhere

  cu -= pFontDesc->firstChar;

  widthInPixel = pFontDesc->pData[cu];

  // locate data bytes by summing up all the width of the previous characters
  // starting at the beginning of the data location
  firstPixelBitPos = 0;
  for( i = 0; i < cu; i++ )
    firstPixelBitPos += pFontDesc->pData[i];
  firstPixelBitPos *= heightInPixel;

  LCDRenderFontData( left, top, pDataStart, firstPixelBitPos, widthInPixel, heightInPixel );

  return widthInPixel;
}

void LCDRenderFontData( int x, int y, unsigned char* pDataStart, int firstPixelBitPos, int widthInPixel, int heightInPixel )
{
  int i;
  int top = y;

  for( i = 0; i < widthInPixel * heightInPixel; i++ ) {
    int bytePos = firstPixelBitPos / 8;
    int bitPos  = firstPixelBitPos % 8;

    if( ( pDataStart[bytePos] & ( 1 << bitPos) ) && BSP_LCD_GetTextColor() != LCD_COLOR_TRANSPARENT )
      LCDDrawPixel( x, y, BSP_LCD_GetTextColor() );
    else if( BSP_LCD_GetBackColor() != LCD_COLOR_TRANSPARENT )
      LCDDrawPixel( x, y, BSP_LCD_GetBackColor() );

    firstPixelBitPos++;
    y++;
    if( y == top + heightInPixel ) {
      y = top;
      x++;
    }
  }
}

Edit:
Ist für einen STM32, daher der recht freizügige Umgang mit 'int'. Auf 
einem AVR würde ich das nicht so machen.

[Rudolph (Gast)]

Okay, den 10x16 habe ich am Laufen, einfach mal falsch interpretiert wie 
die Daten im Array abgelegt sind.

Aber abwechselnd die beiden Zeilen des Zeichens passt so überhaupt nicht 
zu einer halbwegs effizienten Ausgabe.

Hat dann noch mal bitte jemand einen 24x32 Zeichensatz für mich?
Oder ein Idee, womit ich das 22x36.bmp konvertieren könnte?

[Rudolph (Gast)]

Karl H. schrieb:
> Ich hab mir hier aus dem Forum einen Font-Editor geholt, mit dem ich mir
> meine Fonts aus Windows-Fonts selbst erzeuge.

Den habe ich mir gerade angesehen, danke.
Verstehen tue ich das Ding allerdings nicht.

Irgendwie kann ich aus dem Teil heraus nicht exportieren.
Und wie bei allen Font-Importern die ich bisher gesehen habe kommt 
irgendwas unkontrollierbarers in Beziehung auf die X-Y Grösse dabei 
raus.

Font.exe kann nur mit .font Dateien arbeiten und Convert.exe kommt nur 
mit Grafik-Dateien klar und lässt sich nicht einstellen.

[Karl H. (kbuchegg)]

Rudolph schrieb:

> Irgendwie kann ich aus dem Teil heraus nicht exportieren.

Font.exe:

"import Font"
Font einstellen, Größe und sonstiges einstellen

"export Font"
Filenamen angeben

Fertig.

> Und wie bei allen Font-Importern die ich bisher gesehen habe kommt
> irgendwas unkontrollierbarers in Beziehung auf die X-Y Grösse dabei
> raus.

Ja, das ist leider ein Problem. Ich hab dann halt einfach mit der 
Windows-Font Größe gespielt, bis ein 'A' die Pixelgröße hat, die ich 
haben will. Geht ja schnell. Und hat man denn erst mal eine brauchbare 
Größe gefunden, dann funktioniert die auch mit anderen Font-Formen. 
Dafür hab ich allerdings einen riesigen Pool an fertigen Font-Daten für 
alle denkbaren Verwendungszwecke.

Aber ok. Wenn du nicht willst, dann eben nicht.
Ich seh die Sache halt so, dass ich anstelle stundenlang nach etwas zu 
suchen, was ich nicht finde, lebe ich lieber mit einer Krücke und 
schreib mir halt die dazu passenden Ausgabe-Routinen schnell selber. 
Wozu bin ich Programmierer? Mit der gesparten Zeit spiele ich lieber rum 
und seh mir an, wie die Maschinensteuerung mit einem Western-Font 
aussieht oder ob doch etwas mehr futuristisches Eindruck schindet.

[Rudolph (Gast)]

Karl H. schrieb:
>> Irgendwie kann ich aus dem Teil heraus nicht exportieren.
>
> Font.exe:
>
> "import Font"
> Font einstellen, Größe und sonstiges einstellen
>
> "export Font"
> Filenamen angeben
>
> Fertig.

Hmm, ja, und dann?
Damit bekomme ich als Ergebnis eine .font Datei mit der ich nichts 
weiter machen kann.

[Rudolph (Gast)]

Ah, moment, die .h wird auch noch generiert, nur ohne jedes Feedback.
Sind die Daten da drin jetzt horizontal oder vertikal?

[Karl H. (kbuchegg)]

Rudolph schrieb:
> Ah, moment, die .h wird auch noch generiert, nur ohne jedes Feedback.
> Sind die Daten da drin jetzt horizontal oder vertikal?

Die Daten da drinn sind so drinnen, wie du sie ausgibst.

WEnn du
    putpixel( x, y );
machst, dann eben vertikal (oder horizontal, je nach Sichtweise)
WEnn du
    putpixel( y, x );
machst, dann in der anderen Richtung.


Das ist das schöne am selberschreiben. Man kann sich das alles anpassen.

(Die Bits sind so angeordnet, dass die Buchstaben Spalte für Spalte von 
oben nach unten bearbeitet werden. Was du dann daraus machst, ist aber 
eine andere Sache. Koordinaten zu tauschen ist ja nicht das grosse 
Problem. Und ja, eines der 'Problemkreise' ist, dass ein Font, der sich 
mit einer Höhe von 14 Pixel identifiziert dann auch tatsächlich alle 14 
Bits einen Spaltenwechsel macht. Die Fonts sind spaltenweise nicht auf 
Bytegrenzen ausgerichtet. Für mich spielte das keine grosse Rolle, weil 
ich keine Mördertexte ausgeben muss. Für ein paar Beschriftungen im 
überschaubaren Rahmen ist das schnell genug.

Wenn es ein Problem wäre, dann würde ich den Font mit einem weiteren 
Tool vorverarbeiten, so dass mir der fertig aufs LCD klatschbare Bytes 
generiert. Dadurch verliere ich dann allerdings auch die einfache 
Möglichkeit, einen Buchstaben an jede beliebige Pixelposition 
hinzusetzen. Aber ich gebe auch zu, dass ich in dieser Beziehung sowieso 
eigen bin - ich schrecke nicht davor zurück mir für ein Projekt die 
entsprechenden Daten-Konverter notfalls auch selbst zu programmieren.

[Rudolph (Gast)]

Karl H. schrieb:
> Die Daten da drinn sind so drinnen, wie du sie ausgibst.

Ist ja richtig, das Display will das aber vertical haben.
Wenn der Controller das auch noch on-the-fly von horizontal auf vertikal 
umbauen muss, dann ist der ja quasi nur noch damit beschäftigt.

Und auch noch sinnlos beschäftigt weil die Daten ja an sich statisch 
sind.

[Karl H. (kbuchegg)]

Rudolph schrieb:
> Karl H. schrieb:
>> Die Daten da drinn sind so drinnen, wie du sie ausgibst.
>
> Ist ja richtig, das Display will das aber vertical haben.
> Wenn der Controller das auch noch on-the-fly von horizontal auf vertikal
> umbauen muss, dann ist der ja quasi nur noch damit beschäftigt.
>
> Und auch noch sinnlos beschäftigt weil die Daten ja an sich statisch
> sind.

Soll ich dir einen Converter schreiben?

Die pixelbasierte Routine ist ja schon vorhanden. Da noch eine Funktion, 
die die Pixel für einen Character in ein 2D Array 'rendert' und die so 
entstandenen Bytes auf ein neues File (fertig aufbereitet für einen 
#include) schreibt, ist doch jetzt nicht wirklich das Problem?

Man merkt, ich werde alt.

[Michael U. (amiga)]

Hallo,

@ Karl Heinz: bei mir endet sowas immer so: da ich einen lokalen 
Webserver aus anderen Gründen parat habe und da am wenigsten nachdenken 
muß, gibt es schell ein PHP-Script, das die Daten eben umsortiert. Das 
(jetzt ohnehin seit Jahren vorhandene) ist meist in 15 Minuten und einem 
Fehlversuch erledigt.

Wenn da nichts vorhanden ist, würde es wohl der gerade genutzte AVR mit 
seriellen Schnittstellen und einem Terminalprogramm erledigen müssen...
Font in den Flash, Konvertierung geschrieben, testweise gleich auf dem 
Zieldisplay angezeigt und per seriellen, Terminalprogram, Datei 
gespeichert.

Gruß aus Berlin
Michael

[Karl H. (kbuchegg)]

Michael U. schrieb:
> Hallo,
>
> @ Karl Heinz: bei mir endet sowas immer so: da ich einen lokalen
> Webserver aus anderen Gründen parat habe und da am wenigsten nachdenken
> muß, gibt es schell ein PHP-Script, das die Daten eben umsortiert.

Bei mir ist es nicht PHP sondern C++ oder C. Und das auch nur deshalb 
weil ich da einfach die letzten 20 Jahre drinn gearbeitet habe. Sonst 
wärs eben die Sprache oder das Tool mit dem ich am besten umgehen kann.
Ergo: selbes Prinzip.



> Das
> (jetzt ohnehin seit Jahren vorhandene) ist meist in 15 Minuten und einem
> Fehlversuch erledigt.

Yup. Genau so siehts aus.
Und das beste daran: je mehr man programmiert und je mehr Tools man sich 
selber macht, desto besser wird man. Übung macht eben den Meister. Ich 
hab mir meine Fertigkeiten auch nicht über Nacht angeeignet. Vielleicht 
habe ich gerade deshalb wenig Verständnis dafür, dass jemand stundenlang 
das Web nach einfachen Werkzeugen absucht, die er leicht in längstens 1 
Stunde selbst machen kann.

[Rudolph (Gast)]

Och, wenn Ihr Spass dran habt. :-)

Nein, im Ernst, der 10x16 läuft ja und zwar unkompliziert.
Der wird einfach aus dem FLASH ins Display geschrieben.

Dazu bin ich gerade dran mit der 22x36 davon noch zu konvertieren.
Auch alleine schon weil der dazu passt.

Ohne die Software die Benedikt zum Konvertieren benutzt hat wird das
aber noch ganz schön anstrengend.
Wenigstens brauche ich lange nicht alle Zeichen, im wesentlichen die 
Zahlen.

[Rudolph (Gast)]

Hier, nicht immer nur nehmen, sondern auch mal was geben. :-)

Das sind die Zahlen von 0..9 und ein Punkt als 20x32, angeordnet wie das 
DOGXL240 das haben möchte.

Konvertiert aus dem Bild eins weiter oben das aus dem Archiv stammt im 
Beitrag den ich Eingangs verlinkt habe.

[W.S. (Gast)]

Karl H. schrieb:
> Hier die Routine, mit der ich dann einen einzelnen Buchstaben Pixel für
> Pixel hinmale.

Au weia, warum einfach, wenn es auch kompliziert geht?

Zum einen sieht dein Buchstaben-Hinmale-Routine reichlich wirr aus, zum 
anderen scheinen mir die Fonts von H.Reddmann recht unüberlegt gemacht 
zu sein, siehe dort:

struct fontDesc_t {
  unsigned int   totalSize;
  unsigned char  widthInPixel;
  unsigned char  heightInPixel;
  unsigned char  bitsPerPixel;
  unsigned char  firstChar;
  unsigned char  lastChar;
  unsigned char* pData;
};

Das heißt im Klartext, daß man nur feste Breiten hat, dafür aber 
BitsPerPixel, also Farbangaben - die nun wirklich nicht in einen Font 
hineingehören.


Rudolph schrieb:
> Hat dann noch mal bitte jemand einen 24x32 Zeichensatz für mich?

Fertig zum Sich_ins_gemachte_Bett_legen? Nö.
Aber wenn du mal in die (mittlerweile steinalte) Lernbetty hier im Forum 
hineinguckst, dann findest du dort sowohl Fonts, als auch nen kleinen 
Fontcompiler als auch das dazu passende GDI. Und die Fonts können je 
nach Gusto feste Breite haben als auch proportional sein.

Ich häng dir mal was zum Ansehen dran. Das GDI ist für Monochrom, in der 
Lernbetty findest du ein kompatibles für 4 Graustufen und die 
Erweiterung auf Farben sollte damit ein Leichtes sein.

W.S.

[Rudolph R. (rudolph)]

W.S. schrieb:
> Rudolph schrieb:
>> Hat dann noch mal bitte jemand einen 24x32 Zeichensatz für mich?
>
> Fertig zum Sich_ins_gemachte_Bett_legen? Nö.

Tja, schade, die Idee war einfach das Rad nicht wiederholt neu zu 
pixeln.

> Aber wenn du mal in die (mittlerweile steinalte) Lernbetty

In was bitte?

> hier im Forum hineinguckst, dann findest du dort sowohl Fonts,
> als auch nen kleinen Fontcompiler als auch das dazu passende GDI.
> Und die Fonts können je nach Gusto feste Breite haben
> als auch proportional sein.

Und wo bitte? Die Vielfalt hier wird langsam etwas unübersichtlich und 
schwieriger zu durchsuchen. Kann gut sein, dass ich was übersehen habe.

Ausserdem habe ich ausdrücklich für das DOGXL240 gesucht, das hat 
entgegen den scheinbar meisten anderen Displays und so BIOS-Fonts die 
Anordnung vertikal und nicht horizontal.

> Ich häng dir mal was zum Ansehen dran. Das GDI ist für Monochrom, in der
> Lernbetty findest du ein kompatibles für 4 Graustufen und die
> Erweiterung auf Farben sollte damit ein Leichtes sein.

Danke, aber weder suche ich Grafik-Routinen, noch brauche ich Farbe.
Das DOGXL240 ist einfach nur ein Monochrom-Display.

Das FM.exe in dem Archiv macht scheinbar garnichts.
"Das war's.   ...enter"

Einzelne Pixel kann ich auch nicht setzen, ich habe keinen Abbild des 
Displays im Controller und per SPI kann man das nur beschreiben.

Aber naja, eigentlich bin ich ja fertig.
Der Zeichensatz könnte nur etwas schicker aussehen, gerade auch der 
10x16.

[spess53 (Gast)]

Hi

>Ausserdem habe ich ausdrücklich für das DOGXL240 gesucht, das hat
>entgegen den scheinbar meisten anderen Displays und so BIOS-Fonts die
>Anordnung vertikal und nicht horizontal.

Nein. Bei den monochromen grafischen Displays ist die vertikale 
Ausrichtung eindeutig in der Überzahl. Allerdings hast du den Fehler 
gemacht, nach Fonts für das DOGXL240 zu suchen. Das dürfte einen 
geringen kleinen Anteil aufweisen.
Sinnvoller wäre eine Displaycontrollerspezifische Suche gewesen. 
Bekannte Controller in dieser Richtung wären SED1520, HD61202, KS0108B, 
... . Noch mehr findest du hier:

http://www.lcd-module.de/datenblaetter.html

MfG Spess

[Martin J. (bluematrix)]

... dieses Display funktioniert so wie deins.
- monochromen grafischen Displays
- vertikale Ausrichtung (1 Byte = 8 Pixel vertikal = 1 Zeile)
http://www.jtronics.de/avr-projekte/display-nokia3310.html

[Rudolph R. (rudolph)]

spess53 schrieb:
> Allerdings hast du den Fehler gemacht, nach Fonts für das DOGXL240
> zu suchen.

Nee, ich habe nur hier ausdrücklich danach gefragt, aber sonst mit 
diversen Stichwörtern rauf und runter gesucht.

8x16 ist offenbar zu spezifisch.

Und kleine Fonts habe ich auch genug gefunden.