Display: Unterschied zwischen character mode und graphic mode?

[myuser (Gast)]

Hallo,

ich habe ein OLED-Display EA W162-X9LG:
http://cdn-reichelt.de/documents/datenblatt/A400/DS_OLED_EA.pdf

In dem Datenblatt gibt es eine Tabelle zum Befehlssatz. Dort steht, dass 
ich zwischen character mode und graphic mode wählen kann. Was ist der 
Unterschied zwischen diesen beiden Modi?

[Sascha W. (sascha-w)]

Hallo,

ohne jetzt speziell auf dein Display einzugehen.
Im Charachtermode, gibt das Display automatisch Zeichen aus einem 
internen Zeichensatz an von der Zeichengröße vorgegebenen Positionen 
aus. Das scheinen bei dir 2 Zeilen a 16 Zeichen zu sein (mal aus der 
Bezeichnung abgeleitet). Dem Controller gibst du dabei die Position vor 
(X und Y) und das Zeichen (z.B. 'A').
Im Grafikmode kannst/musst du jedes Pixel einzeln setzen somit kannst du 
dort alles darstellen was du willst. Auch da kannst du Text erzeugen 
musst den Zeichensatz dazu aber in deinem Controller vorhalten.

Sascha

[Jakob (Gast)]

Ein Blick in das angegebene Datenblatt zeigt:
Richtiger Grafik-Mode IST NICHT.

Wie bei den üblichen 44780-LCD-Displays, gibt es hier 8
"Character", die man als 5x7-Pixel selbst definieren kann.

Das Sinus-Bildchen auf der 1. Seite oben-Mitte ist schon das
Maximum der "GRAFIK"-Fähigkeiten. mit 7 verschieden hohen
"Säulen".

Oha, da bleibt noch ein selbst zu definierender "Character"
übrig, da die Höhe NULL auch mit SPACE darstellbar ist! ;-)

[Karl B. (gustav)]

Jakob schrieb:
> Ein Blick in das angegebene Datenblatt zeigt:
> Richtiger Grafik-Mode IST NICHT.
>
> Wie bei den üblichen 44780-LCD-Displays, gibt es hier 8
> "Character", die man als 5x7-Pixel selbst definieren kann.
>
> Das Sinus-Bildchen auf der 1. Seite oben-Mitte ist schon das
> Maximum der "GRAFIK"-Fähigkeiten. mit 7 verschieden hohen
> "Säulen".
>
> Oha, da bleibt noch ein selbst zu definierender "Character"
> übrig, da die Höhe NULL auch mit SPACE darstellbar ist! ;-)

Hallo,
probier mal das zum Test:

Was siehst Du?

(Beim Attiny2313 den SPH -String ausremmen)

ciao
gustav

Neue Zeichen werden durch den Display Clear Befehl beim nächsten Start 
gelöscht und müssen neu erzeugt werden.

[Jakob (Gast)]

@ Karl B. (gustav)

Hm, deinen ganzen Assembler-Code habe ich jetzt nicht durchgeackert.

Berichtige mich bitte, wenn ich danebenliege:

Wechselst du während der Ausgabe mal schnell die "User-Defined
Characters" aus, um damit auf mehr als 8 darstellbare "User-Defined-
Characters" zu kommen? - Hab ich noch nie probiert.

Klappt das?

Auf deinem Bild sind nur 8 "ungewöhnliche" Zeichen sichtbar.
Das geht ohne Trick. - Ist kein Beweis.

Wie kommt man damit dem angedeuteten Grafik-Mode näher???

[Jakob (Gast)]

P.S.

Beim Sinus-Bildchen bleiben sogar ZWEI selbst definierbare
Zeichen übrig: Die maximale Säule gibt es schon bei Ausgabe
0xFF = 255.

[gustav (Gast)]

Jakob schrieb:
> Wechselst du während der Ausgabe mal schnell die "User-Defined
> Characters" aus, um damit auf mehr als 8 darstellbare "User-Defined-
> Characters" zu kommen? - Hab ich noch nie probiert.

Das geht.
Aber nur mit den jeweils aufzurufenden Routinen.
Nochmals: Das CharakterROM hat unten noch freie Adressen (kommt davon, 
dass ASCII-Fernschreibcode erst bei höheren Zahlen anfängt.)
Mehr als 8 Zeichen geht nicht, weil die Adressierung dann in einen 
anderen Befehlsmodus wechselt:
Datenblatt:

