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
Angehängte Dateien:
-
Display_connect.jpg
25 KB
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
Angehängte Dateien:
-
Display_connect.jpg
29 KB
Tschuldigung, Tipp-Fehler bei der Pin-Belegung, erster Pin muss RS heissen, hier korrigiertes Bild
Sind das eigentlich 1,8V oder 3,3V Logikpegel bei RS, CS, CLK, DAT usw.? Gruß Michael
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ß
Ach ja, hier noch ein Link (ebenfalls im angebenen Thread) für DBs bezüglich Handys etc. Such mal nach "siemens", findest manchmal recht nützliche Dinge. http://www.eserviceinfo.com/index.php?language_file=lang-english.php Gruß
das cx65 hat zwischen display und µC den epson chip s1d13716 an dem ist auch die kamera vom handy angeschlossen
das s65 wird wahrscheinlich den s1d13732 haben wie im dem oben angegebenen thread schon festgestellt wurde da dieser auch noch ne SD karte unterstützt
Das mit dem s1d13732 passt sehr gut zu der Beobachtung, dass das Display-Memorie per hardware upgedated wird, die control commands vmtl. aber nicht.
Angehängte Dateien:
-
s65_disp_1_red.jpg
58 KB
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
Hallo, wollte mal nachfragen, ob sich hier noch was tut oder ob das Projekt schon wieder auf Eis liegt?
Angehängte Dateien:
-
S65_DISP_RED.jpg
84 KB
.... Gibt's eigentlich schon weitere S65-Display-Nutzer? Gruesse Christian
na endlich weiss ich warum einige hier im Forum doppelt posten....
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.
Angehängte Dateien:
-
display_glcd_large.jpg
140 KB
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 ;)
Wo bekommt man die glcd her? Nokias funktionieren gut bei mir, mal probieren ob das Siemens schöner ist.
Hi, Wieviel Strom zieht den das Display auf der 2.8V Schiene? Mit welchem Regler hast du die erzeugt? Einfach LM317 mit ein paar Rs ? Gruss Tobias
@ Tobias: "Beim Anschluss des Display's an die Pegel-Anpassung denken, bei mir Spannungsteiler 470/610. Ich betreibe beide Versorgungsspannungen mit 2.8V."
Hi, das habe ich auch gelesen :) Mich interressiert gerade aber mehr, wieviel mA das Display fuer die Logik benoetigt. Gruss Tobias
@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,
Wieder ein Meilenstein für Handydisplay und sogar ohne datenblatt!
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,
Jo ein komplett Bausatz oder Gerät wäre nicht schlecht! Wäre die Frage wie teurer? Und wie Ausgereift wäre der treiber.
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,
Angehängte Dateien:
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
@Christian K. Bitte registrier dich doch. Dann gibt's dieses Problem nicht mehr :) abo
@Christian: Könntest Du mir die source code schon mal schicken, ich habe jetzt ein display und möchtes gerne spielen. Grüße Mark, Mark(at)mdejong.de
Nicht so egoistisch, ich habe nämlich auch ein Display und möchte auch spielen! Also bitte hier posten, dann haben alle etwas davon!
Hallo, die Doku und die Sourcen sind online. http://www.mikrocontroller.net/forum/read-4-243641.html?reload=yes#243641 Grüße Christian P.S: Ich habe mich jetzt beim Forum angemeldet, daher der neue Name...
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
Angehängte Dateien:
-
dvis_s65_testpic.jpg
95 KB
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
Schon mal auf Christians Seite geschaut? http://www.superkranz.de/christian/S65_Display/DisplayIndex.html
Weiter oben müste doch eine PDF Datei sein die sozusagen die Kopie der HP ist. Schade ist es schon!
Hi, www.superkranz.de hat den Provider gewechselt. Ist in Kürze wieder online... BR Christian
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?
Es funktionert so weit, du kannst pixel setzen und bitmaps schreiben. Eine Grafik-Library musst du allerdings selber anpassen.
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. =)
ähm keine Ahnung, ich hab nie in delay.h etwas gemacht und wenn ich nix mache mit dem Orginal außer compailieren, dann rennt es ja
F_CPU sollte schon definiert sein. Ansonsten stimmen die delay Zeiten nicht. Füge doch mal ein #define F_CPU <deine Taktfrequenz in Hz> ein...
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?
Du musst mit der Spannung rechnen, die über dem R abfällt: (15V - 10,4V) / 180 Ohm = 25,6mA
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 ... ???
Linien zeichnet man am Besten über eine SetPixel(x,y)-Funktion: (Die Low-Level Sachen sind im Anhang.)
1 | #define RGB(r,g,b) (((r&0xF8)<<8) | ((g&0xFC)<<3) | ((b&0xF8)>>3))
|
2 | |
3 | void SetPixel(UINT8 x, UINT8 y, UINT16 color) |
4 | {
|
5 | lcd_cmd(0x21, ((x<<8)|y)); |
6 | |
7 | lcd_register(0x22); |
8 | LCD_CS_ENABLE(); |
9 | lcd_write(0x76); |
10 | lcd_write16(color); |
11 | LCD_CS_DISABLE(); |
12 | }
|
13 | |
14 | ...
|
15 | x = 10; |
16 | y = 10; |
17 | len = 50; |
18 | color = RGB(0,0,0); |
19 | for(i=0, i<len; i++) |
20 | {
|
21 | SetPixel(x+i, y, color); |
22 | }
|
23 | ...
|
Was die einzelnen Befehle bedeuten steht alles im Datenblatt des Controller: http://www.mikrocontroller.net/attachment/10916/HD66766-10.pdf 0x16 und 0x17 - zum Setzen eines Fensters im RAM 0x21 - RAM Adresse setzen 0x22 - in den RAM schreiben ...
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
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.