mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Reengineering: Siemens S65 Display


Autor: Christian K. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian K. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian K. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian K. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Tschuldigung, Tipp-Fehler bei der Pin-Belegung, erster Pin muss RS
heissen, hier korrigiertes Bild

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind das eigentlich 1,8V oder 3,3V Logikpegel bei RS, CS, CLK, DAT
usw.?

Gruß
Michael

Autor: Christian K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: nox (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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ß

Autor: Axi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_fil...

Gruß

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das cx65 hat zwischen display und µC den epson chip s1d13716
an dem ist auch die kamera vom handy angeschlossen

Autor: Jochen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ach hier noch ne pdf dazu

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem s1d13732 passt sehr gut zu der Beobachtung, dass das
Display-Memorie per hardware upgedated wird, die control commands vmtl.
aber nicht.

Autor: Christian K. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian K. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Milewski (avr-nix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Gerald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wollte mal nachfragen, ob sich hier noch was tut oder ob das Projekt
schon wieder auf Eis liegt?

Autor: Christian K. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
....

Gibt's eigentlich schon weitere S65-Display-Nutzer?

Gruesse
  Christian

Autor: Christian K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na endlich weiss ich warum einige hier im Forum doppelt posten....

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Milewski (avr-nix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-/

Autor: Michael Neumayer (nurmi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Christian K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian K. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Läubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Coole Sache, kannst mu mal Kompletten Schaltplan + benötigert Hardware +
Software auf deiner Seite bereit stellen? Ich denke daran haben viele
Interesse ;)

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ABO

Autor: Thomas S (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
display ist bestellt

Autor: Uwe Blank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo bekommt man die glcd her?
Nokias funktionieren gut bei mir, mal probieren ob das Siemens schöner
ist.

Autor: Tobias Schneider (tobias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Tobias:

"Beim Anschluss des Display's an die Pegel-Anpassung denken, bei mir
Spannungsteiler 470/610. Ich betreibe beide Versorgungsspannungen mit
2.8V."

Autor: Tobias Schneider (tobias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
das habe ich auch gelesen :)

Mich interressiert gerade aber mehr, wieviel mA das Display fuer die
Logik benoetigt.

Gruss Tobias

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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,

Autor: Dirk Milewski (avr-nix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieder ein Meilenstein für Handydisplay und sogar ohne datenblatt!

Autor: Christian K. - cnkz@yahoo.c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark:

Willst Du das kommerziell verwerten?

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,

Autor: Dirk Milewski (avr-nix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo ein komplett Bausatz oder Gerät wäre nicht schlecht!
Wäre die Frage wie teurer? Und wie Ausgereift wäre der treiber.

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,

Autor: Christian K. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmm, die waren jetzt aber beide mit Bild ;)

Autor: Thomas Kropf (thomas_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian K.

Bitte registrier dich doch. Dann gibt's dieses Problem nicht mehr :)

abo

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht so egoistisch, ich habe nämlich auch ein Display und möchte auch
spielen!

Also bitte hier posten, dann haben alle etwas davon!

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die Doku und die Sourcen sind online.

http://www.mikrocontroller.net/forum/read-4-243641...

Grüße
  Christian

P.S: Ich habe mich jetzt beim Forum angemeldet, daher der neue Name...

Autor: Markus Rudolf (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ssss Ssssss (sssssss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ssss Ssssss (sssssss)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Markus Rudolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, bei dem LS020 mag das ja gehen....

Markus

Autor: Markus Rudolf (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Rudolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Appen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist RS für ein Signal? Danke!

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon mal auf Christians Seite geschaut?

http://www.superkranz.de/christian/S65_Display/Dis...

Autor: Klaus Appen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat er seine Seite gelöscht?

Autor: Klaus Appen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
warum? @ Christian

Autor: Avr Nix (avrnix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die geht doch!

Autor: Dieter Bohlen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ne buuuuuuhh

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow, heute Morgen ging sie noch, jetzt aber nicht mehr.

Autor: Magnus Müller (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das ist nicht fair!

Autor: Avr Nix (avrnix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weiter oben müste doch eine PDF Datei sein die sozusagen die Kopie der 
HP ist.
Schade ist es schon!

Autor: Gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist sie.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

www.superkranz.de hat den Provider gewechselt. Ist in Kürze wieder 
online...

BR
  Christian

Autor: Daniel Reinke (sliderbor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Daniel Reinke (sliderbor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"
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?

Autor: Daniel Reinke (sliderbor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir keiner was dazu sagen? :(

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es funktionert so weit, du kannst pixel setzen und bitmaps schreiben. 
Eine Grafik-Library musst du allerdings selber anpassen.

Autor: Daniel Reinke (sliderbor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann sag doch mal welche Fehlermeldung kommt...

Autor: Jens (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Daniel Reinke (sliderbor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. 
=)

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ä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

Autor: SU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles zurück, ich habe beim falschen Display geguckt :-(

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,

funktioniert es jetzt? Falls nicht, ich habe den LPH Quelltext upgedated 
(auf der Web-Page). Kannst ja mal ausprobieren....

Grüße
  Christian

Autor: Markus B. (wolframator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du musst mit der Spannung rechnen, die über dem R abfällt:

(15V - 10,4V) / 180 Ohm = 25,6mA

Autor: Markus B. (wolframator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ... ???

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Linien zeichnet man am Besten über eine SetPixel(x,y)-Funktion:
(Die Low-Level Sachen sind im Anhang.)
#define RGB(r,g,b) (((r&0xF8)<<8) | ((g&0xFC)<<3) | ((b&0xF8)>>3))

void SetPixel(UINT8 x, UINT8 y, UINT16 color)
{
  lcd_cmd(0x21, ((x<<8)|y));

  lcd_register(0x22);
  LCD_CS_ENABLE();
  lcd_write(0x76);
  lcd_write16(color);
  LCD_CS_DISABLE();
}

...
x     = 10;
y     = 10;
len   = 50;
color = RGB(0,0,0);
for(i=0, i<len; i++)
{
  SetPixel(x+i, y, color);
}
...

Was die einzelnen Befehle bedeuten steht alles im Datenblatt des 
Controller:
http://www.mikrocontroller.net/attachment/10916/HD...

0x16 und 0x17 - zum Setzen eines Fensters im RAM
0x21 - RAM Adresse setzen
0x22 - in den RAM schreiben
...

Autor: ongaku (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

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.