DB7 DB6 DB5  DB4  DB3 DB2  DB1  DB0

L    H   X    X    X   X    X    X   Set CGRAM Adress

also Code: ldi temp, 0b01000000   (oder 0x40)
dann Kommando an Display
also RS-Bit auf Low und ein Enableimpuls
So, jetzt ist das Display im User-Defined Character mode und wartet auf 
weitere Eingaben.

Jetzt kommt's: Das ist im Datenlatt garnicht oder nur unzulänglich 
erklärt.

Jetzt gehe ich wieder mir RS auf high in den Datenübernahmemodus und 
gebe
meine Pixelwerte ein.
Im einfachsten Falle:
ldi temp, 0xFF
Daten-an-LCD-Routine (RS auf high, Enableimpuls)
..
..
..
achtmal dasselbe


Dieser Charakter gibt mir einen vollen schwarzen Balken aus und ist im 
Programm dann mit ldi temp, 0x00 in der Datenausgaberoutine aufrufbar.
Sonst kann ich ja Charakters direkt ausgeben z, B. ldi temp, 'A'
Jetzt muss man die Nummer direkt angeben, also 0x00, 0x01, bis 0x07

Vorsicht Falle:
Charakter 0x01 wird jetzt so programmiert: Set CGRAM = 0x40 plus 8
0x48 weil ich die Routine ja achtmal durchlaufe.
entsprechend für
0x02 = 50
0x03 = 58
0x04 = 60
0x05 = 68
0x06 = 70
0x07 = 78
mehr geht nicht, weil die 80 ja schon einen anderen Befehlsmodus 
aufrufen würde.

ciao
gustav

[Karl B. (gustav)]

....
wichtig ist auch noch, dass richtig initialisiert wird. D.h.
die Init-Routine könnte (stark verkürzt) so aussehen:
30
30
30
20
28
08
01
06
10
0C
01

Dann sollte möglichst zur Sicherheit noch vor der Charakter-Ausgabe eine 
Positionierungsangabe erfolgen.

Die Pixelei:
siehe angehängtes Bildchen (uups. dupliziert)


ciao
gustav

[spess53 (Gast)]

Hi

>Das geht.
>Aber nur mit den jeweils aufzurufenden Routinen.

Was hat das mit einem Grafik-Mode zu tun? Das sind ganz normale 
Funktionen des HD44780.

Leider schweigt sich EA über den Typ des Display-Controllers aus. Mit 
den Angaben aus dem Datenblatt kann man nicht viel anfangen.

@ gustav (Gast)

Deine Programme scheinen genauso ausufernd zu sein wie deine 
Ausführungen hier im Forum. Deine 'userdefchars.asm' kann man problemlos 
auf die Hälfte bis ein Drittel eindampfen.

MfG Spess

[Karl B. (gustav)]

Jakob schrieb:
> Wechselst du während der Ausgabe mal schnell die "User-Defined
> Characters" aus, um damit auf mehr als 8 darstellbare "User-Defined-
> Characters" zu kommen? - Hab ich noch nie probiert.

Das sollte beantwortet werden.
Da ist noch ein Fehler drin. Ich gehe vom Proggi aus, wo die Adressen 
"automatisch" (im Z-Pointer) mit temp2 hochgezählt werden.
Für jede Zeile also eine extra Adressenangabe und eine 
Pixel-Daten-Eingabe.


Hatte schon gedacht, dass das Prog irgendwie noch verschlankt werden 
kann.
Vorher war es noch größer, da hatte ich pro Charakter noch eine extra 
Printschleife drin. (das Label Print_01 kann auch noch raus, sorry...)

Alles auf eine lpm- zurechtzustutzen geht deswegen nicht, weil ich 
einmal nullterminierte Tabelle für den "Normaltext" in Zeile 1 nehme, 
zum andern ja die Null darstellen muss, und dabei noch ein paar Befehle 
mehr brauche um die Schleife achtmal bei Adresseninkrement zu 
durchlaufen.

Wie sieht Dein Assemblerprogramm denn aus?

ciao
gustav

[Karl B. (gustav)]

Gefällt's Ihro Gnaden @Spess jetzt besser?

(grins...das läuft sogar....)

ciao bello
gustav

[spess53 (Gast)]

Hi

>(grins...das läuft sogar....)

