www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik unbekannter LCD Controller, mit Eigenart (?)


Autor: Michael W. (das-micha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe ein funktionierendes Gerät, welches ein 132x64 Grafik-LCD (s/w) 
angeschlossen hat, leider ist der Controller des LCD's Gold Bumped und 
auf dem Kabel ist nix zu finden, das Display wird seriell angesteuert, 
D/C CLK und MOSI habe ich bereits identfiziert, SS ist fest verdrahtet.

mit dem OSzi konnte konnte ich auch erste Werte auslesen, das ganze 
läuft mit 1Mhz Spi, das "Problem" ist, ohne grossen Logik-analyzer mit 
Puffer wird es recht schwer zu finden was was ist, ich habe einige 
Command-Sequenzen ausgelesen und mit Datenblättern verglichen, so komme 
ich da nicht wirklich weiter ...

Nun aber habe ich eine Eigenart entdeckt, das Display wird mit sehr 
vielen 0b10000000, also 0x80 "gefüttert" ich vermute das ist setze 
keinen Pixel, auf "hi" allerdings ist mir bei noch keinem LC-D eine 
7-Bit routine untergekommen, hat einer bei euch solche erfahrungen, 
vielleicht gibt es ja genau nur bei dem Controller eine solche eigenart? 
...

Ablauf vermutlich so: Adresse setzen, daten runterschreiben, sehr viele 
0x80's, andere werte konnte ich noch nicht anaylsieren, das 1 MHZ doch 
recht flot ist somit kann ich nicht sagen, ob bit 7 immer hi kommt, noch 
nicht ....

mir würde es reichen für den chip den befehl zum setzen der 
start-adresse zu finden, dannach pixel ich mir rein was ich brauche, 
schön wäre evtl. auch zu wissen ob ein character generator an board ist, 
muss aber nicht sein, ich will im laufenden betrieb des displays die 
leitung unterbrechen und mich einhängen, und wieder zurückgehen wenn ich 
meinen extra-programmabschnitt verlasse ... (komisch erklärt ;) ) ... 
somit kümmern mich zum glück keine init-sequenzen und anderes ...

technisch möglich, da das display ständig mit daten versorgt wird, somit 
braucht man die >8000 bits nicht zwischenspeichern ... aber halt nur 
wenn die befehle für das setzen der grafik-home adresse bekannt sind ...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. wrote:
> Nun aber habe ich eine Eigenart entdeckt, das Display wird mit sehr
> vielen 0b10000000, also 0x80 "gefüttert" ich vermute das ist setze
> keinen Pixel, auf "hi" allerdings ist mir bei noch keinem LC-D eine
> 7-Bit routine untergekommen, hat einer bei euch solche erfahrungen,
> vielleicht gibt es ja genau nur bei dem Controller eine solche eigenart?

Bist du sicher, dass wirklich 0x80 geschrieben werden und nicht 0x00 und 
der high Pegel nicht zwischen 2 Bytes liegt (es gibt ja verschiedene SPI 
Modes)?

> mir würde es reichen für den chip den befehl zum setzen der
> start-adresse zu finden, dannach pixel ich mir rein was ich brauche,

Such mal die Adressleitung. Die sollte sich gut erkennen lassen, denn 
kurz vor dem Daten schreiben wird vermutlich die Adresse zum Display 
geschrieben und dieser Befehl muss ich ja irgendwie von den Daten 
unterscheiden.
Wenn du die Adressleitung gefunden hast, trigger auf die und schau dir 
dann die Daten/Befehle an.

> schön wäre evtl. auch zu wissen ob ein character generator an board ist,

Ist sehr selten geworden in letzter Zeit.

