Hallo,

hier ein einfaches Demo Program für Atmel AVR zur BitMap Ausgabe auf
das Display des Siemens S65/M65/CX65/SK65 Mobiltelefon. Dieses Display
gibt es bei diversen Quellen recht günstig als Ersatzteil zu kaufen.
Preis derzeit z.B. 10EUR beim Internet Versteigerer zum sofort kaufen.

Die weitergehende der Software und Hardware findet sich hier:
http://www.superkranz.de/christian/S65_Display/Dis...

Dort gibt es auch die Quelltexte für die angepasste glcd die
ursprünglich für das Nokia 6100 Display entwickelt wurde.
http://www.mikrocontroller.net/forum/read-4-74872.html#new


Have Fun
  Christian

Ich hab mir auch mal eins bei ebay für 10EUR geordert, hab leider zu
spät gemerkt das bei diesen Displays der Artikelzustand als gebraucht
beschrieben ist... Naja ich bin gespannt für den Preis kann man ja
nicht sehr viel falsch machen :)

Hallo Christian,

Du hast in Deiner Webseite
http://www.superkranz.de/christian/S65_Display/Dis...
die Tag-Klammern zu den verlinkten Seiten etwas unglücklich gesetzt.
Der IE6 verweigert deshalb die Links.

Ansonsten sehr gute Arbeit!

Gruß
Joachim

oh ja, habe die schliessende Klammer(n) vergessen...
Ich hab's repariert.

Leider habe ich zuhause keinen IE und kann das nicht testen... Mozilla
hat das nicht gestört.

Grüße
  Christian

Und ich dachte die ganze Zeit, dass die Seite noch nicht
fertig ist.
Der hier gepostete Source-Code ist für mich nur schwer
zu verstehen (C mit ASM kann ich noch nicht so gut)
Durch deine Homepage ist mir der Ablauf der Display-Ansteuerung
endlich klar geworden.

Andy

Hallo Christian,

in den Startsequenzen Init1 und Init2 sind pro Reihe eine
unterschiedliche Anzahl Kommandos enthalten.
Hat dies etwas zu bedeuten, muss ich außer den 7 ms zwischen
Init1 und Init2 noch andere Zeitintervalle einhalten?
Wie hoch kann die minimale bzw. maximale Taktfrequenz der
seriellen Ansteuerung sein?

MartinK

Hallo,

die Aufteilung in verschiedene Reihen habe ich gemacht, weil ich
vermute dass jede Zeile ein Command ist.

Die Software (lcd.asm) schickt die Sequenzen einfach byte für byte als
grosses Packet.

Ich benutze 8MHz SPI clock, dürfte kein Problem sein, da das Display im
Original mit 13MHz benutzt wird. Es funktioniert aber auch ohne double
clock bit und mit 1/16 Teiler.

Grüße
  Christian

Hi,

ist es auch möglich mit bascom dieses LCD anzusteuern ? Besser gefragt,
hat dies schon jemand gemacht ?
( Wird schon gehen, nur wie ? )

mfg Kay

Naja, die Ansteuerung hat im wesentlichen ja nichts mit der Ansteuerung
zu tun. Bascom wird nur um einiges mehr Code produzieren, sollte aber
trotzdem funktionieren.

So, ehe unser Oberguru Jens Dinspel wieder aus der Bahn geworfen wird*,
hier eine korrigierte Fassung meines obigen Postings:


Naja, die Ansteuerung hat im wesentlichen ja nichts mit der
Programmiersprache zu tun. Bascom wird nur um einiges mehr Code
produzieren, sollte aber trotzdem funktionieren.



*) http://www.mikrocontroller.net/forum/read-5-244046...

Hy Leute,

Hab mir vorhin mal die zeit genommen
und das Zeug was auf der HP von Christian Kranz (ChristianK)
war in ein PDF gepackt.

Sollten irgendwelche Fehler oder Sonstiges
sein, bitte sofort mir sagen.

Gruß Lightning

(Dieser Beitrag wurde geloescht)