Sicher? Beispiel:

Verzoegerung2:  
push temp
push temp1
push temp2
in temp, SREG
push temp
ldi zeit, 0xFF
ldi zeit1, 0x20
;
Verz_Schleife2:
dec  zeit
cpi  zeit,  1
brlt Verz_Schleife2
ldi  zeit, 0xFF
dec  zeit1
cpi  zeit1,  1
brlt Verz_Schleife2
pop temp
out SREG, temp
pop temp2
pop temp1
pop temp 
ret

Da 0xFF..0x80 kleiner als 1 (-1..-128) sind wird nur einmalig zeit bis 
0x7F (127) herunter, eigentlich hoch, gezählt und danach die Routine (da 
0x20>1)verlassen. Ist das so gewollt?

Das Sichern der temp-Register ist eh Unsinn, da sie nicht benutzt 
werden. Für SREG gilt ähnliches.

lpm          ; erstes Byte des Strings nach R0 lesen
...
mov  temp,  r0

Alle aktuellen AVRs beherrschen

lpm register (Register r0..r31)

Das waren nur zwei Beispiele. Es gibt noch mehr. Wäre für mich kein 
Grund zum Grinsen.

MfG Spess

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Und hier noch eine universelle Delayschleife nach Steve Wozniak:

.def  del  = r18  ; delay counter
; steve wozniak's wait routine - this time for AVR 
; this is the extended routine with del^3 
; this wait routine is ingenious and handles wide ranges of delay 
; as a hommage to steve i port it to all my embedded systems. 
wozwait: push  del
wwait2:  push  del
wwait1:  subi  del,1  
         brne  wwait1
         pop  del
         subi  del,1
         brne  wwait2
         pop  del
         subi  del,1
         brne  wozwait
         ret

Aufruf mit einen beliebigen Wert in 'del' (R18) - je grösser, desto 
länger das Delay. Ich klingel die benötigten Zeiten pro Taktfrequenz 
einmal mit dem Simulator aus.

[spess53 (Gast)]

Hi

>Und hier noch eine universelle Delayschleife nach Steve Wozniak:
>...

Der grundlegende Fehler bei Karl B. (gustav) ist die Verwendung von 
signed Befehlen (brlt) auf unsigned Operanten.

MfG Spess

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

spess53 schrieb:
> Der grundlegende Fehler bei Karl B. (gustav) ist die Verwendung von
> signed Befehlen (brlt) auf unsigned Operanten.

Ich finde auch, das sie viel zu viele Register belegt und unnötig Krams 
sichert - ganz, wie du schon gesagt hattest. Die Woz Routine benötigt 
genau ein Register und den Stack und kommt problemlos von µs bis 
Sekunden.

[gustav (Gast)]

Freut mich, dass am eigentlichen Prog wohl zunächst nichts zu meckern 
übrigbleibt.

Nun zu den in die Pfanne gehauenen Warteschleifen:

Diese Schleifen sind noch aus dem "alten" Programm einfach gedankenlos 
von irgendeiner Internet-Seite (irgendein altes 
Mikrocontroller.net-Tutorial) abkopiert worden. Ich verwende sie nach 
Möglichkeit nicht mehr.
(Dienen ausschließlich dem Zweck, Euch hier zur Weißglut zu bringen.)
----
Das Sichern der temps ist dann eine liebgewonnene Angewohnheit.
Kann aber essenziell sein.
Zum Beispiel, wenn man Argumente mehrfach hintereinander sendet, wie bei 
der LCD-Initialisierung ganz zu Anfang ( 3x hex30 ) und zwischenzeitlich 
dieselben Register für Zeitschleifen verwendet.
Das hatten wir ja vorgestern angemeckert, das zuviele Male dasselbe 
geladen würde. Jetzt wäre es ohne push und pop
voll in die berühmte Hose gegangen. Gelle?

Wurde ja auch als "include"-Datei im Kommentar gekennzeichnet, die als 
Programmschnitzel für verschiedene andere Proggis verwendet werden 
könnte, von denen man nicht weiß, ob sie d i e Register noch für 
Arithmetics etc. brauchen.