Autor: Michael W. (das-micha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich denke auch eher, inzwischen, das 0x00 geschrieben wird und 2 
"stopbits" laufen, wäre zwar komisch, aber mhh ... sck und mosi gehen 
synchron, keine verschiebung um 500ns oder so, das wundert mich, d.h. 
gleichzeitig mit dem bit am mosi geht auch sck hoch, gleichzeitig gehen 
die runter, welcher mode es genau ist habe ich noch nicht geschaut, 
vermute steigente flanke sck, so kenn ich die meisten LCD-controller, 
was halt komisch ist, es ist keine zeit fürs "einschwingen" vorhanden, 
muss mal gaaaanz nah ranzoomen am oszi. die D/C leitung habe ich auch 
gefunden, und auf die getriggert, sonst kommt man ja garnicht weiter, 
mir waren halt nur diese 2 bits aufgefallen die "hi" sind, ohne das sck 
läuft (bzw. das 2. bit läuft in mosi rein, wenn der 1. sck takt kommt, 
ich werde mir das nochmal genauer anschauen müssen, vermutlich triggert 
die fallende flanke dann würde 0x00 kommen und alles passen, dann müsste 
ich nur die ersten bytes wo dc=low ist mitschreiben und einfach mal 
probieren ;)

ich überlege aber die ganze zeit schon, wie ich mit einem atmega8/168 da 
dazwischen komme, ohne timing probleme zu bekommen, einerseits könnte 
man ja hardware spi als input und usart als master-output laufen lassen, 
glaube aber nicht das man die use uart as master-spi funktion auf 1 mhz 
bekommt, d/c dann über interrupt switchen, oder was mir vorhins 
einfiehl: in die 3 leitungen einen transistor rein, der bei "übernahme" 
einfach zu gemacht wird, die lcd-leitungen gehen dann an transistor/und 
hardware spi, wären die transistoren aber durchlässig sind, sind die 
pullups am avr auf hi ...

wäre das eine möglichkeit? kommen die 1mhz sauber durch die transistoren 
durch?

Autor: Michael W. (das-micha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hups, nee 1mhz bei transistoren wird glaube nix, da hab ich mich 
verdacht, die sättigung kommt ja nicht weg ... gibt es da eine andere 
möglichkeit? für diesen fall? oder würde es gehen die basis mit dem AVR 
zu steuern und irgendwie die C-E strecke am transistor als durchgang zu 
nutzen? da wüsste ich aber nicht inwiefern so ein gold-bump chip mit den 
dünnen leiterbahnen auf den abfallenden strom reagiert ... zur not 
halt...

irgendwie ein relay bräuchte es da, welches wirklich nur durchschaltet, 
aber irgendwie hab ich gerade eine blockade da die einfache lösung zu 
sehen ...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am einfachsten geht das mit einem Digitalmultiplexer wie einem HC157: 
Damit wird einfach der Bus von der Elektronik abgetrennt und an den AVR 
umgeschaltet. Bis ein paar 10MHz sollte das ohne Probleme funktionieren.
Das ganze sollte man vielleicht noch über die CS\ Leitung 
synchronisieren, damit man nicht mitten in einem Byte umschaltet.

Autor: Michael W. (das-micha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, na klar, 'n mulitplexer würde gehen, CS gibts leider nicht, das ist 
fest verdrahtet, könnte man ab am yC mit der D/C Leitung abfangen, 
sobald die sich ändern ist das ein zeichen, das kein byte läuft ...

einen "einfacheren" weg gibts nicht?, mit "analog"-technik bin ich in 
den letzten jahren ein wenig unberührt gewesen, und da ich es nur 
hobby-mässig betreibe ...  irgendwie muss es ja mit analog-mitteln ein 
"unabhängiges" relais nachbildbar sein .... das "zeug" hab ich da, 'n 
multiplexer muss ich erst besorgen, oder irgendwo auf einer platine 
finden ....

Autor: Michael W. (das-micha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
darf ich dich nochmal was fragen?

ich bin inzwischen weiter, ich habe mit einem AVR das SPI "abgehorcht" 
und mitgeschrieben, leider gehen nur weniger bytes, bis der ram "voll" 
ist, das wird dann per uart an den pc übertragen, ergebniss: ich habe 
ein bild ;) zumind. in der konsole, wenn ich das raw-logfile ausgebe, 
das "problem" ist nur (vielleicht hilft das ja weiter) das hier 
zeilenweise geschrieben wird, d.h. es kommt der befehl zum platzieren 
des address-pointers, und dannach kommen 132 bytes (132x64) wobei 
vertikal runtergeschrieben wird, das erklärt auch die 0x80, das war der 
rahmen ;)

beispiel:

11111111-10000001-10000001-[...]-10000001-11111111

ergibt folgendes bild auf dem display:

111111111111111111111111111
100000000000000000000000001
100000000000000000000000001
100000000000000000000000001
100000000000000000000000001
100000000000000000000000001
100000000000000000000000001
111111111111111111111111111


so, aber sowas hab ich ja nun noch garnicht gesehen!, oder lese ich die 
datenblätter falsch (?) bis dato gings bei mir immer noch links nach 
rechts/byte, aber vielleicht liegt das an dem fehlenden character 
generator?

init-für diese "zeilen" scheint

1011+4bit
0001+4bit

hi/low nibble, wobei nur das 1011xxxx byte "läuft"
zu sein....


usw... sein kann, hier warscheinlich die "linie" die angesrochen wird 
bei 64 pixel höhe ergibt sich das die letzten 3 bits dafür zuständig 
sein könnten ....


(mit ein wenig glück hat jetzt einer schonmal einen kontroller mit 
dieser art in den fingern gehabt)

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. wrote:
> so, aber sowas hab ich ja nun noch garnicht gesehen!, oder lese ich die
> datenblätter falsch (?) bis dato gings bei mir immer noch links nach
> rechts/byte, aber vielleicht liegt das an dem fehlenden character
> generator?

Ja, das ist normal. Damit kann man in der Tat schön Text schreiben, 
solange er 8 Pixel hoch ist.

>
> init-für diese "zeilen" scheint
>
> 1011+4bit
> 0001+4bit

1011 = Zeilenadresse
0001 / 0000 sind high und Low für Spaltenadresse

Controller dürfte der SED1565 sein, der kann genau 132x65 Pixel und die 
Befehle passen auch. Oder ein ähnlicher, aber die kleineren Epson 
Controller sind alle sehr ähnlich. SED1565/S1D15605 ist ein Standardtyp, 
also ziemlich warscheinlich, dass es der richtige ist.

Autor: Michael W. (das-micha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na aber danke! ich bin gestern über den ssd1815 gestolpert, das stimmte 
die adressierung, und wer datenblatt lesen kann .... auch die 
pixelzuweissen (page-select 1011xxxx) .. allerdings ist der erste 
display-init code 11110000 (oder so) wobei 1111xxxx reset display 
test-mode (don't use) ist.... das hat mich gewundert, ich schau mir die 
1565 nochmal an, denke aber nur das die älter sind, danke dir, benedikt!

Autor: Michael W. (das-micha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe mal die init-sequenz mit text versehen, sieht ansich ganz gut 
aus, das wäre das display-init für den sed1565, nur das 1. byte mit
11111000 bereitet mir "schmerzen" das 1111xxxx für ic-test steht und man 
es nicht nutzen sollte ...

aber ansonsten sieht das gut aus, wenn ich das init bräuchte würde ich 
sowieso das mitgeschriebene nehmen, was geht, geht ;)


11111000                  :   248 // Command for IC test. Do not use 
this command
01010100                  :   84  // Sets the display RAM display start
                                      line address 01xxxxxx
11100010                  :   226 // Internal reset
00101100                  :   44  // Select internal power supply
                                     operating mode
00101110                  :   46  // Select internal power supply
                                     operating mode
00101111                  :   47  // Select internal power supply
                                     operating mode
00100101                  :   37  // Select internal power supply
                                     operating mode
10000001                  :   129 // Set the V5 output voltage set
                                     electronic volume register
00001111                  :   15  // Sets the least significant 4 bits 
of
                                     set lower bit the display RAM 
column
                                     address
11001000                  :   200 // Select COM output scan 1: reverse
                                     direction
10100100                  :   164 // Display all points 0: normal 
display
10101111                  :   175 // LCD display ON/OFF : ON
10110000                  :   176 // set page
00010000                  :   16  // most significant

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. wrote:
> ich habe mal die init-sequenz mit text versehen, sieht ansich ganz gut
> aus, das wäre das display-init für den sed1565, nur das 1. byte mit
> 11111000 bereitet mir "schmerzen" das 1111xxxx für ic-test steht und man
> es nicht nutzen sollte ...

Der SED1565/S1D15605 (alte und neue Bezeichnung von dem selben IC) ist 
das älteste IC aus der Serie. Der wurde nach und nach mit mehr Features 
erweitert und auch von anderen Herstellern kopiert.

Dann ist es wohl der Nachbau von Sitronix: ST7565:
11111000: select booster ratio: 2x

Abgesehen von diesem einen Befehl dürfte der ansonsten kompatibel sein.

Autor: das-micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mhh ... im ST7565 Datenblatt steht allerdings auch 1111XXXX test-mode, 
do not use...

hab aber gerade ein anderes datenblatt gefunden, von einem anderen chip

da steht
111110000 (01/11)

im nächsten schritt
1111**** test ...

somit kann das schon stimmen... den rest gehe ich dann mal noch 
gesondert durch, ob es da abweichungen gibt, am ende ist der befehl auch 
in den SED's drine ...

danke vielmals...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das-micha wrote:
> mhh ... im ST7565 Datenblatt steht allerdings auch 1111XXXX test-mode,
> do not use...

Ich sags mal so: Sitronix ist nicht gerade für fehlerfreie Datenblätter 
bekannt. Da gibt es aber noch weitaus schlimmere Fehler bei diesen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.