Fonts beim GLCD Verständnisfrage

Marcel wrote:
> Hallo!
> Ich habe einen Font, der sich als Tabelle darstellt. In dieser Tabelle
> sind lauter Hex Zahlen. Kann mir jemand erklären wie sich diese
> Geschichte zusammensetzt?
> Beispiel:
>
> 0x7e,0x11,0x11,0x11,0x7e,0x00,
>
> soll 'A' bedeuten.
> Dank euch schonmal!

Schreibe es mal um in binär, schreibe es untereinander und schau Dir 
dann die Nullen und Einsen an. Jedes Bit jedes Bytes repräsentiert 
nämlich einen Pixel einer Grafik, die ganze Grafik bildet das Zeichen 
ab. Wie die Pixel des Zeichens organisiert sind, wirst Du dann schon 
sehen.

Falls Du das, was ich schrieb, nicht verstehst, dann schau Dir mal die 
Pixelmuster der Zeichensätze der Text-LCDs (in deren Datenblättern) an.

...

Marcel wrote:
> Hallo!
> Ich habe einen Font, der sich als Tabelle darstellt. In dieser Tabelle
> sind lauter Hex Zahlen. Kann mir jemand erklären wie sich diese
> Geschichte zusammensetzt?
> Beispiel:
>
> 0x7e,0x11,0x11,0x11,0x7e,0x00,
>
> soll 'A' bedeuten.
> Dank euch schonmal!

Probiers einfach mal aus und schreib die Zahle binär hin

0x7e     01111110
0x11     00010001
0x11     00010001
0x11     00010001
0x7e     01111110
0x00     00000000


Kannst du das 'A' im binären sehen?
Wenn nein: Ersetze mal alle 0 durch Leerzeichen und
alle 1 durch +

0x7e      ++++++
0x11        +   +
0x11        +   +
0x11        +   +
0x7e      ++++++
0x00

Jetzt sieht man es besser (Kopf drehen!)

> Ersetze mal alle 0 durch Leerzeichen und alle 1 durch +

Da wird auch gerne "o" und "_" genommen, lässt sich gut mit Define für C 
verfügbar machen.

1

#define ________ 0x00

2

#define _______o 0x01

3

#define ______o_ 0x02

4

#define ______oo 0x03

5

#define _____o__ 0x04

6

#define _____o_o 0x05

7

#define _____oo_ 0x06

8

#define _____ooo 0x07

9

#define ____o___ 0x08

10

#define ____o__o 0x09

11

#define ____o_o_ 0x0a

12

#define ____o_oo 0x0b

13

#define ____oo__ 0x0c

14

#define ____oo_o 0x0d

15

#define ____ooo_ 0x0e

16

#define ____oooo 0x0f

17

18

und so weiter...

Ein A könnte dann so definiert werden, wobei dieser Zeichensatz anders 
orientiert ist und variable Breite hat:

1

// 0x41 'A'    

2

  5,

3

    ________,

4

    __o_____,

5

    _o_o____,

6

    o___o___,

7

    o___o___,

8

    ooooo___,

9

    o___o___,

10

    o___o___,

11

    o___o___,

12

    ________,

13

    ________,

...

Hannes Lux wrote:
>> Ersetze mal alle 0 durch Leerzeichen und alle 1 durch +
>
> Da wird auch gerne "o" und "_" genommen, lässt sich gut mit Define für C
> verfügbar machen.
>
> #define ______ 0x00

:-)
Das hätte ich jetzt nicht von dir erwartet
:-)

Du wirst doch nicht etwa bekehrt werden

:-)

(Hab ich genug Smilies gesetzt?)

Karl heinz Buchegger wrote:
> Hannes Lux wrote:
>>> Ersetze mal alle 0 durch Leerzeichen und alle 1 durch +
>>
>> Da wird auch gerne "o" und "_" genommen, lässt sich gut mit Define für C
>> verfügbar machen.
>>
>> #define ______ 0x00
>
> :-)
> Das hätte ich jetzt nicht von dir erwartet
> :-)
>
> Du wirst doch nicht etwa bekehrt werden

Neeeeiiiinnnnnnn, niiiiieeemals niiieee nicht...

Aber man darf doch mal über'n Zaun schaun, oder?


>
> :-)
>
> (Hab ich genug Smilies gesetzt?)

Die hast Du doch nicht nötig...

...

T.S. wrote:
>> #define ____ 0x00
> Erwischt. Mein Zeichensatz gefällt Dir also doch. ;)