Die "brlt"-Sache gefällt mir auch nicht.
Vielleicht geht es auch mit brlo oder Knopf an die Backe nähen und 
irgendwelche Flags abfragen, was es - auf Teufel komm raus - noch so zu 
bieten hat.
----
Es geht mit folgenden 16-Bit-Schleifen IMHO besser und übersichtlicher.
(Die Befehlsdurchläufe lassen sich wenn gewünscht, besser berechnen, 
ohne sich vielleicht in dem "Knäuel" zu verheddern.)

vielen Dank für Ihro Gnaden Aufmerksamkeit,
untertäniglichst

ciao
gustav

[Karl B. (gustav)]

Was soll da falsch sein?
erstes Byte des Strings nach R0 lesen


 ist bloß ungenügend klar formuliert




Zitat: "http://www.avr-asm-tutorial.net/avr_de/testlpm.html";
lesen:   LPM ; Lese das Byte, auf das Zeiger Z zeigt in Register R0

Zufrieden?

[spess53 (Gast)]

Hi

>Freut mich, dass am eigentlichen Prog wohl zunächst nichts zu meckern
>übrigbleibt.

Falsch. Ich habe nur keine Lust dein Progamm Zeile für Zeile auseinander 
zu nehmen und Romane dazu zu schreiben.

Z.B. Deine 72 Befehle zum Laden vom CG-RAM

ascii_00:        ; Charakters zuordnen
ldi  temp,  0x40    ; und Pixel definieren
rcall  kommando   
...
ascii_07:
ldi  temp,  0x78    ; "Set CGRAM address"-Steuerbefehl
...
ret

sehen bei mir so

                      ldi ZL,low(tabelle<<1)
                      ldi ZH,high(tabelle<<1)
                      ldi t17,8*8 
                      rcall set_cgram
                      ...
;-----------------------------------------------------------
;                     CG-Ram laden

;                     in  : Z - Tabelle
;                           r17 Anzahl Zeichen (á 8 Byte)

                      .if use_set_cgram == 1
set_cgram:              push r17
                        push r18

                        ldi r18,cgram_set
                        rcall lcd_wrcmd

set_cgram10:            lpm r18,Z+
                        rcall lcd_wrdat

                        dec r17
                        brne set_cgram10

                        pop r18
                        pop r17
                        ret
                      .endif

aus. Macht das gleiche, ist aber eine Idee kürzer.

>Die "brlt"-Sache gefällt mir auch nicht.
>Vielleicht geht es auch mit brlo

brlo ist genau so falsch, weil für signed Operanden. Sieh dir mal die 
Tabelle '3. Conditional Branch Summary' in

www.atmel.com/images/Atmel-0856-AVR-Instruction-Set-Manual.pdf

an.

Einfach so:

      ldi r16,10
aaa:  dec r16
      brne aaa

MfG Spess

[spess53 (Gast)]

Hi

>Was soll da falsch sein?
>erstes Byte des Strings nach R0 lesen

Nicht falsch, aber überholt

lpm     - [Z] nach r0
lpm rd  - [Z] nach r0...r31

lpm stammt aus Zeiten der AT90Sxyz. Alle aktuellen kennen AVRs den 
lpm-Befehl der direkt in das Zielregister, ohne Umweg über r0, lädt.

MfG Spess

[spess53 (Gast)]

Hi

Korrektur:

Alle aktuellen kennen AVRs den... -> Alle aktuellen AVRs kennen den...

MfG Spess

[Karl B. (gustav)]

print_0:
lpm  temp, z+    ; erstes Byte des Strings nach temp lesen
inc  temp2       ; und Adresse Postincrement
cpi  temp2, 0x09    ; insgesamt achtmal Pixelwerte holen
breq  print_end0  ; wenn 9, dann zu print_end0
;mov  temp,  r0    ; Inhalt von R0 nach temp kopieren --- enfällt
rcall  ausgabe
;adiw  ZL:ZH,  1  ; Adresse des Z-Pointers um 1 erhoehen entfällt bei Z+
rjmp  print_0    ; zum Anfang springen, um naechstes
;        ; Byte zu holen
print_end0:
ret


Vorsicht Falle:
der Attiny 4313 machts, der 2313 glaube ich nicht.
da kommt im Studio4.18 die Assemblerfehlermeldung "no such instruction"

Das Z+ !!
danke für tip

[Karl B. (gustav)]

hier das Bild

[spess53 (Gast)]

Hi

>Vorsicht Falle: der Attiny 4313 machts, der 2313 glaube ich nicht.
>da kommt im Studio4.18 die Assemblerfehlermeldung "no such instruction"