Hat jezt nix mitm Disp zu tun,
aber ich wllte euch nur mal drauf hinweisen, dass "actually" im
Englischen icht aktuell sondern tasachlich bedeutet.

Ihr wollt in dem Satz "Actually there are known three different types
of the display." wohl eher "Currently" nehmen :)

Gruss Tobias

@Christian:

bei der Addressierung des DisplayRAMs gibt es wirklich nur diese 2
Modis ?
Das bedeutet das dieses LCD mit meinen Font Routinen der GLCD nur Sinn
macht wenn es senkrecht benutzt wird, mit Koordinate (0,0) Links Oben.
Das ist Schade da es gerade waagerecht eingebaut interessant wäre.

Hast du bei den Commandbytes mal alle Bits durchgetestet ? Ich könnte
mir vorstellen das es ein Bit gibt das die Ansteuerung der Koordinaten
spiegelt. In diesem Moment wären alle 4 Richtungen wieder möglich.

Das Problem mit meinen Font Routinen ist, das sie durch die
Komprimierung und dementsprechende Live-Dekomprimierung während der
Anzeige eines Zeichens, nur in Richtung der Y Koordinate bottomup und
der X Koordinate bottomup gezeichnet werden können.
Eine einfache Art&Weise dieses Verhalten umzuprogrammiern wird es
leider nicht möglich sein.
Die Fonts müssten in ihrer Pixelreihenfolge schon während der
Komprimierung umprogrammiert werden. Was natürlich zu einer
Inkompatibilität der verschiedenen Fonts untereinander führt.

Funktionieren denn meine Linien Routinen ? Ich erinnere mich dunkel
daran das auch die Linienfunktionen von der spez. Memory
Addressierungen Gebrauch machen.

Kann man den DisplayRAM des LCDs auch wieder auslesen ?

Ansonsten super Arbeit.

Gruß Hagen

@ Tobias Schneider

Hallo,

Gut das du das mit demActually bemerkt hast.
Ih habe bereits ein neues PDF gemacht wo der
Fehler korrigiert ist. Ich warte aber noch
mit dem Upload, vieleicht tauchen noch mehr
solche Fehler auf.

Gruß Lightning

@Hagen,

ich habe einige (allerdings wohl nicht alle) Bit-Kombinationen nach dem
0x05xx Command getestet. Zumindest alle Einzelbits und FF. Ausser bei
der 04 hat sich nichts getan... (habe natürlich auch 0x04xx und 0x03xx
getestet ohne Wirkung) Ich habe mir da aber nicht sehr viel Zeit
genommen, vielleicht ist noch was versteckt....

Die Linien habe ich in alle 4-Richtungen diagonal getestet, waren o.k.

Leider kann man das Display Memory nicht zurücklesen. Macht im Mobile
Phone Betrieb auch keinen Sinn, da der RAM-Inhalt regelmässig (etwa
jede Sekunde) vom µC aufgefrischt wird um Pixelfehler zu vermeiden.

Wie man mit der GLCD weitermacht weiss ich auch noch nicht. Mir reicht
im Moment erst mal der 90-Grad Betrieb. Vermutlich könnte man sie schon
einfach anpassen, wenn man etwas Performance und RAM opfert....

Grüße
  Christian

Im Notfall könnte man die zu zeichnenden Zeichen ins RAM des uC
dekomprimieren und von dort aus entsprechend gedreht ans Display
senden.  Bei einer 2 Farb Font bräuchte man für ein 32x32 Pixel großes
Zeichen gerade einmal 128 Byte.

@Hubertus

du bist sowas von armsehlig...
schade, dass solche, wie du meinen sie muessen leuter persoehnlich
angreifen und somit solche foren, wie hier in den dreck ziehen
nunja du bist der beste mach weiter so..

hi, nochmal zu bascom ...

hat jemand vor, das ganze auch auf bascom zu portieren, oder bleibt ihr
lieber bei C ?

mfg Kay

In Bascom nicht aber in Assembler.

Gruß Lightning

@Christian:

>> Die Linien habe ich in alle 4-Richtungen diagonal getestet,
>> waren o.k.

