Hallo,
ich habe mal angefangen, mich mit dem Display aus dem Siemens S65
Mobile zu beschäftigen (auch M65, CX65). Es bietet 132x176 Pixel mit
16-bit Farbtiefe. Dazu einen recht gut zugänglichen Anschluss und
preiswert bei Ebay...
Leider habe ich keinen Zugriff auf die Spezifikation des integrierten
EPSON Display Controllers, daher habe ich mal ein paar Messungen mit
einem Speicher-Oscilloskop (siehe Anhang) des Daten-Traffics gemacht.
Dekodierte Befehlssequenzen stehen im Excel Sheet. Die Beschreibungen
zu den Bildern in der Textdatei.
Probleme:
a) Unglücklicherweise scheinen die Sequenzen mit keinem der mir
bekannten EPSON Display-Kontroller übereinzustimmen. (z.B. Nokia 6100)
b) Siemens scheint immer den ganzen Display-Speicher zu schreiben, d.h.
wenn ich eine Zahl eingebe, wird nicht nur diese Zahl, sondern der
vollständige Display-Speicher geschrieben. Sollte es keine Befehle für
variable Windows geben, wäre das Display für µC Anwendungen schlecht
geeignet.
c) Mein ATmega128 Board ist defekt, solange ich auf Ersatz warte, kann
ich nichts ausprobieren...
Anschlussbelegung Display:
1: RS
2: Reset
3: CS
4: clock
5: data
6: 2.8V
7: gnd
8: 2.8V
9: LED
10: LED
Falls jemand helfen möchte, sehr gerne...
Grüße
Christian
O.k. jetzt habe ich auch den Startup analysieren können. Die Scree-Shots
findet ihr im zip File, auch eine kurze Beschreibung.
Der Startup besteht aus insgesamt 6 Sequenzen die teilweise recht lang
auseinander liegen.
Im folgenden sind die Sequenzen zu einer zusammengefasst. Die
nachfolgenden Bytes werden also als Init Commands an das Display
geschickt:
FD FD FD FD EF 00 EE 04 1B 04 FE FE FE FE EF 90 4A 04
7F 3F EE 04 43 06 EF 90 09 83 08 00 0B AF 0A 00 05 00
06 00 07 00 EF 00 EE 0C EF 90 00 80 EF B0 49 02 EF 00
7F 01 E1 81 E2 02 E2 76 E1 83 80 01
Danach beginnt der Clear Screen, wobei erstaunlicherweise Einsen in den
Speicher geschrieben werden.
Der initale Screen wird noch mit zwei leading Command Wörtern
geschrieben:
EF 90
00 00
Danach folgt das eigentliche Kommando das auch später immer wieder für
Screen updates verwendet wird
EF 90
05 00
06 00
07 00
Ab hier wechselt RS von high nach Low und 371712 data bit's werden in
das Display RAM geschrieben. (132*176*16=371712)
Da das Interface mit 13MHz clock läuft, dauert die Übertragung der
Display-RAM Daten (gemessen) 28.5945ms.
So, im Grunde steht jetzt einer ersten Implementierung und Test nichts
mehr entgegen...
Grüße
Christian
Vielleicht noch zur Info, ich habe das alles an einem S65 mit Software
Version 16 gemessen...
Ausserdem ist ziemlich sicher, das im S65 der Display-Inhalt per
Hardware an das Display übertragen wird, denn es gibt keinerlei
Störungen bei den 28ms dauernden Übertragungsbursts. Die Kommandos
dagegen liegen zeitlich auseinander und scheinen daher eher per
Software generiert zu sein.
Hallo,
hervorragende Arbeit.
Kannst Du bitte mal die genaue Typenbezeichnung Deines Displays noch
posten? Bei vielen Handys werden Displays von unterschiedlichen
Herstellern eingesetzt, mit Controllern, die unterschiedliche
Befehlssätze haben, siehe Nokia-Handy 6100. Wäre schade, wenn man sich
dann bei Ebay genau das falsche Display ersteigert...
Gruß
Michael
Hier ein Bild mit Anschlussbelegung.
Ich glaube nicht, dass es verschiedene Controller Hersteller wie beim
Nokia gibt. Dieses Display ist eine spezial-Anfertigung für Siemens
(ESxxx). Ausserdem gibt es keinerlei Feedback vom Display zum Mobile.
Man könnte also gar nicht detektieren das ein anderes Display verwendet
wird...
Grüße
Christian
Habe ich leider nicht gemessen, ich gehe aber von 1.8V aus. Auf meiner
Platine habe ich beide Spannungen auf 2.8V gelegt, da das die Display
Kontroller üblicherweise können. Die 5VµC Pegel habe ich mit
Spannungsteiler (470/610) abgesenkt.
Bisher funktioniert es bei mir aber noch nicht (nur buntes Rauschen auf
dem Display). Vielleicht muss ich mir mehr Mühe geben das original
Timing nachzustellen (hatte bisher kaum Zeit)
Die LED Spannung ist ungefähr 10V@20mA.
Ich denke, es sollte herausgefunden werden, welcher Controller
eingesetzt wird.
Das "Nachstellen" des Timings halte ich für eine schlechte Lösung.
Ich befasse mich auch mit dem Display, habe aber auch nur die
Anschlussbelegung gefunden.
Das Problem ist, dass die Datenblätter vieler 132x176 TFT controller
nicht veröffentlicht sind. Da muss man erst mal die Hersteller fragen,
ob sie Unterlagen rausrücken.
Hallo,
interessante sache was ihr da macht.
Kann man dann diese Displays für eigene Bildausgabe nutzen, wenn
man herausgefunden hat, welche daten man eigeben muss ?
Oder wofür macht ihr das ?
Ciao,
nox
@ Christian K.
Hast du die Controller von HIMAX schon einmal in Betracht gezogen? Ich
bin auf den Hersteller einmal zufällig gestoßen.
http://www.himax.com.tw/ch/product/mbline.asp
Ich meine hier den Controller "HX8302"!
5 Minuten später habe ich durch google folgenen Thread hier gefunden.
Ist eventuell interessant.
http://www.mikrocontroller.net/forum/read-1-159313.html
Eventuell HIMAX einfach mal wegen dem DB anschreiben...
Gruß
Hallo,
meine erste Test-Software läuft und ich kann damit Bilder auf dem
Display darstellen bzw. den Inhalt des RAM's beschreiben und sichtbar
machen... Hier ein erstes Bild (ganz frisch) von Versuchsaufbau mit dem
neuen init-Bild.
Grüße
Christian
P.S: Ich schweige lieber, warum die SW nicht direkt am Anfang
funktioniert hat, am Timing lag es aber nicht. Obwohl ich das Timing
(bzw. die Verzögerungen zwischen den Command-Zugriffen) etwas
hingefummelt habe. Sie ist aber bei weitem kürzer als ich im Original
gemessen habe.
Hallo,
für alle die es interessiert, hier der erste Source-Code (AVR) zum
Ansteuern des S65-Displays.
Er füllt das Display zu je 1/3 mit reinem rot, 1/3 reinem Grün und 1/3
reinem Blau in der lcd_clrscr() function. (o.k. später wird das mal ein
echtes clrscr)
Aufpassen müsst ihr bei der Wartezeit zwischen der INIT1 und INIT2
Sequence in lcd_init(). Diese sollte so um die 29ms+/-3ms betragen
(genauer habe ich das nicht ausgetestet). Wenn sie zulang oder zukurz
ist geht das Display nicht. Hier also an euren µC anpassen. Die
eingestellten Zeiten sind für ATmega32 mit 8MHz.
Verschaltung ist in port_init_io codiert und lcd.h definiert:
#define LCD_CS PB0
#define LCD_RESET PB1
#define LCD_RS PB2
#define LCD_MOSI PB5
#define LCD_MISO PB6
#define LCD_SCK PB7
Beim Anschluss des Display's an die Pegel-Anpassung denken, bei mir
Spannungsteiler 470/610. Ich betreibe beide Versorgungsspannungen mit
2.8V.
Grüße
Christian
Hi Christian K.
Das Bild sieht gut aus, die Ansteuerung scheint zu funktionieren.
Kompliment!
Muss ich für die serielle Ansteuerung ein genaues Timing
einhalten bzw. brauch ich eine gewisse Mindestgeschwindigkeit
der Signale, oder reicht auch ein langsames Timing?
MartinK
cool - kannst dumal den Code posten, endlich mal eine altanative zum
6100 von Nokia :-) wie gross ist das Display eigentlich?
Und gibts das Display nur einmal ? Ich meine beim Nokia 6100 Display
gibts 3 Chipsätze :-/
Bevor jetzt alle losrennen und sich das Display kaufen für eine
Plug&Play Lösung...
Es gibt derzeit noch ein grosses Problem mit dem Display:
Es lässt sich nur das ganze Display in einem Rutsch beschreiben. Die
Sequenz um Unterabschnitte zu beschreiben sind mir nicht bekannt.
D.h. soll sich irgendwo ein Pixel ändern, muss einmal das vollständige
Display-RAM upgedatet werden. Das sind immerin 371712bit's und das
dauert bei 8MHz SPI Takt schon ca. 50ms ohne Inhalts Berechnung
Ich würde mich allerdings freuen, wenn interessierte
experimentierfreudige Zeitgenossen hier unterstützen könnten, oder wenn
jemand an die Programmiersequenz herankommen könnte. Ich habe bisher nur
sehr wenig mit den Program-Sequenzen experimentiert und noch nichts
gefunden.
Gruesse Christian
P.S: Meine Textlösung ist derzeit nur ein ganz einfacher Hack, bei dem
ich das Display in 16x12 SpaltenxZeilen geteilt habe und mir für jedes
Element den Character (8-bit) und Farbe (16-bit) merke. (576bytes).
Damit kann ich dann jederzeit den Display-Inhalt rekonstruieren. Wenn
sich ein Zeichen auf dem Display ändert, wird das in die Matrix
eingetragen und das Bild neu gezeichnet.
Hallo,
das Siemens S65-Display hat jetzt seine letzten wichtigen Geheimnisse
preisgegeben.... Ich habe die Befehlssequenzen um Teile des Screens zu
beschreiben entschlüsselt :-)
Gerade habe ich die allseits geliebte (nicht nur wegen der schönen
Font's) glcd graphic library für den AVR auf das Display portiert,
siehe Foto.
Ich kann das Display jetzt bedenkenlos empfehlen. Vorteile gegenüber
Nokia 6100 Display:
a) Grösse
b) Auflösung (132x176) anstelle (132x132)
c) 65536 Farben (16-bit) anstelle 4096
d) einfacher grosser Anschluss, leicht zu löten
e) Kompatiblität (es gibt zwar verschiedene Ausführungen, aber die sind
kompatibel)
Grüße
Christian
Coole Sache, kannst mu mal Kompletten Schaltplan + benötigert Hardware +
Software auf deiner Seite bereit stellen? Ich denke daran haben viele
Interesse ;)
@ Tobias:
"Beim Anschluss des Display's an die Pegel-Anpassung denken, bei mir
Spannungsteiler 470/610. Ich betreibe beide Versorgungsspannungen mit
2.8V."
@Christian:
Gratuliere, sehr gute Arbeit.
Frage, wie gross ist der Abstand zwischen die kontakte vom Display.
Ich möchte eine Platine mit controller und taster für das S65 Display
machen.
P.S. kannst du bitte die schaltpläne und software posten?
Grüße Mark,
Hallo Christian,
Ich möchte für mein hexapod, spinnenroboter, einen MMI bauen.
Vielleicht werde ich, wenn die frage da ist, auch die Platine anbieten,
aber dann als Open Source (GPL) was die Software angeht.
Ich werde kein geheimniss aus die Software machen, auch werde ich die
quellen in der Software vermerken.
Wie du auf meine homepage (www.mdejong.de) sehen kannst mache ich auch
keine geheimnisse aus die schaltpläne.
Grüße Mark,
Die Platine werde ich nur als komplettes module (90mmx60mm), mit oder
ohne display verkaufen.
Die bauteile sind nämlich klein (0,5mm pitch).
MSP430F15x / MSP430F161x Controller.
Anschlusse:
I2C master/slave und rs232.
Spannungversorgung für controller, display und beleuchtung.
Die beleuchtung soll regelbar sein (PWM).
Ich suche im moment noch nach einen connctor für das Display.
@Christian:
Hast Du eine idee welche controller auf das S65 display ist, vielleicht
kann ich an das Datenblatt kommen!
Grüße Mark,
Hallo,
natürlich werde ich die Software und auch einen Schaltplan in der
Codesammlung veröffentlichen. Gebt mir nur noch ein paar Tage (ja ich
muss leider auch arbeiten und habe nicht viel Freizeit) zum Erstellen
der Doku.
Zum Pin-Abstand:
1/20 inch, d.h. ca. 1.3mm. Ich habe ein Foto meiner "Lötkünste"
angehängt.
Zur Stromaufnahme:
habe ich nicht gemessen, werden aber nur ein paar mA sein
Und noch etwas:
Da offensichtlich andere unter meinem Namen posten, glaubt nur den
Postings mit Bild :-)
Grüße
Christian
Ich habe ein Problem mit dem L2F50 Display.
Ich habe einen ARM9 mit Linux drauf, als Hardwareanbindung einen FPGA
mit 512 Word FIFO der mir eine "gepufferte" SPI zur Verfügung stellt
sowie einen Framebuffertreiber samt Consolentreiber dafür geschrieben.
QT Embedded läuft auf dem Framebuffer, nur sahen die Menüs irgendwie
komisch aus (siehe Anhang). Also hab ich mir mal ein Testprogramm
geschrieben, welches mir die RGB Werte als Farbverlauf ausgeben sollte.
Hängt dran, einschließlich Ausgabe auf dem TFT.
Erwarten würde ich pro Zeile von links nach rechts 32 Pixel von schwarz
bis sattrot, dann 64 Pixel von schwarz bis sattgrün, und dann 32 Pixel
von schwarz bis sattblau.
Die Position der Farbbits in dem 16bit Wort ist wirklich 565, das habe
ich mit einem anderen Testprogramm durchprobiert.
Es sieht momentan aus wie 3-4-3 RGB auf 5-6-5 RGB gemapped. In der
Mitte des Fotos auf Höhe der Mitte vom Stecker sieht man das es 8
verschiedene Rotstufen, 16 Grünstufen und 8 Blaustufen gibt, das Foto
ist nicht besonders gut gebe ich zu, aber ich kann das hier auf dem
Display eindeutig sehen.
Kann das Demoprogramm mal jemand mit einem AVR und der Demosoft von
Christian testen, weil ich befürchte daß das LCD nicht richtig
initialisiert wird.
Hatte jemand schonmal das L2F50 laufen mit definiv 5-6-5 Farben ? Weil
ich glaube nicht daß das bei dem Textdemo weiter aufgefallen wäre.
Markus
Hi!
>Hatte jemand schonmal das L2F50 laufen mit definiv 5-6-5 Farben ?
Weil
>ich glaube nicht daß das bei dem Textdemo weiter aufgefallen wäre.
Also ich habe bei mir ein rgb565 von einer cmos cam auf dem display
angezeigt.
Da wäre mir sowas aufgefallen denke ich...
Bye, Simon
uuuppss sorry ich hab ein LS020 !!
Hab mal ein Foto angehängt (wobei ich aber nur rgb555 anzeige glaub
ich, bit0 vom grün is immer 0)
Also da würde man das sehen ...
So, ich hab jetzt nochmal den Kram an den AVR umgeklemmt, und Christians
Demoprogramm soweit angepasst, daß diese Gradienten gezeichnet werden
müssten wie die aus meinem letzten Posting. Es auf dem AVR genauso
SCH... aus wie auf dem ARM9.
Kann jemand begefügtes AVR Projekt mal mit seinem L2F50 testen ? Das
würde sehr weiterhelfen denke ich.
In dem ZIP ist auch nochmal ein Screendump (Clock.bmp)von meinem QT
Embedded, welches ich mit cat /dev/fb0 > file.raw ausgelesen habe und
dann mit IrfanView nach BMP gewandelt.
So sollte es eigentlich aussehen, in Wirklichkeit aber siehe
"qt_embedded_small.jpg" im ZIP File.
Christian: kannst du das vielleicht auch nochmal bei dir testen ?
Danke!
Markus Rudolf
Hallo Markus,
habe es bei mir getestet, sieht erst mal genauso aus wie bei dir. In
den ersten Spalten sieht man von schwarz ausgehend immer heller
werdendes rot, das kippt dann plötzlich auf intensives rot dass sich
nicht mehr verändert. Grün und blau ist ähnlich.
Grüße
Ch.
So, wenns keiner macht muss mans wie immer selbst machen ;)
Hab gerade mal mit nem FPGA den Init vom L2F50 mitgesniffed und den Bug
gefunden der zu dem komischen Farbmode führt.
In der Inittabelle "gcp64_0[29]" ist ein Byte falsch.
static const uint8_t gcp64_0[29] =
{
0x11,0x27,0x3C,0x4C,0x5D,0x6C,0x78,0x84,0x90, // OK
0x99,0xA2,0xAA, 0xB2,0xBA,0xC0,0xC7,0xCC,0xD2,//OK
0xC7<-(D7!!!),0xDC,0xE0,0xE4,0xE8,0xED,0xF0,0xF4,0xF7, // NOK
0xFB,0xFE //OK
};
Den 7ms delay hab ich auch wieder mit drin. Da ist wirklich ne lange
Pause an der Stelle. Evtl. gehts aber auch so. Ich hab nur das eine
Byte geändert und es lief. Evtl. kann Christian ja nochmal testen, ich
hab keine Lust den AVR wieder aufzubauen, bin nächste Woche auf
Dienstreise.
Schönes Wochenende !
Markus
Sorry, dass ich den alten Thread wieder ausgrabe, aber ich habe noch
eine wichtige Frage!
Auf der Seite von Christian ist das L2F50xxx Display nicht so
ausführlich beschrieben wie die anderen, daher wollte ich fragen, ob es
denn genauso läuft und ob ich mich auch an seinem Code orientieren kann.
Oder gibt es irgendwas, was noch nicht geklärt ist bzw. was ich wissen
sollte?
Das Problem ist, dass es bei Ebay fast ausschließlich nur L2F50xxx
Displays gibt. Nur ein Händler hat ein paar LS0, aber dafür auch für den
doppelten Preis. >(
Vielen Dank und schöne Grüße!
"
Sorry, dass ich den alten Thread wieder ausgrabe, aber ich habe noch
eine wichtige Frage!
Auf der Seite von Christian ist das L2F50xxx Display nicht so
ausführlich beschrieben wie die anderen, daher wollte ich fragen, ob es
denn genauso läuft und ob ich mich auch an seinem Code orientieren kann.
Oder gibt es irgendwas, was noch nicht geklärt ist bzw. was ich wissen
sollte?
Er hat glaube ich mal geschrieben, dass er es nicht weiter getestet
hatte, daher meine Frage.
Das Problem ist, dass es bei Ebay fast ausschließlich nur L2F50xxx
Displays gibt. Nur ein Händler hat ein paar LS0, aber dafür auch für den
doppelten Preis. >(
Vielen Dank und schöne Grüße!
"
Weiß da jemand was genaues? Erfahrungswerte oder so?
Das heißt die Beschaltung ist soweit identisch, nur einige Befehle
unterscheiden sich vom LS0 zum L2F5?
Habe gestern ein L2F5xxx bestellt, werde dann mal ausführlich testen und
fragen/berichten.
so da hock ich und guck n bissi doof - ich hab ein LHP88 Display und
mich des Testprogramms von "superkranz" bedient. Folgendes Problem, wenn
ich das orginal hex-File nehme, alles prima - das Display macht den
Screen grün und schreibt darauf was es soll. Versuche ich dagegen den
orginal Sourcecode entweder mit dem makefile oder mit dem Atmel Studio
zu compailieren, dann bleibt mein Display dunkel.
Mein WinAVR ist 20071221 ... Fehlermeldung kommt, die Codeoptimierung
hab ich au mal ausgeschaltet, Display tut trotzdem nix - kennt das
Problem jemand und weiß vielleicht was zu tun ist???
danke ... happy eastern
sorry hab mich vertippt - ich wollte schreiben es kommt KEINE
Fehlermeldung, jedenfalls ned immer ... also ich versuchs noch gener zu
erklären, gibt nämlich ne leichte Veränderung.
das orginal hex-File rennt super, trage ich im orginal Makefile noch die
Prozressorgeschwindigkeit ein, rennts dieses hex-File auch, sobald ich
etwas am Programm ändere, z.B. eine neue Funktion einführe, die nix
macht bleibt das Display weiß. Selbst wenn ich "clean all" mache, meinen
zusätzlichen Code entferne und ein neues hex-File erstelle bleibt alles
dunkel. Erst wenn ich aus dem orginal Projekt *.o und *.d Files in mein
Projekt kopiere, dann erhalte ich wieder ein funktionierendes hex-File.
Entweder gibt es einen "Kopierschutz" im Projekt von Superkranz oder
meine Version von WinAVR paßt nicht richtig zu dem Cod ... oder es
handelt sich um ein ganz anderes Problem???
Im Anhang die Meldungen von WinAVR, wenn sich auf dem Display dann nix
mehr tut ... vielleicht hilfts
Gibt es für das LHP88 eine ein Bibliothek, die Linien zeichnen und
Bitmaps darstellen kann?
Aus deinem Logfile:
"F_CPU not defined for <util/delay.h>"
Muss das so? oO Muss da nicht die Frequenz definiert werden? Wenn ja,
dann kann das nicht tun. Aber das weiß bestimmt jemand anders genauer.
=)
ok könnte ich machen, ABER wo füge ich das denn ein, weil wenn "clean
all" mache und dann neu compailiere kommt ja besagte Meldung, trage ich
dann in der besagten Datei das F_CPU ein, dann meckert er trotzdem und
es tut sich au nix auf dem Display und in meinem Makefile ist F_CPU
bereits eingetragen oder muß das in main.c stehen?
Im Original-Quelltext steht das
#define F_CPU 16000000
im file disp.h. Hast du die Zeile rausgeworfen?
Auch passen die folgenden Fehlermeldungen
disp.c:231: warning: operation on 'j' may be undefined
disp.c:238: warning: operation on 'j' may be undefined
disp.c:245: warning: operation on 'j' may be undefined
disp.c:252: warning: operation on 'j' may be undefined
nicht zum Original-Quelltext.
Ich schlage vor nocheinmal zurück zum Original zu gehen und von da aus
die Fehler zu debuggen.
Beim LPH code muss du diesen Block
for (i=0; i<6; i++)
{
lcd_comtype(ct1[i]);
lcd_comdat(cd1[j++],cd1[j++]);
}
ändern. Das doppel j++ scheint nicht ANSI-C konform zu sein und bei
neueren gcc Versionen nicht zu funktionieren. Also z.B. ändern in:
for (i=0; i<6; i++)
{
lcd_comtype(ct1[i]);
lcd_comdat(cd1[j],cd1[j+1]);
j+=2;
}
Das ganze taucht mehrmals auf.
Das
#define F_CPU 16000000
kannst du auch hier am besten in disp.h packen, scheint zu fehlen.
Natürlich deinen Takt angeben.
Hallo Jens,
funktioniert es jetzt? Falls nicht, ich habe den LPH Quelltext upgedated
(auf der Web-Page). Kannst ja mal ausprobieren....
Grüße
Christian
Ich hab da mal ne ganz doofe Frage...
Wenn ich mir die Schaltung von Christian ansehe, dann ist für die
Hintergrundbeleuchtung ein 180 Ohm Widerstand und eine Spannung von 15V
angegeben. Wenn das Display jedoch 10,4V und 20mA braucht, dann kann das
doch nicht ganz passen.
15V / 180 Ohm = 83,3 mA
Ich würde die Hintergrundbeleuchtung gerne mit 12V betreiben. Bei einem
Widerstand von 680 Ohm wären das bei 12V dann immerhin 17mA. Zwar nicht
die maximale Helligkeit, aber sollte nicht stören.
Hab ich irgendwo einen Denkfehler oder sehe ich das gerade zu simpel?
Warum 180 Ohm bei 15V?
Arg... Ja sch*** ding ding ding
Also für 12V ca. 80 Ohm bei 20mA.
3x 220 Ohm parallel für 21,8mA hätte ich für ne Testschaltung da.
Ansonsten gibts ja 82 Ohm als Standardwert in jedem guten
Elektronikladen zu kaufen :)
also folgendes, vielleicht verstehts jemand LPH88 Display, ATmega128 und
ich will Striche zeichnen und mache das:
Auffruf im Programm:
x_line(0,20,174,0xffe0); // Pos x,y Länge, Farbe
void x_line(unsigned int x, unsigned int y, unsigned int l, unsigned int
c)
{
uint16_t i;
PORTB &= ~_BV(LCD_CS); // Auswahl Display
lcd_comtype(0x16);
lcd_comdat(0x83-y, 0x83-y); // y - Koordinaten
lcd_comtype(0x17);
lcd_comdat(x+l, x); // x - Koordinaten
lcd_comtype(0x21);
lcd_comdat(0x00, 0x00); //
lcd_comtype(0x22);
lcd_write(0x76);
for (i=0; i<DISP_W*DISP_H; i++)
{
lcd_write16(c); // mit Farbe ausfüllen
}
PORTB |= _BV(LCD_CS); // Display weg
}
es malt auch einen Strich, aber zwei Pixelreihen breit und ich versteh
bei Nacht ned wieso - ihr? Wenn ich das Ganze für Y-Richtig verbiege, is
der Strich nur ein Pixel breit, aber dafür länger als er soll und wenn
wir schon dabei sind, welchen Zweck verfolgen:
lcd_comtype(0x21);
lcd_comdat(0x00, 0x00); //
lcd_comtype(0x22);
lcd_write(0x76);
ich habs blind aus dem Beispiel von Superkranz kopiert ... ???
Hallo,
ich habe einen Schaltplan für das C65 und SL65 gefunden.
Vielleicht kann es sich mal einer von den Hardwareprofis anschauen.
In beiden wird als Displaycontroller der S1D13716B02-L verwendet,
was für das L2F50 Display sprechen würde?
Vielleicht hilft es weiter.
Gruß Ongaku