Nö. Aus Instruction Set Summary ATTiny2313:

LPM            Load Program Memory R0 ← (Z) None 3
LPM Rd, Z      Load Program Memory Rd ← (Z) None 3
LPM Rd, Z+     Load Program Memory and Post-Inc

Der uralte AT90S2313 (Include-Datei 2313def.inc) kennt nur 'lpm'. 
ATTinys kennen die erweiterten lpm-Befehle.

MfG Spess

[Karl B. (gustav)]

Ja, korrekt!

[Jakob (Gast)]

Hm, ohne es genauer zu betrachten, erzeugt Karl B. (gustav)
da einige zusätzliche "user defined Characters" deren
Verwendbarkeit für eine Grafikausgabe z.B. mit einem Tiny-µC,
der mit seinen beschränkten Resourcen erst mal die Daten
erfassen, auswerten und bereitstellen muss, bisher nicht
nachgewiesen hat.

Hat schon mal wenig mit der Fragestellung des TO zu tun.
Aber vielleicht lernen wir anderen was:

Erzähl also nicht so viel, zeig es uns!
Datenerfassung, Auswertung und grafische Darstellung!

Vorgabe: Maximal 50% der Ressourcen eines Tiny44.
Punkteabzug, aber noch "interessant",
wenn es 50% eines Tiny84 sein müssen.

[spess53 (Gast)]

Hi

>Hm, ohne es genauer zu betrachten, erzeugt Karl B. (gustav)
>da einige zusätzliche "user defined Characters" deren
>Verwendbarkeit für eine Grafikausgabe z.B. mit einem Tiny-µC,
>der mit seinen beschränkten Resourcen erst mal die Daten
>erfassen, auswerten und bereitstellen muss, bisher nicht
>nachgewiesen hat.

Wenn du den Typ des Displaycontrollers von EA nennst bekommst du mehr 
Infomationen.

MfG Spess

[gustav (Gast)]

Jakob schrieb:
> Ein Blick in das angegebene Datenblatt zeigt:
> Richtiger Grafik-Mode IST NICHT.
>
> Wie bei den üblichen 44780-LCD-Displays, gibt es hier 8
> "Character", die man als 5x7-Pixel selbst definieren kann.

Also, wo steht im mit obigem Link aufrufbaren Datenblatt irgendetwas von 
Graphik-Mode.
Sollte so etwas sein, schicke ich eine Beschwerde an Reichelt wegen 
unlauteren Wettbewerbs bzw. bewusster Irreführung der Kunden.

Meine Displays von POLLIN funktionieren, wie sie es sollen.

Hier ein echtes Graphik-LCD:

LCD-Modul TG12864B-05
Grünes, grafisches LC-Display (128x64 Pixel) mit integriertem Controller 
(kompatibel zu KS0108) und LED-Hintergrundbeleuchtung. Geeignet zum 
Betrieb am PC-Druckerport (LPT).


Der Rest des Threads sollte doch die Userdef Chars behandeln
Grafik-Mode ist nicht.
Wenn man einen galoppierenden Gaul mit dem Hitachi-Controller hinkriegen 
will, kostet es schon viel Mühe. Den ersten Ansatz dafür habe ich hier 
geleistet. Mehr it nicht drin.


ciao
gustav

[Karl B. (gustav)]

Suchergebnis:
Da können 3 Fonts ausgewählt werden, sonst nichts an Extras.

[spess53 (Gast)]

Hi

>Also, wo steht im mit obigem Link aufrufbaren Datenblatt irgendetwas von
>Graphik-Mode.

Auf S.4 unter Cursor/Display Shift/Mode/Pw r

>Sollte so etwas sein, schicke ich eine Beschwerde an Reichelt wegen
>unlauteren Wettbewerbs bzw. bewusster Irreführung der Kunden.

Was hat Reichelt damit zu tun? Das ist das Original Datenblatt von 
ELECTRONIC ASSEMBLY. Und das ist für OLED-Displays und nicht für 
LC-Displays.

Die OLED-Controller sind zwar weitestgehend kompatibel mit den HD44780, 
haben aber ein paar Befehle zusätzlich.

Ich habe hier noch ein dieser Displays herum liegen. Wenn ich Zeit habe 
werde ich die mal genauer testen.

MfG Spess

[Karl B. (gustav)]