Schlechter Test ;) versuche mal 4 Linien mit den Koordinaten

40,0 -> 60,176
60,0 -> 40,176
60,176 -> 40,0
40,176 -> 60,0

Deren Steigung ist < 1 in Y Richtung

Dann noch

0,78->128,98
0,98->128,78
128,98->0,78
128,78->0,98

Deren Steigung ist ebenfalls < 1 in X Richtung

Bei den Fonts gäbe es noch die Möglichkeit ohne Komprimierung zu
arbeiten. Man kann dann die Speicherzugruiffe auf die Fontdaten
entsprechend umbauen. Allerdigs hats eben mehrere Nachteile

1.) monochrome große Fonts werden normalerweise auf 1/4'tel oder sogar
1/8'tel der Größe komprimiert. Bei 16Kb also nur 2-4Kb an real
benötigtem Speicher, das ist ne Menge Holz.

2.) Der Code muß 4 Orientierungen separat umsetzen, für jede
Orientierung eine eigene Schleife, ergo mehr Programcode

3.) Man kann nun nicht mehr linear sequientiell die Fontdaten aus dem
Speicher laden. Das ist im ersten Moment für einen Laien kein größeres
Problem. Aber ich habe exakt auf dieses spezielle Feature Acht gegeben
damit man nämlich die Fontdaten in externen seriellen
Speicherbausteinen, oder SD/MMC Karten ablegen kann.
Bisher gibt man den Startadresse an dem ein Font beginnt vor. Beim
zeichnen eines Zeichens wird immer linear sequientiell ab dieser
Addresse die Daten aus dem Speicher gelesen.
Darauf müsste man dann verzichten.

4.) die bisherige innerste Loop der Fontroutinen ist so ausgelegt das
sie während 1 Byte übers HW-SPI im Hintergrund gesendet werden mit
maximal 16 Takten die nächsten Koordinaten berechnet und die Daten
dekomprimieren kann. Es entsteht also eine enorm hohe Performance der
Font-Routinen im Vergleich zum Datendurchsatz. Wie Ape schon oben
vorgerechnet hat: ein String mit 32 zeichen a 16x16 Pixeln und 16Bit
Farben muß an das Display 16Kb übertragen. Nur 32 Zeichen !!
Bei komprimierten Fonts ist aber die innerste Schleife samt Clipping
meistens schneller fertig mit den neuen Daten als das das HW-SPI seine
8 Bits rausschicken kann. Man erreicht also theoretisch Clock/2 MBit
Durchsatz.



Gruß Hagen

wäre es denn möglich, einen avr zu nehmen, der in Assembler oder C das
display ansteuert und die "daten" über die serielle bekommt ?

mein problem ist, das ich kein C und kein assembler kann. würde halt
gern mit bascom programmieren.

Hallo Kay,

ich werde mich nicht mit BASCOM beschäftigen. Allerdings dürfte - wenn
du dich ein wenig mit BASCOM auskennst - die Display Ansteuerung nicht
so schwer sein.

nach der Homepage kann Bascom:
a) SPI Interface ansprechen
b) externe C/Assembler Routinen aufrufen

D.h. für eigene Grafik-Routinen reicht a), wenn du die glcd benutzen
willst musst du dich mit b) beschäftigen...

Grüße
  Christian

alles klar danke

hab im oberen post den halben text vergessen. ich habe mir jetzt so ein
display bestellt. ich warte bis das display hier ist und werde dann mal
schauen wie weit ich komme. Will einfache Texte an einer bestimmten
position platzieren. und grafiken anzeigen lassen. vielleicht bekomme
ich das mit bascom ja hin. wenn nicht, dann halt nicht. probieren kann
man es ja mal.

mfg Kay

Ich habe Vorgestern mein Display (blaue Platine) erhalten. Doch
leider gelingt mir die Ansteuerung nicht.
Zuerst habe ich es mit Bascom versucht, da ich mit Basic schon
die Ansteuerungsroutinen für die Nokia-Displays 3510i und 6100
geschrieben habe.