Ja aber sicher doch. Und wenn ich #define durch .equ ersetze, dann geht 
das auch hervorragend in ASM. Aber was erzähle ich Dir das, Du kannst 
ASM ja besser als ich... ;-)

Ja, er gefällt mit, sonst hätte ich keine Auszüge daraus hier als 
Beispiel gebracht. Die kompletten Dateien gibt es von mir allerdings 
nicht, das steht mir nicht zu, ich muss mich nicht mit anderer Leute 
Arbeit wichtig machen.

Dass ich den Zeichensatz nicht "benutze", hat ja damit zu tun, dass ich 
im momentanen Projekt die Zeichen anders verschachtelt brauche. Ich 
halte es aber durchaus für möglich, dass ich mir mal in QBASIC ein 
Programm schreibe, dass mir die Bytes dieses Zeichensatzes umsortiert. 
Wobei es durchaus sein kann, dass ich ihn auf einem GLCD mal benutze. 
Das liegt aber vorläufig nicht an.

>
>> Du wirst doch nicht etwa bekehrt werden
> Mit Engelszungen habe ich versucht ihn zu überreden wenigstens mal
> "hello world" in C auszuprobieren. Keine Chance. Ich hätte auch aus dem
> Fenster "kuckuck" rufen können.

Genau, denn meine Projekte lassen sich verdammt gut mit ASM lösen. 
Trotzdem schau ich bei C nicht weg, wenn ich die Zeit dazu habe. Aber 
noch bin ich nicht soweit, damit zu beginnen, ich habe es auch nicht auf 
der ToDo-Liste.

>
> Eines Tages beim Besuch habe ich den K&R auf dem Tisch gesehen...

Na auf dem Tisch nun nicht gerade, aber doch in Reichweite. Das Bienchen 
kann sich aber unser Kieler Mechatronik-Ing. (der auch im Besitz 
mindestens eines STK500 ist und manchmal recht trollig daherkommt) 
eintragen lassen. Es schadet nicht, bei diversen C-Fragen mal 
nachschlagen zu können.

> Karl
> Heinz, gib ihm einen kleinen Schubs, auf mich hört Hannes nicht mehr.

Ich glaub' Karl Heinz kann nachvollziehen, warum ich in ASM werkele. Er 
liest in meinen Programmen ja nicht nur die ASM-Mnemonics, sondern auch 
die Kommentare.

> :-)
>
> Torsten

Bit- & Bytebruch, bis zum nächsten Käffchen...
Hannes

Hannes Lux wrote:

> Genau, denn meine Projekte lassen sich verdammt gut mit ASM lösen.
> Trotzdem schau ich bei C nicht weg, wenn ich die Zeit dazu habe.

Das ist die richtige Einstellung.
Ich krieg regelmässig das Kotzen, wenn wieder mal wer antwortet:

<Regieanweisung: In weinerlicher Stimme vortragen>

Ich kann aber kein C, ich kann aber kein Assembler. Dein Link/
dein Beispiel ist für mich nutzlos, weil ich die Sprache nicht
verstehe.

Anmerkung des Verfassers: Dabei handelt es sich oft um das Setzen
von ein paar Bits in irgendwelchen CPU Registern. Völlig Wurscht
ob das in Assembler oder in C gemacht wird, es sind immer beteiligt:
der Name des Registers, der Bitname und natürlich das Verständnis
warum ausgerechnet dieses Bit gesetzt werden muss. Und gerade bei
letzterem scheiden sich dann die Geister. Die einen, die sich
beschweren, sind diejenigen, die einfach nur Code haben wollen,
den sie mit Cut&Paste in ihr Programm übernehmen können (was
oft sowieso so nicht funktioniert) ohne zu verstehen was sie
tun. Das sind dann diejenigen mit dem 'Ich kann kein Assembler/C'
Defekt. Die anderen denken sich: so schwer kann das auch nicht sein,
soviel werde ich schon verstehen, dass ich das Prinzip heraushole
und das setze ich dann in meiner Lieblingssprache um.

Und das ginge sogar alles auch in BASCOM, wenn die BASCOM-Nutzer nicht 
durch irrsinnige Config-Anweisungen vom Lesen der Datenblätter 
abgehalten würden...

Noch mache ich meine AVR-Programmierung mit einem 233er MMX. Wenn ich da 
noch C installiere, dann kommt der beim Starten von AVR-Studio gar nicht 
mehr aus dem Knick. Beim nächsten Rechner sehe ich das evtl. anders.

...