spess53 schrieb:
> Wenn du den Typ des Displaycontrollers von EA nennst bekommst du mehr
> Infomationen.

Das ist mal wieder typisch. In der Produktbeschreibung im Prospekt ist 
nichts, was beanstandenswert wäre.
Aber jeder, der sich ein wenig mit LCDs oder ähnlichen Displays nur 
annähernd etwas genauer befasst hat, wird doch bei der Angabe des 
Controllertyps sofort stutzig.
TECHNISCHE  DATEN
*  INTEGRIERTER KONTROLLER (HD44780-ÄHNLICH)

Dass man zwischen 3 "Fonts" auswählen kann, scheint das Besondere.
Wieso da Graphik-mode steht, müsste man mal den Hersteller fragen, was 
er sich dabei gedacht hat.
Reichelt kann da auch nichts dafür, bitte reuigst um Vergebung Ihro 
Gnaden.
Überall auch "subject to change - Änderungen vorbehalten etc."
(Will meine Kundennummer bei Reichelt auch nicht verlieren wegen 
unablässiger Querulanz.)

Testen kann ich's nicht, habe keine Oleds.

ciao
gustav

[spess53 (Gast)]

Hi

>Aber jeder, der sich ein wenig mit LCDs oder ähnlichen Displays nur
>annähernd etwas genauer befasst hat, wird doch bei der Angabe des
>Controllertyps sofort stutzig.

Warum stutzig?

>TECHNISCHE  DATEN
>*  INTEGRIERTER KONTROLLER (HD44780-ÄHNLICH)

Ist auch nicht falsch. Ich habe das OLED-Display W162-XBLW einfach auf 
eine Platine aus der laufenden Fertigung gesteckt und es hat ohne 
Änderungen an der Software anstandslos funktioniert.

MfG Spess

[gustav (Gast)]

spess53 schrieb:
> Warum stutzig?

Grafikmodus und HD447780
das macht doch stutzig.... so wäre es sinngemäß korrekter



Wenn ich nach LCD und Grafikmodus suche, bekomme ich andere 
Controller-Standards serviert.

[Karl B. (gustav)]

Nur ein Suchergebnis purer Zufall:
Wo ist da was von HD44780 die Rede?

 LCD-Grafikdisplay

    Technologie
    mit Display-RAM

    Ausführung
    mit Controller UC1701

[Karl B. (gustav)]

Warte noch auf Email-Antwort vom Hersteller des vom TO benutzten 
Displays insbesondere, wie der Begriff "Graphic Mode" hier nun zu 
verstehen ist.
Bis dahin... bitte etwas Geduld.

Abwarten und Tee trinken
ciao
gustav

[spess53 (Gast)]

Hi

>Grafikmodus und HD447780
>das macht doch stutzig.... so wäre es sinngemäß korrekter

Nicht alles was du nicht kennst gibt es nicht. Such mal nach den ST7920 
von Sitronix. Und auch

Beitrag "HD44780 (Pollin DV20208) Zeichenbreite stimmt nicht"

MfG spess

[Karl B. (gustav)]

Hallo,
hier Antwort des LCD-Herstellers (sinngemäß)
"...Es ist ein HD44780 kompatibler Controller. Er kann dasselbe wie der 
eben genannte.
Er kann zusätzlich aber noch OLED Spannungen generieren
und als Grafikcontroller arbeiten.
Der Controller könnte beim EA W162-X9LG auch vom "Schreib-" in den 
"Zeichenmodus" gesetzt werden, doch entstünde hierbei nach 8 Pixeln eine 
Lücke von 4 Pixeln Höhe, da auf dem OLED-Glas ein Zwischenraum zwischen 
erster und zweiter Zeile fest eingefügt ist, so dass nicht über die 
gesamte Fläche gezeichnet werden kann..."
Zitat Ende


Laut Datenblatt müsste IMHO dann in der Initialisierungsroutine anstelle 
0x17  0x1F erscheinen, um den "Graphic mode" zu aktivieren.



ciao
gustav

[spess53 (Gast)]

Hi

>hier Antwort des LCD-Herstellers (sinngemäß)

Interessant wäre der Typ des Displaycontrollers.

Aber ich habe mal etwas gesucht und bin auf den WS0010 von WINSTAR 
gestoßen. Der stimmt soweit mit den Angaben von EA überein.

MfG Spess