Prinzipieller Ablauf (verkürzt wiedergegeben):
Mega128, 2.8 Volt, 4 MHz-Resonator, Port C
Reset (low), dann Pegel auf high
CS auf low, RS high (Commands)
Datenpin high/low setzen, mit CLK auf high wird Zustand eingelesen
die Wartezeiten zwischen Init1 und Init2 habe ich variiert (0-40 ms)
RS low für Daten

Leider tat sich nichts

Dann habe ich das Beispielprogramm simple_display3 genommen, das
Display an Port B angeschlossen, und im ASM-File Xtal auf 4 MHz
gesetzt, und make all vom AVR-GCC gestartet.
Dann das Gleiche nochmal mit dem internen kallibrierten 1 MHz
Oszillator ausprobiert.
Leider zeigte das Display keine Reaktion.

Jetzt bleiben noch 3 Möglichkeiten übrig:
Display ist defekt
Display is inkompatibel
ich habe irgendwas falsch gemacht (nur was?)
Vielleicht weiss einer Rat.

MartinK

Hallo Martin,

grundsätzlich hört sich das o.k. an. Läuft der atmega mit 2.8V
zuverlässig?

Drei Dinge:

a) mit so langsamen Takt habe ich das noch nicht probiert, der
langsamste waren 8MHz mit einem ATmega32

b) Für dein BASCOM: Ich glaube, das zwischen den Commands das CS
toggeln muss.

c) Blaue Platine? Bisher kenne ich nur die grüne und zwei verschiedene
braune....

Vorschläge:
-> Überprüfe die Verdrahtung mit den #defines in simple_display3
-> kannst du dir die Port Signale anschauen und überprüfen? Wenn ja
check die Verzögerung zwischen INIT1 und INIT2 mit dem Osci. sowie die
Daten
-> Überprüfe deinen Display Anschluss. Ich kann ESD Schutzdioden
zwischen den Steuersignalen und Supply/GND messen (ca. 1V mit meinem
Diodentester). Damit kannst du testen ob der Kontakt da ist.
-> Nehme Spannungsteiler, 5V und 16MHz

@MartinK

Kannst du bitte mal n Foto von dem Display
mit der blauen Platine Posten ??
(Vorder + Rückseite)

Mfg. Lightning

@Lightning

Tut mir Leid, aber momentan habe ich keine Digitalkamera.
Das Display habe ich bei Ebay ersteigert (Cellow),
sieht fast genauso aus wie das linke Display auf Christians
Homepage.

@Christian
Ich habe den Mega128L, kann max 8 MHz, läuft aber bei 2.8 Volt
zuverlässig.
Die Schutzdioden habe ich auch messen können mit Ausnahme von Pin 1
(RS), bei dem ich absolut nichts messen kann, vielleicht liegt
hier der Fehler.

MartinK

Das ist zumindest ein Fehler. Ich kann auch bei RS die Dioden messen.

@Christian

Die Signalleitung von Pin 1 (RS) ist definitiv irgendwo unterbrochen.
Im Übrigen gleicht mein Display deinem Grünen fast 100%ig, nur der
Lötstopplack meiner Platine ist blau. Sogar die Platinenaufdrucke
sind gleich.
Ich habe bei meinem Display den weissen unteren Platikrahmen
abmontiert. Dann habe ich kurz vor der Bending-Area, also dort, wo
die Leiterfolie auf die Platine geklebt ist, mit einem scharfen Cutter
den Lötstopplack von der Platine gekratzt. Da die Leiterbahnen
an dieser Stelle sehr klein und eng beianander liegen (etwa 60 auf 2,2
cm), habe ich mit einem akustischen Durchgangsprüfer die Signale
zwischen Leiterbahnen und Anschlusspins geprüft. Alle Pins mit
Ausnahme von RS gaben einen Signalton.
Der einzige Punkt, an dem ich noch ein Signal erhalte, ist der rechte
Lötpunkt von R4 (oder A4). Von da an verliere ich das Signal. Und bei
einer 4-Layer (oder noch mehr) Platine kann ich nichts mehr machen.
Vielleicht könntest du mir helfen. Von Reset und CS weiss ich, dass
das Signal bei einem Kondensator oder Widerstand wieder auftaucht.
(CLK taucht erst an der Bending-Area wieder auf). Vielleicht gibt es
eine direkte Verbindung zwischen RS und irgendeinem Baustein oder
Lötpunkt. Dann könnte ich einfach ein Kabel daran löten.
Unter dem weissen Abdeckrahmen sind keine Bausteine.

