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 ...
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.
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?
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 ...
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.
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 ....
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)
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.
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!
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
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.
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...
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.