Zeichensätze für DOGXL240

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.

1

// Das Header File wird vom FontTool erzeugt

2

#include "../Font/Trebuchet_20.h"

3

4

struct fontDesc_t* pFontDesc = &Trebuchet_20_Desc;

5

6

int LCDDrawChar( int left, int top, char c )

7

{

8

  int heightInPixel = pFontDesc->heightInPixel;

9

  int widthInPixel;

10

  int i;

11

  int firstPixelBitPos;

12

  unsigned char cu = (unsigned char)c;

13

  unsigned char* pDataStart = &(pFontDesc->pData)[pFontDesc->lastChar - pFontDesc->firstChar + 1];

14

15

  if( c == ' ' ) {

16

    BSP_LCD_SetFillColor( (uint32_t)0xFFFFFFFF );

17

    LCDFillRect( DISPLAY_OFFSET_X + CursorX * CellSizeX, DISPLAY_OFFSET_Y + CursorY * CellSizeY,

18

                 CellSizeX+1, CellSizeY+1 );

19

    return 3;

20

  }

21

22

  if( cu < pFontDesc->firstChar || cu > pFontDesc->lastChar )

23

    cu = '?'; // Assume exists everywhere

24

25

  cu -= pFontDesc->firstChar;

26

27

  widthInPixel = pFontDesc->pData[cu];

28

29

  // locate data bytes by summing up all the width of the previous characters

30

  // starting at the beginning of the data location

31

  firstPixelBitPos = 0;

32

  for( i = 0; i < cu; i++ )

33

    firstPixelBitPos += pFontDesc->pData[i];

34

  firstPixelBitPos *= heightInPixel;

35

36

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

37

38

  return widthInPixel;

39

}

40

41

void LCDRenderFontData( int x, int y, unsigned char* pDataStart, int firstPixelBitPos, int widthInPixel, int heightInPixel )

42

{

43

  int i;

44

  int top = y;

45

46

  for( i = 0; i < widthInPixel * heightInPixel; i++ ) {

47

    int bytePos = firstPixelBitPos / 8;

48

    int bitPos  = firstPixelBitPos % 8;

49

50

    if( ( pDataStart[bytePos] & ( 1 << bitPos) ) && BSP_LCD_GetTextColor() != LCD_COLOR_TRANSPARENT )

51

      LCDDrawPixel( x, y, BSP_LCD_GetTextColor() );

52

    else if( BSP_LCD_GetBackColor() != LCD_COLOR_TRANSPARENT )

53

      LCDDrawPixel( x, y, BSP_LCD_GetBackColor() );

54

55

    firstPixelBitPos++;

56

    y++;

57

    if( y == top + heightInPixel ) {

58

      y = top;

59

      x++;

60

    }

61

  }

62

}

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

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

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.

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.

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

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.