MartinK

abo

Martin,

habe gerade mein grünes Display untersucht:
a) ich kann RS nirgends, ausser an R4 finden

b) ich messe bei RS auch keine Schutzdiode!!!! Das ist ein Unterschied
zwischen den grünen/blauen Display und den braunen...

Grüße
  Christian

@ChristianK:

> Das ist ein Unterschied
> zwischen den grünen/blauen Display und den braunen...
Das heißt jetzt was genau? Ich werde wohl morgen auch
ein blaues erhalten (Cellow, ebay). Laut dem PDF sollte
es 3 Versionen geben (wohl blau, braun und grün). Sind jetzt
alle gleich oder nicht?

@MartinK:
Wenn meins morgen ankommt werde ich mich mal am WE dran begeben. Ich
meld mich dann mit den Ergebnissen.

Grüße,
André

Ach noch was. In der Artikelbeschreibung von Cellow ist aber ein ROTES
mit brauner(?) Folie abgebildet.

Laut PDF: Grün=Braun
Laut ChristianK: Grün=Blau!=Braun

Hilfe! Farbenwahn!

Grüße,
André

@Christian

Hast du das grüne Display mal ausprobiert?


@André

Ja, ich habe bei meiner Bestellung bei Cellow auch ein Display
mit einer rötlichen Platine gesehen.
Streng genommen ist meine Platine nicht rein blau, sondern hat einen
kleinen Grünstich, also dunkel-Türkis

MartinK

Hm.

Wenn meins morgen da ist, up ich mal 'nen Scan. Vielleicht sollte das
PDF dann um Eigenarten der verschiedenen Displaytypen ergänzt werden.

AK

Zum Aufklären des Farbwirrwars:

Also ich besitze:
a) ein braunes wie auf Web-Page abgebildet
b) ein braunes mit anderer Platine  (kein Foto, da eingebaut )
c) ein grünes wie auf Web-Page abgebildet

Diese drei verhalten sich gleich.

Martin hat jetzt noch ein türkis-farbenes das aber wie mein grünes
aussieht... und offensichtlich die gleiche Eigenschaft hat dass keine
Schutzstruktur am RS pin zu messen ist.

Hallo,

ich habe die Software (WEB und hier) nocheinmal upgedated. Grund ist,
dass das Display nicht immer zuverlässig gestartet ist. Es konnte
passieren, dass mehere Reset's nötig waren um das Display zu starten.
Wenn es dann einmal lief, lief es ohne Probleme.

Zuerst habe ich das auf meine unvollkommene Reset-Beschaltung
geschoben, konnte heute aber nachweisen, dass es nicht der µC ist der
die Probleme macht.

Also habe ich die init1 sequence in zwei Sequenzen aufgeteilt (wie beim
S65 gemessen) und eine Wartezeit von 68ms dazwischen eingebaut.

Bisher hat damit das Display problemlos funktioniert.

Grüße
  Christian

P.S: Diesmal habe ich die HEX-Files im Zip gelassen. Diese HEX Files
habe ich bei mir getestet und sie funktionieren.

Hy Leute,

Wenn ihr alle Arten von Displays untersucht habt,
schickt mir bitte Infos zu (oder hier Posten).
Dann werd ich in mein PDF da noch ne extra Rubrik
für die verschiedenen Displays und
deren Tücken, Farben,... etc. reinbasteln.

Gruß Lightning

Da stehen doch auch Typbezeichnungen auf der Rückseite drauf, z.B.
LPH8836 oder LS020...
Gibt es denn innerhalb eines Typs verschiedene Leiterplattenfarben?

Gruß
Roland

hi,

das display braucht ja eine Versorgungsspannung von 2,9V. macht es dem
display was aus, wenn es 3,3 V sind ? habe nämlich noch einen LM3574
den ich gerne benutzen würde. nur will ich auch nicht mein Display
schrotten.

mfg Kay

Ob 3.3V funktionieren weiss ich nicht, ich würde da aber erstmal keine
Experimente eingehen. Letztendlich hängt die ganze Spannungserzeugung
für das Glas daran.

dann muss ich wohl das ganze von 3,3 auf 2,9 V bringen. müsste doch mit
nem widerstand machbar sein oder ?

@Christian,

auf den Fotos auf Deiner Homepage ist ja auch ein LPH8836 zu erkennen.
Hast Du Deine Software auch mit dem LPH8836 getestet oder nur mit dem
anderen LS020-Typ?

Bei meinem LPH8836-3 funktioniert außer der LED-Beleuchtung leider noch
nichts. Verdrahtung habe ich schon mehrfach kontrolliert, am
Power-Up-Timing habe ich auch schon herumprobiert, leider ohne Erfolg.

Was mich etwas wundert: weshalb geht bei Dir das Power-Up-Timing
schief, wenn die Wartezeit zu groß ist? Eine Mindestzeit hätte ich
erwartet, aber eine Maximalzeit...?

Michael

Hi,

mein Cellow-LCD ist da. Grün (also kein Türkis wie bei MartinK).
Allerdings auch keine Typenbezeichnung drauf ;-(
Hoffe es ist ein LPH8836 (DAS sollte ja gehen). Layout
paßt schonmal.

Grüße,
AK

Meins ist auch da, ein braunes mit LS020..... über eb**

müsste auch passen

@André

Cellow scheint verschiedene Chargen zu verkaufen.
Meins sieht zwar genauso aus (außer der Farbe)
Als Herstelldatum auf dem weißen Kunststoff steht bei mir 4 04,
also 3 Monate jünger als deines.
Die Nummer auf dem weißem Aufklebr ist: 3738.1
Nummer auf der Platine (neben den Anschlüssen): 3320 010 2051.2

Mein Display läuft leider immer noch nicht.
Es wäre schön, wenn du bei erfolgreicher Ansteuerung dein Ergebnis
mal posten würdest.

MartinK

@MartinK

Ergebnisse kommen (wohl frühestens am WE).

Wenn Deins jünger ist, geh ich mal davon aus daß nur
der Lack-Hersteller gewechselt wurde. Deine Chancen (und meine)
stehen wohl gut ;-)

Grüße,
AK

Kann mir jemand die exakten Einbau-Masse des Displays nennen ? Danke im
Voraus an alle Hilfsbereiten.

   Daz

Hallo,

ich benutze derzeit ausschliesslich das Display, das auf der Web-Seite
rechts neben dem grünen zu sehen ist. (braun LSxxx)

Das grüne hatte ich nur einmal ganz kurz vor einiger Zeit im Betrieb.
Nur um zu testen ob es funktioniert. (damals hatte ich die Displays
übrigens parallel geschaltet, - beide zeigen dann das gleiche Bild...)

Die Ansteuersoftware hat sich danach noch geändert. Im wesentlichen
"Weg-Optimierungen" von "überflüssigen" CS toggeln, Änderungen im
Timing etc.

Es besteht daher eine gewisse Wahrscheinlichkeit, dass das grüne
Display mit der derzeitigen Ansteuerung nicht (mehr) funktioniert. Nach
dem Motto was nicht getestet ist funktioniert meist auch nicht.

Ich werde - frühestens am Wochenende - das grüne mal wieder
anschliessen. Dann kann ich näheres sagen.

Zu den Kodes:
LSxxxxxx Hersteller vmtl. Epson?
L2F50126 Hersteller vmtl. Epson
LPHxxxxx Hersteller vmtl. Philips?

Ihr könnt aber auch selber experimentieren. Die Timing's der
Original-Ansteuerung sind ja verfügbar. Im worst case muss man die
einfach exakt nachbauen...

ich habe jetzt über einen Spannungsteiler mit 2 Widerständen eine
Spannung von 3,034 V. Das müsste doch gehen für die Spannungsversorgung
vom Display oder ?

Noch ne Frage: Wieviel mA zieht das Display denn ?

mfg Kay

So hab jetzt mein Display auch endlich mal bekommen, braune Leiterplatte
LSxxx. 2,9V Versorgung über Spannungsregler, Level-Shifting über
Widerstände. Die Lib hat auf Anhieb funktioniert. Vielen Dank nochma
:)

Kleine Frage am Rande: Warum ist der zweite Versorgungspin des Display
1V8 benannt, obwohl er auch an den 2,9V hängt?

@Kay: Mit Spannungsteiler-Konstruktionen für die Versorgungsspannung
wär ich vorsichtig, da eine solche Versorgung per Definition einen sehr
hohen Innenwiderstand hat und daher die Spannung bei Lastwechseln stark
schwankt (Es sei denn du willst mit dem Spannungsteiler auch gleich
heizen). Hab noch nich gemessen wieviel das Display so aufnimmt und ob
sich die Stromaufnahme stark ändert, aber ein Spannungsregler ist doch
die bessere Wahl.

hi ape,

welchen Spannungsteiler benutzt du denn für das display ?
hast du das display schon ans laufen gebracht ?

mfg Kay

mhh ich meine natürlich Spannungsregler ...

@ape

Woher hast du das Display?
Hast du 16 MHz, oder funktioniert die Ansteuerung auch bei
niedrigeren Taktfrequenzen?

MartinK

Ich hab das ganze im Moment auf dem Steckbrett laufen und benutze einen
LM314 (einstellbarer Spg.regler), der is zwar etwas überdimensioniert,
aber das macht ja nichts :)

Ich hatte zunächst die Lib für 8MHz übersetzt und den Mega128 mit
internen 8MHz laufen, das hat wunderbar funktioniert. Als nächstes habe
ich die Lib für 16MHz kompiliert und einen 16MHz Quarz verwendet, damit
geht das Display aber nicht an. Wenn ich aber erstmal mit einem
langsamen Takt starte und dann auf 16MHz umstelle (Jumper auf dem
STk500 von Board-Takt auf Quarz-Takt umstecke) läuft das Display auch
problemlos.
Erscheint mir merkwürdig, ich muss das nochmal genauer untersuchen.

@ape

Mit Lib meinst du simple_display3 ?
Gut, dass das bei dir läuft.
Mit meinem 8 MHz Atmega128L hat das nicht funktioniert.
Vielleicht habe ich beim Compilieren etwas falsch gemacht.
Kannst du mir das fertige Hex-File für 8 MHz an meine E-Mail-Adresse
martin-k@x-mail.net schicken oder hier posten?
Wenn mein Display dann immer noch nicht funktioniert, dann ist es
entweder kaputt oder inkompatibel.
Mein Mega128L funktioniert einwandfrei, das habe ich überprüft.

MartinK

@Fabian
Super, endlich mal ein Erfolg :-)
Die 1V8 Spannung heisst so, weil im Original hier 1.8V anliegen. Das
ist die von Siemens benutzte Interface-Spannung. Bei allen mir
bekannten Display Controllern ist diese allerdings sehr weit
spezifiziert üblicherweise immer bis hin zur Display-Spannung. Darum
habe ich sie auch an die 2.8V gehangen.

16MHz Problem: Hast du die neue Version mit den 3-Init Sequenzen
benutzt? (die die aktuell unter download steht) Die läuft bei mir mit
16-MHz wirklich völlig problemlos. Allerdings ist das Timing am SPI-Bus
mit den passiven Level-Shiftern bei 8MHz SPI-Clock schon nicht mehr
optimal. Ich überlege schon, ob ich für das spätere Gerät nicht aktive
Level-Shifter verwenden soll.

Grüße
  Christian

Hallo ich hab jetzt nochmal die neueste Lib von deienr Seite
runtergeladen aber das hat keine Änderung gebracht. Vielleicht kannst
du in einer nächsten Version den SPI Clock fürs Init etwas runtersetzen
und  erst danach voll aufdrehen.

Ich denke spätestens wenn ich ein Gerät mit dem Display baue, werde ich
aktive Level-Shifter einsetzen, aber so fürs steckbrett wars erstmal die
einfachste und schnellste Lösung :)

Im Anhang mal nochn Bild, kommt auf dem Foto nicht gut rüber, aber ich
bin positiv überrascht von der Bildqualität des LCDs, ist wirklich um
Längen besser als das Nokia 6100...

@Martin: Nein das simple_display hab ich nicht ausprobiert sondern
gleich die portierte glcd Library verwendet. Ich hab dir mal das Hex
File per Mail geschickt.

@ape

Danke für das File.
Leider funktioniert das Display immer noch nicht.
Ich habe extra noch mal alle Kabel neu angelötet.
Ich schätze, ich werde mir ein braunes Display bestellen.

MartinK

Schaut euch mal dieses Angebot bei Ebay an:
http://cgi.ebay.de/Original-Siemens-M65-M-65-Farb-...
Laut Anbieter ist ein M65-Display nicht mit S65 kompatibel,
während andere Händler keinen Unterschied machen.
Vielleicht ist mein Display nur M65 kompatibel.

MartinK

Für was genötigt man diese Levelshifter ? ich dachte, es reicht, eine
2,9V Spannung und die 10,4 V für die Hintergrundbeleuchtung ?

mfg Kay

@Kay: Nix für ungut, aber du weißt schon was du tust? Die Level-Shifter
brauch man um die Pegel auf der Schnittstelle zwischen Controller und
Display anzupassen. Schließlich läuft der AVR bei 2,9V nicht mehr mit
voller Taktrate (wenn man Glück hat schon, aber man ist dann schon sher
weit außerhlab der Specs...). Die einfach-Lösung besteht darin mit
Spannungsteilern die Signal-pegel runterzuteilen. Steht glaub ich auch
irgendwo weiter oben im Thread. Jedenfalls sind aber durch die relativ
hohen Widerstände die Signale bei hohen Frequenzen nicht mehr sehr
schön. Ein aktiver Level-Shifter schafft da Abhilfe.

@all: Für einen Einsatz im Querformat ist das Display übrigens nicht
sehr gut geeignet, da der Blickwinkel für den Einsatz im Handy
optimiert zu sein scheint. Der beste Kontrast ergibt sich, wenn man von
unten leicht schräg auf das Display schaut. Bei senkrechtem Blickwinkel
oder gar von der Seite leidet der Kontrast doch recht massiv.

So hab nun auch das Init Problem bei 16MHz behoben. Und zwar hab ich die
init Routine so geändert das das Double Speed Bit erst nach der
eigentlichen Initialisierung gesetzt wird. Also hier (glcd_init.asm):

;   write initial screen command (i think not necessary...)
    cbi LCD_PORT,LCD_CS ;select Display

    ldi T1,0xEF
    rcall   glcdDispCommand
    ldi T1,0x90
    rcall   glcdDispCommand
    ldi T1,0x00
    rcall   glcdDispCommand
    ldi T1,0x00
    rcall   glcdDispCommand

    ldi     r24,1               ; double speed bit
    out     LCD_SPSR,r24

        rcall   lcd_clrscr

    pop     r31
    pop     r30
    ret

Hatten wir das gleiche Problem nicht auch schon beim Nokia Display ?

Gruß Hagen

Naja zumindest ist der Blickwinkel beim Nokia auch nicht sehr groß. Das
Problem beim Siemens Display lag aber zum Teil auch an mir :) Der
Spannunsgregler war nich ganz richtig beschaltet das Display hatte nur
2V Versorgungsspannung... Jetzt kann man auch senkrecht aufs Display
gucken, aber sonderlich groß is der Sichtbereich trotzdem nich.
Ich denke mal mein Problem mit den 16MHz lag auch dadran, aber ein
etwas langsameres Init kann denk ich trotzdem nich schaden :)