www.mikrocontroller.net

Forum: Projekte & Code The Siemens S65 132x176, 65536 color display with AVR


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

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

Autor: Fabian Thiele (ape)
Datum:

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

Autor: Joachim Börke (joachimb)
Datum:

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

Autor: Christian K. (christiank)
Datum:

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

Autor: Andy (Gast)
Datum:

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

Autor: MartinK (Gast)
Datum:

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

Autor: Christian K. (christiank)
Datum:

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

Autor: Kay (Gast)
Datum:

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

Autor: Hubertus (Gast)
Datum:

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

Autor: Hubertus (Gast)
Datum:

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

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

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

Autor: Tobias Schneider (tobias)
Datum:

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

Autor: Hagen (Gast)
Datum:

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

Autor: Lightning (Gast)
Datum:

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

Autor: Christian K. (christiank)
Datum:

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

Autor: Fabian Thiele (ape)
Datum:

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

Autor: Jens D. (jens) Benutzerseite
Datum:

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

Autor: Kay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi, nochmal zu bascom ...

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

mfg Kay

Autor: Lightning (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In Bascom nicht aber in Assembler.

Gruß Lightning

Autor: Hagen (Gast)
Datum:

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

Autor: Kay (Gast)
Datum:

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

Autor: Christian K. (christiank)
Datum:

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

Autor: Kay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alles klar danke

Autor: Kay (Gast)
Datum:

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

Autor: MartinK (Gast)
Datum:

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

Autor: Christian K. (christiank)
Datum:

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

Autor: Lightning (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK

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

Mfg. Lightning

Autor: MartinK (Gast)
Datum:

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

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist zumindest ein Fehler. Ich kann auch bei RS die Dioden messen.

Autor: MartinK (Gast)
Datum:

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

Autor: Flo K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: ChristianK (Gast)
Datum:

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

Autor: André Kronfeldt (Gast)
Datum:

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

Autor: André Kronfeldt (Gast)
Datum:

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

Autor: MartinK (Gast)
Datum:

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

Autor: André Kronfeldt (Gast)
Datum:

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

Autor: ChristianK (Gast)
Datum:

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

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

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

Autor: Lightning (Gast)
Datum:

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

Autor: Michael (Gast)
Datum:

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

Autor: Kay (Gast)
Datum:

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

Autor: Christian K. (christiank)
Datum:

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

Autor: Kay (Gast)
Datum:

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

Autor: Michael (Gast)
Datum:

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

Autor: André Kronfeldt (Gast)
Datum:
Angehängte Dateien:

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

Autor: Kay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meins ist auch da, ein braunes mit LS020..... über eb**

müsste auch passen

Autor: MartinK (Gast)
Datum:

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

Autor: André Kronfeldt (Gast)
Datum:

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

Autor: The Daz (Gast)
Datum:

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

   Daz

Autor: Christian K. (christiank)
Datum:

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

Autor: Kay (Gast)
Datum:

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

Autor: Fabian Thiele (ape)
Datum:

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

Autor: Kay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi ape,

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

mfg Kay

Autor: Kay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mhh ich meine natürlich Spannungsregler ...

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ape

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

MartinK

Autor: Fabian Thiele (ape)
Datum:

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

Autor: MartinK (Gast)
Datum:

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

Autor: Christian K. (christiank)
Datum:

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

Autor: Fabian Thiele (ape)
Datum:
Angehängte Dateien:

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

Autor: MartinK (Gast)
Datum:

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

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schaut euch mal dieses Angebot bei Ebay an:
Ebay-Artikel Nr. 6444305427
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

Autor: Kay (Gast)
Datum:

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

Autor: Fabian Thiele (ape)
Datum:

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

Autor: Fabian Thiele (ape)
Datum:

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

Autor: Hagen (Gast)
Datum:

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

Gruß Hagen

Autor: Fabian Thiele (ape)
Datum:

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

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

schlechte Nachrichten für alle grünen und blauen...

Ich habe gerade das grüne Display LPHxxx angeschlossen. Mit der
aktuellen Software läuft es nicht! Ich habe auch bereits ein wenig am
Timing gespielt, es aber nicht zum laufen gebracht.

Vorher hatte ich es zum Test in das S65 eingesetzt und dort hat es
funktioniert. (Daher glaube ich die Theorie mit dem M65 nicht)

-> Vorerst als nur das LSxxx Display kaufen! (braun, rechts auf dem
Bild)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian:

Wenn es im S65 funktioniert hat, aber mit Deiner eigenen Ansteuerung
nicht, dann wird beim LPHxx vermutlich doch ein anderes Protokoll
gefahren als beim LSxxx, d.h. in der Handysoftware wird erkannt, um
welches Display es sich handelt, ähnlich wie beim Nokia 6100 Philips /
Epson, z.B. durch Abfrage eines Identifikationsregisters.

Wenn Du das Protokoll des Handys mit eingesetztem LPHxx nochmal
aufzeichnen könntest, wäre das natürlich super. Ich weiss, ist viel
Arbeit. Ich würde es auch selber machen, habe aber leider kein S65 und
nur dafür eines kaufen ist mir dann dann doch etwws zu teuer... ;-)

Gruß
Michael

Autor: Fabian Thiele (ape)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von weiter oben:

"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."

Wenn ich das richtig verstehe hat es ja schonmal funktioniert :)

Autor: ChristianK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich bin mir ziemlich sicher (ich werde schon vorsichtiger...), dass
ich das grüne und das braune parallel in Betrieb hatte. Ich wollte ja
wissen ob sie kompatibel sind... Darum sollten sie - wenigstens für
init - einen ähnlichen Befehlssatz haben.

Ich vermute, dass es eine blöde Kleinigkeit ist, die hier das grüne
Display blockiert. Z.B. falsche Pegel auf RS/CS/CLK/DAT lines wärend
der RESET Flanke...

Ich habe jetzt schon einiges probiert, leider immer noch ohne Erfolg...

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ChristianK:

auf Deiner Homepage steht 10,4V/20mA für die HB. Müßte die
Gesamtspannung in "Schematic" dann nicht 14V sein (steht 15V drin)?
10,4+180Ohm*20mA = 14V. Wie ist das denn bei der HB, wenn die 5mA mehr
Strom (immerhin 25%) bekommt?

Grüße,
AK

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andre,

ich kenne die Spezifikation der LED's nicht und habe mir den Aufbau
der Hintergrundbeleuchtung auch noch nicht genau angeschaut.

Im Moment gehe ich von drei in Reihe geschalteten LED's aus. D.h. bis
zu max. 30mA Dauerstrom (je nach gewünschter
Helligkeit/Batterie-Lebensdauer) sollte erlaubt sein. (sollten es 2x3
in Reihe geschaltete LED's sein müsste der Strom höher eingestellt
werden...)

Deine Rechnung stimmt. Aber der Messwert 10.4V@20mA gilt natürlich nur
für dieses eine Display bei der damaligen Temperatur.

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

danke. Dann mach ich mich mal dran. Hab Deinen Code für einen
ATmega8515 kompiliert (wegen DIP-Gehäuse und ein anderer war gerade
nicht da). Werde einen 74HC573 als LevelShifter nötigen. Mal sehen ob
mein LCD damit funzt ...

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fabian Thiele

könntest du eventuell mal deinen Code posten mit dem du die Bitmap
ausgibst? Wo hast du die gespeichert ? Wenn ich richtig rechne hat das
Display eine Auflösung von 132x176 Pixel also 23232 Bildpunkte bei 16
bit Farbtiefe sind das etwa 45kb?

Autor: Fabian Thiele (ape)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sende die Bilder über die serielle Schnittstelle vom PC. War nur nen
einfaches Test-Programm ohne jegliches Protokoll oder so. Das ganze
"Programm" sieht so aus:
void recvPicture(void) {
  uint8_t x=0, y=175;
  glcdColor_t pix;
  
  for(uint16_t i=0; i<23232; i++) {
    pix = get()<<8;
    pix |= get();
    glcdSetPixel(x, y--, pix);
    if(y == 255) {
      y=175;
      x++;
    }
  }
}

get() empfängt ein Byte übers UART, die Üebrtragung erfolgt mit
460kBaud, das Bild zu übertragen dauert ca. 1 Sekunde. Ich weiß auch
das die Funktion glcdSetPixel() für diesen Zweck nicht optimal ist, da
ja jedes Mal auch wieder die Position auf dem Display neu egsetzt wird,
was jede Menge Overhead bedeutet, aber zum Testen reichts :)

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die schnelle Antwort. Hast du ein speiziellen Programm mit dem
du die Daten an den UART schickst oder verwedest du einfach das
Hyperterminal und benutzt du die Funktion Datei schicken?

Autor: Fabian Thiele (ape)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mir ein kleines Java-Programm geschrieben, was die Bilder öffnet
in die richtige Größe konvertiert, nach 16-Bit umrechnet und dann
einfach die nackten Pixeldaten an den AVR sendet. Hyper-Terminal oder
sowas funktioniert nicht, da das ja ein Protokoll zur Dateiübertragung
verwenden würde, außerdem haben ja auch Bitmaps nen Header und auch
nicht die passende Farbtiefe.

Hab mein Programm mal angehangen, vielleicht kannst du ja was mit
anfangen. Mit run.bat starten, Bild öffnen (gif, jpg oder png) Com-Port
auswählen und senden. Baudrate ist fest auf 460kBaud, wenn das zu Viel
ist musst dus im Quelltext anpassen udn neu kompilieren :). Wenn man
ein Verzeichnis öffnet, werden alle enthaltenen Bilder im 15 Sekunden
Takt als Slideshow angezeigt.
Achja und du brauchst natürlich eine aktuelle Java Runtime Environment.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Programm scheint schon mal super zu sein. Leider hackt es auf dem
Atmel noch etwas. Die Zeile "pix = get()<<8;" erzeugt beim
Kompilieren den Fehler: undefined reference to `get'.

Autor: Fabian Thiele (ape)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ja klar, das is ja keine Library Funktion. Die Funktion empfängt einfach
ein Byte übers UART. Hatte sie jetzt oben nicht mit gepostet weil ich
das eigentlich für Trivial gehalten habe :)

Im Anhang mal der Komplette Code für den AVR (mega128). Takt ist
18,432MHz. Wenn du einen anderen Takt verwendest, musst du den Wert für
UBRR0L anpassen um die passende Baudrate zu behalten.

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schlechte Nachrichten für alle Besitzer von grünen Displays (LPH) und
Epson (L2F) Displays. Ich habe - nachdem ich alle Variationen der
Ansteuerung mit dem grünen Display erfolglos durchgefahren habe - den
Parallel-Test wiederholt. D.h. ich habe ein Epson Display (L2F)
(eingebaut) jeweils mit einem grünen (LPH) und dem braunen (LS0)
ausserhalb und parallel am S65 betrieben.

Leider ohne Erfolg. Es hat immer das externe Display gewonnen und den
Inhalt angezeigt, wobei das interne L2F leer blieb. Ohne externes hat
das interne funktioniert.

-> Das S65 hat wohl eine Funktion um das Display zu erkennen

-> Beim letzten mal muss ich wohl doch zwei gleiche Displays parallel
geschaltet haben

-> jedes Display wird seinen eigenen Befehlssatz haben

Immerhin lässt das hoffen, dass das Epson kompatibel zu einem Epson
Befehlssatz ist (d.h. mehr Addressierungsmodies, 0-Grad Betrieb mit
glcd...)

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt definitiv 2 verschiedene Controller:
www.siediyer.com/Doc/x65SRD.pdf
Seite 30

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MarinK,

toller Link - danke. Ich habe lange versucht das S65 repair manual zu
finden, aber keiner der Links und Quellen hat funktioniert...

Jetzt kennen wir zumindest schon die LED-Spec (15mA). Ich denke aber es
gibt drei Hersteller (ich habe die drei Bilder auf meiner Web-Page).
Eins kommt definitiv von EPSON (steht drauf).

Wenn sie über die Widerstandswerte identifiziert werden kann man ja mal
nachmessen...

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

> For the display two different sources are used, which
> will be distinguished by the software via different
> code resistor values.
Bin ich noch zu müde? Hat jemand gefunden WIE man die LCDs erkennt?
'Resistor' scheint klar, aber welcher?

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ChristianK:

> ich habe ein Epson Display (L2F) (eingebaut) jeweils mit einem grünen
> (LPH) und dem braunen (LS0) ausserhalb und parallel am S65 betrieben.

> Leider ohne Erfolg. Es hat immer das externe Display gewonnen und
den
> Inhalt angezeigt, wobei das interne L2F leer blieb. Ohne externes
hat
> das interne funktioniert.
Ok. Heißt also L2F!=LPH und L2F!=LS0.

Laut Datenblatt gibt es 2(!) verschiedene Typen.
Wenn L2F!=LPH ist und L2F!=LS0, MUß LS0=LPH sein => Deine Routinen
sollten auch mit dem LPH funktionieren.

Allerdings befürchte ich noch eine andere Fehlerquelle:
Die Widerstandskodierung dürfte nicht funktionieren bei 2 parallelen
LCDs.

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Christian, du hast ja alle drei sorten displays, kannst du mal
nachmessen:

Widerstand zwischen masse und RESET:
- L2F50xxx -> 52,46Kohm
- LPH88xxx -> 20,1Mohm
- LS020xxx ->  ??

Widerstand zwischen masse und CS:
- L2F50xxx -> 27,6Mohm
- LPH88xxx -> 25,2Mohm
- LS020xxx ->  ??

Ich habe mit eine philips PM2525 (multimeter) gemessen und die com vom
messgerät auch an die masse vom display gehalten.

Nur der RESET und CS gehen zum ARM9 (SGold-Lite PM8875) controller,
also können das meiner meinung nach die einzige pin zur display
erkennung sein.

Die andere pins (CLK, DAT, RS) gehen zum S1D13732, also keine
möglichkeit zur erkennung.

Grüße Mark,

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

das deckt sich ja mit meiner Theorie. Wenn das LS 20,1MOhm hat zwischen
GND und RESET besauf ich mich heute abend ;-)
Ich denke nicht, daß die 2MOhm Unterschied am CS relevant sind.
Ich meß mal mein Display gleich nach.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian:

Hättest Du denn Zeit und Lust, das Protokoll des ans S65
angeschlossenen LPHxx nochmal mitzuloggen?

Hab leider kein S65, sonst würde ich es selbst versuchen, aber falls
mich jemand mit einem S65 sponsern möchte, jederzeit gerne... ;-)

Gruß
Michael

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alle,

Kennt jemand das Siemens CXT65 ?

Grüße Mark,

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat sich erledigd, das CXT65 hat das gleiche display.

Grüße Mark,

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Freunde der grünen und blauen Display's,

jetzt wartet Arbeit auf euch....

Hier ein C-Programm zur Ansteuerung des Displays. FillScreen()
funktioniert tadellos aber ihr werdet sehen, dass die Textausgabe noch
nicht ganz korrekt ist. Die Position und die Breite stimmt schon - aber
die Höhe noch nicht...  Die Zeichen sind ein wenig verschoben und nur
halb ausgegeben.

Also macht euch an die Arbeit und unterstützt beim Suchen der richtigen
Ansteuerung....

Grüße
  Christian

Autor: Mark De jong (mark_de_jong)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

Das sieht danach aus das der HD66766 Controller drauf ist.

Grüße Mark,

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

Bewertung
0 lesenswert
nicht lesenswert
Das wäre natürlich super wenn es der HD66766 oder ein kompatibler
wäre...

Hier noch ein Bild zum obigen Program. Ich werde die nächsten Tage
nicht unterstützen können also viel Erfolg.

Grüße
  Christian

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich weiß nicht ob das mitten in diesen Thread gehört, aber:

!!! EIN FETTES DANKE UND MERCI AN CHRISTIAN KRANZ FÜR SEINE MÜHEN
UND UNTERSTÜTZUNG !!!

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

Bewertung
0 lesenswert
nicht lesenswert
@André
Dem kann ich nur zustimmen!

@Christian
Die Ansteuerung hat geklappt, bis auf die Textausgabe. Zur
Weiterentwicklung der Ansteuerung bin ich noch nicht gekommen,
weil ich heute ein LS020-Display bekommen habe (Ebay, PID-Handy),
das ich auf Anhieb auch zum Laufen bekommen habe.
Mir ist aber aufgefallen, dass das LS020-Display wesentlich
heller ist. Im Dateianhang ist ein Bild von beiden Displays, deren
Hintergrundbeleuchtung mit je 12 mA betrieben wird
(links LS020, rechts LPH88)
Außerdem scheint das LS020-Display gleichmäßiger beleuchtet zu sein.

MartinK

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

Bewertung
0 lesenswert
nicht lesenswert
and the winner is

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alle,

Ich arbeite gerade an eine platine für das Display.

Ich will ein Platine machen mit:
- +3.3volt oder +5 volt eingang.
- Spannungs regler für 2.8 volt.
- Spannungs regler für hintergrundbeleuchtung, PWM geregelt.
- Level wandler für signale.
- 10 polige stifleiste mit 2,54mm abstand.
- etwas größer als das display.
- größe 38.8mm x 60mm

Soll noch etwas mit drauf?

Grüße Mark,

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

Bewertung
0 lesenswert
nicht lesenswert
O.k. nachdem das Datenblatt verfügbar ist (es handelt sich tatsächlich
um einen HD66766 kompatiblen Controller :-) war es ja nur noch eine
Sache von Minuten...

Das LPH hat auch seine Vorteile:
a) einfacher zu löten, da keine Folie
b) Datenblatt verfügbar! D.h. mehr Möglichkeiten

Jetzt muss ich mich aber um etwas anderes kümmern.

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian
Hat das L2F50xxx-Display vielleicht auch einen HD66766?
Wie hell ist dieses Display im Vergleich zu den anderen?

MartinK

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mir ist kein gravierender Unterschied zwischen den Displays
aufgefallen.

Beim LPH ändern sich die Farben etwas, wenn man schräg draufschaut,
dafür finde ich die Farben etwas satter.

Ich habe auch keinen grossen Helligkeitsunterschied festgestellt. Die
LPH LED forward-voltage ist ca. 0.5V höher (bei mir) als beim LS020.
Ich betreibe die Displays aber auch mit etwas mehr als 20mA.

@André:
Danke, mache ich auch nur weil ich am Anfang irrtümlich versprochen
habe die Displays sind kompatibel :-)

@MartinK:
Das L2F50 hat einen EPSON Controller. Die Ansteuerung liegt hier schon,
brauche nur noch einmal 1-2h Zeit...

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian:
Weisst Du welche EPSON controller drauf ist?

Ich glaube es nicht der HD66766 sondern der HD66773, ich habe die
register nochmal gecheckt.

Grüße Mark,

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hab gerade eben diesen Thread entdeckt. Super sache!
Ich hab mit die Seite von Christian angesehen, dabei ist mir folgende
Frage eingefallen:
Kann ich die 10,4V für die Hintergrundbeleuchtung aus dem Power-Booster
des LCD-Controllers abziehen?
Meint, hat der Booster reseven, sodaß er auch diesen Strom noch
abzapfen läßt?
Würd die Ansteuerplatine erheblich vereinfachen.

abo

Mario

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mario
Die Spannung vom Booster beträgt etwa 12,5 Volt (LPH Display).
Wenn ich die LEDs daran anschließe, liefert dieser nur einen
sehr geringen Strom von etwa 0.4 mA, also viel zu wenig.

MartinK

Autor: Ralf Kirmis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark

Ich  bin an einer solchen Platine interessiert und
bitte um Info, sobald es Neuigkeiten in Bezug auf Preis
und Lieferzeit gibt.
Vielen Dank.

Gruss,
Ralf

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es nur die Platine oder mit Display? Ja und der Preis wäre gut.

Autor: Nullblicker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mark,

--> Soll noch etwas mit drauf?

- Joystick, siehe Butterfly Board
- PS2-Tastatur Eingang
- SD-Card Steckplatz

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht 7 Tasten zur Steuerung, es soll ja bezahlbar bleiben,
verschiede Versionen mit Joystick und SD-Slot, gibts den auch als
Bausatz?

Vielleicht noch  Version mit einen ATMEGA µC und SD-KArte.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark,

ich glaube an so einer Platine gibt's viele interessierte. Mit einer
SD-Karte und der Java nanoVM hätte man dann ein richtig tolles und
günstiges Kleincomputersystem, vorallem mit Farb-Display :))
Zudem gibt's dann sicher genügend freiwillige die fleißig daran
herumbasteln.

Ich habe mir jedenfalls soeben von Cellow ein so ein Display geordert.
Mal sehen wann es da ist.

Gruß
Mario

Autor: jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will ne Kaffeemaschine mit drauf haben!

Autor: Kay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark

ich wäre schon ganz zufrieden damit, wenn auf der Platine die
Levelshifter und der Spannungsconverter für die 2,9V drauf wären.

kannst dann mal bescheid sagen, was die platine kosten würde.

mfg Kay

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark

Denke auch, daß die nötigsten Komponenten reichen (2,9V-Regler,
Levelshifter) vielleicht noch der Konverter für die HB.

@ChristianK

Mein LCD leuchtet zwar grün, aber kein Text ist zu sehen. Nur bunte
Balken in der ersten Pixelreihe. Wird wohl noch ein Timing-Problem bei
mir sein.

Dein Quellcode definert kein F_CPU (wird für delay_ms() benötigt). Der
Compiler setzt zwar als default 1000000UL, aber das klappt nicht
immer.
Wenn ich die Optimierung ausschalte (OPT=0), funktioniert das LCD nicht
(kein Init). Auch ein wenig seltsam.

Aber ich arbeite dran.

Grüße,
AK

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@André

Bei mir läuft die Ansteuerung (grünes Display) einwandfrei sowohl
bei 1 Mhz als auch 8 MHz, obwohl ich Christians originale
Hex-Datei (16 MHz) zum flashen genommen habe, ohne sie neu
zu compilieren.

MartinK

Autor: Mark De jong (mark_de_jong)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hat jemand schon das EPSON (L2F50126) display getestet?

Das LS020B8UD06 hat glaube ich denn LR38826 controller drauf.
Wenn mann sich seite 14 vom Datenblatt vom LQ022B8UD04 display ansieht,
erkennt mann die kommandos wieder.

Ich habe das Datenblatt vom LR38826 noch nicht gefunde, nur einen
übersicht.

Grüße Mark,

Autor: Kay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kurze frage:

wo finde ich bei reichelt einen 2,9V regulator ?


mfg Kay

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mark,

einige Kommandos scheinen gleich zu sein -> Also ist Sharp der
Hersteller :-)

Nur die wichtigen Kommandos wie wie VRAM writing stimmen nicht.

Aber: Du bist nahe dran, hast du noch mehr von Sharp?

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

Leider (noch) nicht, hast Du denn Epson schon getestet?
Anfrage bei sharp hat noch nichts gebracht, anfrage bei epson lauft.

Grüße Mark,

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kay: versuchst mal mit LM317 kann man die Spannung mit 2 Widerständen
einstellen. Datenblatt gibt bei reichlet

Autor: Kay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke, schau ich mir gleich mal an

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

so. Mein LCD geht mit dem Code jetzt auch. Der Fehler war nicht in der
Ansteuerung selbst, sondern mir scheint der AVR-GCC noch nicht
ausgereift genug zu sein.

Erklärung:
- Sobald der Code mit 'OPT=0' kompiliert wird läuft er bei mir
nicht.
- Bei 'OPT=3' werden Warteschleifen wegoptimiert.
  Sind zwar simple for-schleifen ohne Inhalt, aber kein Grund es
  zu übertreiben.
- Nur einige Zeichen gehen (wohl Zugriffsprobleme bei großen Arrays)

Ich habe für die Änderung an den ATmega8515 nur die Portpins
(funktioniert, da Ansteuerung geht) und das Compiler-Ziel (MCU)
angepaßt. Zusätzlich hab ich noch ein F_CPU gesetzt, was aber wohl
nicht unbedingt nötig ist (Wartezeiten sind da wohl nicht so
kritisch).

Entweder mach ich was falsch, oder das Teil ist für den ATmega8515
nicht zu gebrauchen.

Grüße,
André

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andre,

der Code war nur als einfaches, sofort zu verstehendes Beispiel
gedacht, daher liegen alle Daten (ASCII sowie Display) im RAM! (Denn
dar AVR braucht spezifische (non ANSI) Befehle für den Zugriff auf den
Program-Speicher.

Ich kenne den ATmega8515 nicht, aber ich vermute, du hast zu wenig RAM.
Daher solltest du die ganzen Arrays in den Program-Space verschieben.
Wie das geht steht sehr gut hier im AVR-GCC Tutorial beschrieben.

Vielleicht sollte ich den Beispielcode dementsprechend ändern....

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

danke aber nicht nötig. Denke Du hast Recht mit dem Problem. Das sollte
aber vom AVR-GCC erkannt werden und - entweder Abbruch mit Fehler - oder
die Daten ins .cseg und mit LPM zugreifen. Naja. Vielleicht lese ich
erstmal ein wenig und übe, bevor ich den Thread mit Sachen zumülle die
nichts mit der LCD-Ansteuerung zu tun haben ;-)

Grüße,
André

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian

Betrifft LS020-Display
Ich habe eine einfache Ansteuerung in Bascom geschrieben.
Dabei habe ich festgestellt, dass ohne die beiden Befehle
EF90 0000 nach der Initialisierungssequenz auf dem Bildschirm
nichts erscheint. (in deinem Asm-File steht dazu: I think not
necessary...)

MartinK

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian

Außerdem habe ich festgestellt, dass die Zeit zwischen Init2 und
Init3 zwar eine Mindestzeit von etwa 7 ms haben muss, doch die
Maximalzeit ist unbegrenzt (1 Sekunde funktioniert bei mir noch)

MartinK

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MartinK,

zur Mindestzeit:
ich könnte mir vorstellen, dass es daran liegt, das es jetzt 3-Init
Sequenzen gibt (am Anfang hatte ich nur 2). Der Display reset 0xFDFD
war vorher wohl noch nicht sauber gelaufen. Jetzt kannst du das ja mal
ausprobieren :-)

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
hab das PDF ein bisschen erweitert. Falls irgendwo Fehler
drinn sind bitte mir sagen.

Gruss Lightning

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lightning,

Der Controller ist der HD66773 und nicht der HD66766.

Kannst du nocht die init für das LPH88 display hinzufügen?

Grüße Mark,

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann das sein das das LS020 am meisten  bei Ebay verkauft wird (
gelbliche Platine ) und der LPH88 ein auslauf Modell ist das L2S50
sieht man auch ab und zu.

Frage: Aber ich es jetzt richtig verstanden das , nur der LPH88 im
Moment läuft? Wie weit seit Ihr mit den anderen?

Ich ohne bedenken LS020 kaufen oder erstmal abwarten?

Für welche Displays kann man verwenden.

Bitte - gebt bei den Posts an welches Display ihr meint , sonst kommt
man ja durcheinander.

Gute Arbeits Jungs!!!!

Autor: Lightning (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark de Jong

Ist die INIT für das LPH88 Display die mit den
3 einzelnen Inits ??

~ Lightning

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Dirk:
Den mehr oder weniger aktuellen Stand findest du hier:

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

Grüße
  Christian

Im Moment ist das LPH88 und LS020 supported. Das L2F50 hoffentlich
bald.

Die GLCD gibt es derzeit nur für das LS020, ein gleichwertiger Port für
das LPH88 ist einfach möglich. Für das L2F50 könnte es schwieriger
werden, da es anscheinend keine Addressierungs-Modi unterstützt.

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark de Jong:

>HD66773 und nicht der HD66766

Wieso denkst du es ist das HD66773? Hast du die Specification davon?
Wenn ja würden mich die Grafik-Befehle interessieren bzw. ob sie sich
vom HD66766 unterscheiden.

Die Grafik-Befehle die ich benutze sind zum HD66766 kompatibel.

Grüße
  Christian

Autor: Mark De jong (mark_de_jong)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

Wenn mann die init anschaut schreib er auch zu register 0x0D und 0x0E
beim init.
Die gibt beim HD66766 nicht, aber beim HD66773 schon.

Deshalb glaube ich das es der HD66773 ist.

Grüße Mark,

Autor: Lightning (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark de Jong

Wenn ich die INIT für den LPH88 auch ins PDF
reinschreiben soll muss ich wissen welche
Init das ist.

Jetzt sind auf der Homepage vom
Christian Kranz da auf einmal 3 einzelne
Inits. Warum ?? Hab ich was verpasst ??

Gruß Lightning

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lightning:
Am besten wartest du, bis alles 100% deutlich ist.

Grüße Mark,

Autor: Lightning (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark de Jong
Ja ist wohl das beste. Wenns soweit ist poste
ich dann das neue PDF.

Gruß Lightning

Autor: Mark De jong (mark_de_jong)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich schreibe gerade an meine software library die ich auch frei
verfügbar machen werde (pre-beta, längst nicht alles ist drin).

Ich schreibe sie für denn MSP430 (IAR Embedded Workbench), er soll aber
auch für denn Atmel werden (brauche jemand der dabei hilft).

Ich werde das font-tool von Ape benutzen.

Der low-level treiber ist für pin toggle und SPI-hardware ausgelegd.

Grüße Mark,

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich plane zwei Platinen:

1. Minimal platine (fertig für produktion):
- mit oder ohne display lieferbar.
- +3.3volt oder +5 volt eingang.
- Spannungs regler für 2.8 volt.
- Spannungs regler für hintergrundbeleuchtung, PWM geregelt.
- Level wandler für signale.
- 10 polige stifleiste mit 2,54mm abstand.
- etwas größer als das display.
- größe 40mm x 60mm

2. MMI platine (in arbeit)
- nur mit display lieferbar.
- 5 volt eingang.
- MSP430F15x/MSP430F16x/MSP430F161x microcontroller.
- JTAG anschluss.
- I2C anschluss mit pegel anpassung.
- RS232 V24 anschluss.
- bis zu 64Kbytes EEPROM (smd)
- Spannungs regler für 3.3 volt und 2.8 volt.
- Spannungs regler für hintergrundbeleuchtung, PWM geregelt.
- 2x 4 taster neben display.
- 5 tasten unterhalb display (in kreuz).
- größe 60mm x 90mm.

Sobald ich preise und lieferzeiten weiss melde ich das auch hier, und
auf meine homepage (www.mdejong.de)

Die software library und alle iinformationen für die displays wird auch
auf meine homepage zum download verfügbar sein.

Grüße Mark,

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnt Ihr in eure Programm Dateien auch reinschreiben für welchen
Display damit man bescheidweis wenn man mal die Lib tauschen will.

Ich bin mal gespannt auf die Preise :-/

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurze Frage zur Spannungsversorgung:

Weiter oben im Thread steht, dass der 1V8 Eingang auch 2V9 verträgt. Im
Datenblatt zum HD-Controller hab ich gesehen, dass der alles im Bereich
von 2.2 bis 3.3V verträgt.
Ich vermute mal dass das für alle Controller die hier im Einsatz sind
gilt.
Ist der Level-Shifter + Spannungswandler überhaupt nötig, oder spielt
da das LCD-Panel auch eine Rolle?

Mario

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark:
"Sobald ich preise und lieferzeiten weiss melde ich das auch hier,
und
auf meine homepage (www.mdejong.de)"


Nicht, daß das so hängenbleibt wie andere unvollendete Projekte von
Dir.
Auf die LCD-Platine zum 640er warten wir bis heute trotz vollmundiger
Ankündigung...

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andi,

Wie du auf meine homepage sehen kannst ist der platine jetzt
lieferbar.

Ich mache das alles alleine und neben meine eigentliche arbeit deshalb
dauert es manchmal länger.

Die hardware entwicklung ansich ist nicht das Problem.
Die testfase kostest viel zeit (Platinen machen lassen, bauteile
besorgen, aufbauen, testen....)
, ich biete keine ungetestet hardware an.
Auch das schreiben von der doku nimmt viel zeit in anspruch.

Ich möchte das meine Produkte für jeder zu benutzten sind, also keine
"bastellösungen".

Ich bin auch jederzeit bereit fragen zu beantworten (per email oder
telefonisch).

z.b. Das suchen welche controller auf die displays benutzt werden hat
viele stunden gekostet, ich habe viele stunden verbracht im internet zu
suchen und datenblätter zu lesen.

Dies soll keine entschuldigung sein, sondern nur eine erklärung :-)
Ich beschwere mich auch nicht, es ist eine hobby für mich.

@Mario,
Du hast recht das steht im datenblatt vom controller, aber wir haben
kein datenblatt vom LCD-Panel, deshalb gehen wir auf nummer sicher und
benutzten nur 2,9 volt.
Der level-shifter is "notwendig" um die signale zum controller
richtig zu haben (die flankensteilheit, etc.)

Grüße Mark,

Autor: Holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo André Kronfeldt und den rest der Leser.

Ich hab mal eine Frage an gerichtet André, du sagtest oben das du dein
Display mit einem Levelshifter 74HC573 ansteuern wills, meine frage
dazu hat dies Funktioniert und wie hast du diesen angeschlossen.

Vielen Dank Holger

Autor: Fabian Thiele (ape)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es eigentlich möglich die Lib noch um eine Funktion zu erweitern um
Dreiecke zu füllen? Damit könnte man dann beliebige Polygone zeichnen da
sich ja jede Form in Dreiecke zerlgen lässt.

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Holger:

Ich hab dann doch lieber 10 Widerstände genommen. Der 74HC573 hat
entgegen seinem Dateblatt die Ausgänge auf 3,3V gelegt (angeblich
maximal VCC+0,5V). Wurde extra mit 2,4V versorgt. Ging aber nicht.
Ich hab das bislang aber nicht weiter verfolgt, werde mich aber mal bei
Gelegenheit dran machen.

Grüße,
AK

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andi,

ich muss mich Mark anschließen. Es ist das Forum für Hobbyasten und
Bastler, das ist weit weg vom Komerziellen. Da gibts andere Seiten,
beipielsweise www.display300.com.
Ich denke aber mal, dass Dir das sowieso klar ist und du Mark nur
motivieren wolltest damit die hier interessierten daran auch zu der
Platine kommen. ICh denke er tut in seinem Rahmen des möglichen das
beste ...

@Mark: Ich werde mich mal bzgl. LCD-Panels schlau machen. Ich denke die
werden sowieso über den internen Booster angesteuert, der wiederum die
Spannung über die interne Referenz erzeugt. Aber der "auf Nummer
sicher" Ansatz klingt überzeugend :)


Mario

Autor: Fabian Thiele (ape)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@André
ein normaler HC573 hat an seinen Eingängen ESD Schutz-Dioden, die dafür
Sorgen das Überspannungen an den Eingängen auf die Versorgungsspannung
abgeleitet werden. Wenn du nun an den Eingängen höhere Pegel hast als
die Versorgungsspannung des ICs, wird die Versorgung über die Eingänge
hoch gezogen. Da der AVR recht kräftige IOs hat stellt sich dann eine
entsprechend höhere Spannung ein. Deshalb steht ja auch in den Absolute
Maximum Ratings als Maximum Input Voltage VCC...
Ein Level Shifter wie z.B. ein HC4050 ist dafür ausgelegt an den
Eingängen höhere Pegel als die Versorgungsspannung zu haben.

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fabian

Danke. Das kommt davon, wenn man nur die Hälfte liest. Einen HC4050 hab
ich wohl noch hier. Ich teste das mal.

Grüße,
André

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fabian

bei mir im Datenblatt ist für den HC4050 aber auch
VI DC Input Voltage -0.5 to VCC + 0.5 V (Maximum)
VI Input Voltage 0 to VCC V (RECOMMENDED)
angegeben und in der CIRCUIT SCHEMATIC auch zwei
Schutzdioden (allerdings gestrichelt).

Autor: Fabian Thiele (ape)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also bei TI steht im Datenblatt:

"The ’HC4049 and ’HC4050 are fabricated with high-speed
silicon gate technology. They have a modified input
protection structure that enables these parts to be used as
logic level translators which convert high-level logic to a lowlevel
logic while operating off the low-level logic supply. For
example, 15-V input pulse levels can be down-converted to
0-V to 5-V logic levels."

Ausprobiert hab ich die aber auhc noch nie.

Autor: Mark De jong (mark_de_jong)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Wegen die pegelwandler hier ist mein schaltplan für die Platine.
Ich benutzte denn 74LVC1T45 und 74LVC2T45 von TI.

Grüße Mark,

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Dies soll keine entschuldigung sein, sondern nur eine erklärung :-)
Ich beschwere mich auch nicht, es ist eine hobby für mich."


Wenn das ein Hobby ist, wieso dann eine Umsatzsteueridentnummer?

Im Übrigen ist der Bestellvorgang nicht gesetzeskonform. Wenn man
nämlich die AGB bei der Bestellung anklickt (Der Link hinter dem
Haken), dann führt der ins Leere. Die AGB werden also nicht Bestandteil
des Kaufvertrages.

Wenn man die AGB links anklickt, so kommen hier nicht gesetzeskonforme
AGB zu Tage. Portkosten sind nämlich ab einem Bestellwert von 40 Euro
in jedem Fall vom Verkäufer zu erstatten.

Auf jeden Fall solltest Du an der Webseite arbeiten, sonst kann das
schnell teuer werden.

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark:

> Wenn mann die init anschaut schreib er auch zu register 0x0D und
0x0E
> beim init. Die gibt beim HD66766 nicht, aber beim HD66773 schon.
Ich find die beim HD66773 aber auch nicht.
R0Bh (Seite 35) ...
R0Fh (Seite 37) ...

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andre,

Aber auf seite 27 :-)

@Andi,
Mann braucht einen Steuernummer zum verkaufen, Auch wenn es ein hobby
ist.

Auch ein gewerbe kann ein hobby sein, ich meine nur das ich nicht davon
lebe (kann).

Grüße Mark,

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark:
Japanische Reihenfolge ist schon seltsam.
BTW: Natürlich hab ich nach 'R0Ch' gesucht, ging aber nicht.

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian

Habe gerade gesehen, dass du die Ansteuerung für das
L2F50-Display fertig gestellt hast.
Hast du vielleicht ein Datenblatt des Controllers gefunden,
weil du so detailiert die Befehle beschrieben hast.
Besonders interessant finde ich, dass es eine 18-Bit-Farbdarstellung
gibt. Bedeutet das, dass dieses Display das Beste von allen Dreien
ist? Oder welches Display würdest du empfehlen? (in Bezug auf
Bildqualität, Helligkeit, Ansteuerbarkeit)


MartinK

Autor: Mark De jong (mark_de_jong)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Das ist ein Controller von EPSON, wie der S1D15G10 (132x132pixel).

Jetzt brauchen wir nur noch das richtige datenblatt.

Grüße Mark,

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich hab mal eine Frage zu der generellen SPI-Kommuniktation. Laut
Datenblatt (S55) wird CS* auf low gezogen um das LCD zu selektieren.
Dann werden die Daten (Kommando, Parameter) übertragen. Danach CS*
wieder auf high.

Laut dem Code von ChristianK ist CS* die ganze Zeit low und wird nur
nach der Übertragung kurz auf high gezogen.

Woran liegt das?

Grüße,
AK

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Mann braucht einen Steuernummer zum verkaufen, Auch wenn es ein hobby
ist."

Das ist falsch. Entscheidend ist die Gewinnerzielungsabsicht.


"Auch ein gewerbe kann ein hobby sein, ich meine nur das ich nicht
davon
lebe (kann)."

Das ist etwas anderes, wenn die Umsätze zu gering dafür sind.
Entscheidend ist, wie gesagt, daß Du damit Gewinne erzielen möchtest.

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jochen & Andi

abgesehen davon, daß einem in diesem Land bestimmt sofort
'Gewinnerzielungsabsicht' vom Finanzamt unterstellt wird sobald man
versucht einen alten Kaugummi loszuwerden, halte ich die Diskussion
über den Shop in diesem Thread für unangebracht.

Nicht bös sein, aber ich denke es geht hier um das S65-LCD und um die
Ansteuerung (von mir aus auch um Bauteilbeschaffung).

Grüße,
André

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andre:
Da hast Du völlig recht, also ENDE.

Grüße Mark,

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andre,

>Laut dem Code von ChristianK ist CS* die ganze Zeit low und wird nur
>nach der Übertragung kurz auf high gezogen.

Das stimmt so nicht. Schau dir den Code nochmal genau an. Im übrigen
unterscheidet sich die CS Steuerung bei jedem Display Typ. Es gibt aber
auch bestimmt andere CS Steuerungen die zum Ziel führen, als die aus
meinem Code.

Allen Display's gemein ist (hoffentlich, noch nicht getestet) dass sie
den SPI Bus ignorieren wenn CS=high ist.

Grüsse
  Christian

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian,

Hast Du das richtige datenblatt vom EPSON controller?
Wenn Ja, kannst Du das Posten?

Grüße Mark,

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian:

Es geht hier um das LPH.

Nach einem port_init() ist CS* low.
Im lcd_init_c() wird erst ein Reset (CS*=1) durchgeführt
und dann das LCD selektiert (CS*=0). Soweit okay. Dann
kommen die Daten per comtype() oder comdat(). Nach dem
Senden wird CS* auf high gezogen. Da komm ich noch mit.
Aber warum geht es danach wieder auf low?
Vor allem, weil Du es am Ende von lcd_init_c() wieder setzt.
Das Setzen ist okay (LCD nicht selektiert), aber der zusätzlich
Impuls scheint mir unnötig, oder?
Kann aber auch sein, daß Du versuchst das LCD default-mäßig zu
selektieren um mehrere Befehle hintereinander zu senden.
Dann ist natürlich klar, daß du am Ende von put_char() und lcd_init_c()
das LCD wieder abwählen mußt. Trickser ;-)

Ich denke aber auch, daß der BUs ignoriert wird, wenn CS*=1 ist.

Gruß,
AK

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark:
Nein, ich habe kein passendes Datenblatt zum Epson Controller. Wäre
schön wenn du das irgendwie besorgen könntest ;-)

Die Commands sind aber ähnlich zu anderen Controllern (z.B. der
132x132) und die die benutzt werden passen auch soweit. Andere, die bei
mir noch in der #define Liste stehen, aber nicht benutzt werden, z.B.
DISPINV, scheinen nicht zu funktionieren.

Ich habe aber noch nicht alles (viel) ausprobiert. Hoffe das die SLEEP
Commands funktionieren.

Grüße
  Christian

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andre,

schau mal in das HITACHI Datenblatt. Da steht etwas zu den CS Flanken.
Z.B. muss es zu Begin und Abschluss der commands gewisse Flanken
geben.

Grüße
  Christian

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian

Hast die 18-Bit-Farbenzahl beim L2F50-Display schon ausprobiert?
(bezieht sich auf deinen Kommentar im C-File)

MartinK

Autor: Thomas Voss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

auch ich hab mal eine Frage in wie fern ist es möglich zwei Displays
über einen Mikrocontroller zu steuern, muss man dazu im Code viel
verändern?

Mfg Thomas

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas

Wenn ich mich nicht täusch, sollte es reichen wenn man getrennte CS*
Signale auf jedes Display legt.
Der Code ist dann fast derselbe (bis auf die Anstuerung des CS*).

Autor: Kay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK

könntest du mir bitte dein Beispiel in Bascom mal zukommen lassen ?


mfg Kay

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK:
> Oder welches Display würdest du empfehlen? (in Bezug auf
> Bildqualität, Helligkeit, Ansteuerbarkeit)

Weiter oben im Thread findet man:

>Mir ist aber aufgefallen, dass das LS020-Display wesentlich
>heller ist.... Außerdem scheint das LS020-Display gleichmäßiger
>beleuchtet zu sein.

Aha, aber trotzdem würde ich die LPHxx Display (die grünen/blauen)
aufkaufen wenn ihr sie los werden wollt....

Grüße
  Christian

P.S:
Die LPH's lassen sich nämlich laut Datenblatt (noch nicht probiert)
erheblich flexiber programmieren. Es gibt praktisch alle
Addressierungsarten, so dass z.B. ein Port der glcd in allen Rotationen
einfach möglich sein wird. D.h. das LPH Display eignet sich dann sehr
gut zum Quereinbau (längs). Bei den anderen beiden Displays ist dazu
mehr Portierungsaufwand erforderlich.

Die Bildqualität ist bei allen recht ähnlich, die Qualität der
Beleuchtung wohl beim LPH am schlechtesten, L2FS und LS020 sind
ähnlich. Meiner Meinung nach macht das L2FS Bildmässig overall den
besten Eindruck, auch was die mechanische Qualität angeht - ist aber
derzeit von der Programmierung her am wenigsten flexibel.

Beim LPH kann man sich sogar noch ein Interface-Signal (RS) sparen.

Also zusammengefasst derzeit meine private Rangliste:
a) LPH
b) LS020
c) L2FS

Autor: The Daz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian,
reagiert deine step-up 10V Quelle empfindlich auf die groesse der
Induktivitaet ? Ich habe eigentlich KEINE Ahnung von dem analogen
Gebimsel und habe hier noch ne 1mH Festinduktivitaet rumliegen und
hoffe, man kann das mit einer Anpassung des PWM Signals ausgleichen.
Ich gehe mal davon aus, dass der Transistor- und Dioden-Typ eher
nebensaechlich sind, oder ? (dachte an BC546 + 1N4148).

  Daz

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@The Daz

Ich würde lieber bei einer Schottky-Diode bleiben.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe im eBay ein bischen herumgesucht und bin auf das SX1 gestoßen.
Ich weiß, dass dass hier nicht so richtig passt.
Aber ich vermute, dass dieses Display (ist etwas größer) ähnlich in der
Ansteuerung ist wie dieses hier.
Hat dazu schon jemand eine Idee.

Hier die "Daten" vom Display:
Display (genutzte Fläche) 35 x 44 mm (176 x 220 Pixel, 65.536 Farben)

Das Teil gibts für ca. 15.- bei eBay.

Zu meiner Level-shifter Frage von vorhin. Nachdem ich mich versucht
habe so gut wie möglich schlau zu machen, bin ich auf folgende
Versuchsanordnung gestoßen: Das Display anhängen und langsam die
Spannung schrittweise von 2.9V bis 2.2V verringern. Ändert sich nichts
(Kontrast etc.), so sollte dasselbe auch für höhere Spannungen gelten,
d.h. das Display kann innerhalb der Controller-Spezifikation betrieben
werden.

Von der Theorie her (Flüssigkristalle etc.) sollte das auch für das
Panel nicht kritisch sein. Desweiteren scheint der Controller seine
LCD-Treiberspannungen von der (internen) Referenz zu erzeugen wie es
das Blockschaltbild darstellt.

Welche internen Spannungen hat das S65?


Mario

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mario,

Das SX1-display habe ich ach schon gesehen, aber das hat glaube ich
einen 40 polige connector.

Grüße Mark,

Autor: Fabian Thiele (ape)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soweit ich das auf den eBay Bildern erkennen konnte scheint der
Connector 18 Pins zu haben... Das spricht jedenfalls für ne paralelle
Schnittstelle. Macht auch Sinn, bei 176*220 Pixeln und 16 Bit ist ein
Bild stolze 77440 Byte groß. Bei einer SPI Schnittstelle mit 8MBit
würde man für ein Bild im Idealfall 74ms brauchen bzw. 13,5fps
schaffen. In der Praxis wäre das ganze noch wesentlich langsamer, da
die Daten ja erstmal generiert werden müssen.
Überhaupt sind AVRs für diese Auflösungen meiner Meinung nach nicht
mehr wirklich geeignet, und die hohe Auflösung ist denke ich auch
einfach überflüssig. Zu JPEG- oder Video-Anzeige sind AVRs glaube ich
selbst bei noch so effizienter Programmierung nicht mehr in der Lage :)
und sonst wüsste ich nich wofür man die vielen Pixel noch gebrauchen
kann.
Für die größeren ARMs könnte so ein Display schon eher handhabbar sein,
aber die Anwendung fehlt immernoch. Vielleicht ein selbstbau Video
Player mit TI DaVinci :D

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fabian Thiele

Also mein Anwendungsfall wird ganz klar GinaSisters oder Tetris ;-)

Mittlerweile kann mein LPH Hardware-Scrolling und am Wochenende werde
ich die guten alten 'Sprites' oder 'Blobs' realisieren. Meine Frau
fragt mich zwar nach dem Sinn, aber ich hoffe ich werde nicht entmutigt
;-)
Der Code von ChristianK ist mittlerweile auch nach Assembler übersetzt
und ein wenig optimiert. Die Datenaufbereitung fällt fast nicht mehr
ins Gewicht.
Ich hoffe nur, daß bald die bestellten ATmega128 kommen, der ATmega8515
wird langsam eng (SRAM-mäßig). Das momentan angebundene Dataflash ist zu
langsam.

Grüße,
AK

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bascom-Ansteuerung für ein LS020...-Display

http://www.xmail.net/martin-k/display.htm

Benötigt wird eine neuere Bascom-Demo-Version,
die auf 4 kB Codegröße limitiert ist.

MartinK

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@The Daz:

Der Supply Boost ist nicht sehr empfindlich. Kannst also ruhig mit der
1mH Spule starten. Empfehlung ist erstmal mit einer kleinen pulse-weite
anzufangen und dann langsam hochdrehen...

Weiterhin empfehle ich für's Lab/Bastellkeller einen
Überspannungsschutz vorzusehen. Wenn z.B. mal das Display - bei
anliegendem PWM Signal - nicht angeschlossen ist, wird sich der
Spulenstrom einen anderen Weg suchen. Der ist sonst vmtl. tödlich für
irgend ein anderes Bauteil. Ich habe zwei 5.6V Z-Dioden in Reihe
geschaltet.

Hier die Initialisierung des Timers 2 für die PWM Erzeugung (16MHz ->
62.5kHz PWM Frequenz). (Achtung, die die den PB7 for LCD_RS genutzt
haben - wie ich in meinen Code-Beispielen - müssen den verlegen z.B.
auf PB5) Puls-Weite ist OCR2/256. PWM Ausgangssignal ist OC2 (PB7)

    // backlight PWM generation
    // use timer 2 in fast PWM mode for this
    PORTB &= ~_BV(PB7);  // clear port before enable
    DDRB |= _BV(PB7);  // will be used for OC2, must be output
    TCCR2 = _BV(WGM21) | _BV(WGM20) | _BV(COM21) | _BV(CS20);
    TCNT2=0x00;
    OCR2=120;

Zur Hardware:
Schottky Diode ist wegen besseren Wirkungsgrad (normale geht aber
auch).

Beim bipolaren Schalttransistor den Basis-Vorwiderstand nicht vergessen
;-)

Grüße
  Christian

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

Bewertung
0 lesenswert
nicht lesenswert
Hy Leute,

Hab das PDF wiedermal auf den neusten Stand
der Dinge gebracht.

Falls Fehler auftauchen oder sonst was ist
wie immer bitte melden.


Gruß Lightning

Autor: The Daz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian,
merci fuer die Info. Hab mir ein LS020 bestellt und werde demnaechst
anfangen.

@Lightning,
daaaanke fuer den update. Endlich kenne ich die genauen Einbaumasse und
es sieht so aus, als ob das Display in ein 1HE 19" Gehaeuse passen
wuerde.

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lightning:
Denn Update beim PWM backlight hast du noch nicht mit aufgenommen. Wie
erzeugst du das PDF? Von Hand?

Grüße
  Christian

Autor: Jens D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Such mal im netz nach PDF Drucker ;)
evtl auch nach Ghostprint oder script hiess das tool meine ich

Gruss

Autor: Kay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi Lightning,

wieso gibts das pdf nur in englisch. ich kann zwar englisch, aber in
Deutsch würde ich es besser verstehen. gibt es dafür einen besonderen
grund ?

mfg Kay

Autor: Lightning (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hy Leute,

@ Christian Kranz
Hab das PWM Update jetzt eingefügt. Zuerst schreibe ich das Zeug
im Word und dann nehm ich den Acrobat 7.0 her und mache aus dem Word
Dokument ein PDF.

@ Kay
Bin seit 2 Tagen drann das PDF nach Deutsch zu Übersetzen
jedoch hab ich eher wenig zeit daher dauert das n bisschen.
Wenn ich die Deutsche version fertig habe, poste ich sie
natürlich auch hier im Forum.

Danke nochmal an alle.


Gruß Lightning

Autor: Kay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lightning
vielen Dank

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leicht OT, aber dennoch passend:

Verwendet man anstelle von Microsoft Word den OpenOffice Writer, dann
hat man den PDF-Export gleich mit dabei.
OpenOffice 2.0 (gibt es seit einigen Tagen) ist kostenlos und
weitestgehend kompatibel zu den aktuellen Microsoft-Formaten.
Von politischen oder religiösen Überzeugungen abgesehen kann ich wenig
Gründe erkennen, die gegen eine Migration sprächen.

Autor: Lightning (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rufus T. Firefly

Da ich mich mit Word schon sehr gut
auskenne, geht es schneller wenn ich
das ganze ein bisschen umständlicher
mache, als wenn ich mich jetzt in
OpenOffice einlerne.

Gruß Lightning

Autor: The Daz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mir die Schaltung jetzt mal mit nem ATMega16 @ 16MHz und nem
LS020 Display auf nem Steckbrett zusammengestrickt. Fuer die LED
Voltage steht bei diesem uC ja nur 62,5kHz (anstatt 200kHz wie im PDF
beschrieben) zur Verfuegung. Auf die benoetigten 10,4V komme ich bei
mir erst mit ca. 5mH Spuleninduktivitaet und einem
Puls/Pause-Verhaeltnis von 52%/48% (OCR2 = 134).

Das kleine Demo-Programm (Hello World) scheint auch nicht zu
funktionieren, der Hintergrund wird zwar eingefaerbt, aber es ist kein
Text zu sehen. Aus diesem Grund habe ich erstmal nur versucht kleine
Rechtecke aufs Display zu zaubern. Dabei hat sich herausgestellt, dass
die X und Y Koordinaten vertauscht zu sein scheinen. Egal welchen
Rotations-Wert ich einsetze, ich muss X und Y vertauschen. Sehr
seltsam, werde das nochmal genauer untersuchen.

Ansonsten bin ich bisher ganz zufrieden mit dem Ergebnis. Vielen Dank
an Christian und Mark. Good job !

   Daz

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daz:
Backlight:
Ich benutze 820µH mit 62.5kHz mit n-channel FET und schottky diode.
-> funktioniert tadellos, Helligkeit lässt sich über pulse weite sehr
gut einstellen, auch extrem hell (und vmtl. weit ausserhalb der LED
Spec.) Kann sein dass das an deinen nicht optimalen Bauteilen (bipolar
Tr. 1n4148 liegt)

Hello World:
Schiebe mal die komplette ASCII Tabelle in den Flash Speicher. Ich
vermute du hast ein SRAM Problem... (Als Beispiel kannst du dir den
Code vom EPSON Display ansehen oder GCC tutorial oder du weisst das
sowieso)

Gruesse
  Christian

Autor: The Daz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian,
dachte ich zuerst auch. Habe deshalb auf FET und Shottky-Diode
umgestellt und damit ueberhaupt erst ein braucgbares Ergebnis erziehlt.
Die angegebenen Werte beziehen sich daher auf die FET/Shottky
Kombination. Ich will nicht ausschliessen, dass der Aufbau auf dem
Steckbrett seinen Teil dazu beitraegt.

Die ASCII-Tabelle ins Flash zu schieben werde ich heute abend mal
ausprobieren. Danke fuer den Tip.

  Daz

Autor: The Daz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, den Font ins Flash zu verlegen hat das Problem mit der Anzeige des
'Hello World' Strings gefixt. Bleibt nur noch die Sache mit den
vertauschten Koordinaten. Aber da scheint es, als ob das
Beispiel-Programm mehr weis als das PDF Dokument. Bei 0° Rotation
vertauscht die put_char Routine nämlich auch die Koordinaten und schon
stimmts wieder.

  Daz

Autor: Kay Pohl (kay)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK

hi,

hab das display jetzt am laufen. hat sogar auf anhieb geklappt. wenn
ich den AVR und das display mit Strom versorge, dann dauert es ca. 20
Sekunden bis das Display voll beschrieben ist. Ist das normal ? liegt
es daran, das es keine SPI Ansteuerung ist ?

mfg Kay

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kay

Bei mir dauert der Bildaufbau maximal 3 Sekunden bei einer
Taktfrequenz von 8 MHz.
Natürlich wäre eine Ansteuerung über SPI wesentlich!!! schneller.
(Bascom unterstützt SPI-Befehle)
Selbst ohne SPI läßt sich mein Code noch optimieren. Ich werde mal
sehen, was ich da noch ändern kann.
Der Vorteil einer Ansteuerung ohne SPI ist, dass sich jeder
Portpin eignet.

MartinK

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK

ok, habe meinen Fehler gefunden. war ja ein neuer mega8. Da ich mit den
megas noch nicht so viel gemacht habe, habe ich vergessen, die FuseBits
so umzustellen, das er auf externem Quarz läuft. jetzt dauert der
Bildaufbau ca 1-2 Sekunden mit 16 Mhz.

ja bascom kann SPI. man könnte ja auch SoftSPI benutzen, dann würde man
auch jeden Port benutzen können. Müsste nur in Bascom die Ports für den
SoftSPI Port definieren.

mfg Kay

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK

ich habe mal ein wenig am programm rumgespielt, aber ich blicke nicht
durch. ich möchte einfach nur den ganzen Screen Blau malen. Könntest Du
mir bitte sagen, wie ich das anstelle ?
( Ich habe versucht, aus dem PDF schlau zu werde, nur dieses Englisch
.... :-) )

mfg Kay

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kay

Auf meiner Seite http://www.xmail.net/martin-k/display.htm
habe ich das Beispielprogramm aktualisiert.
Ich benutze jetzt die Shiftout Funktion, die Ansteuerung läuft
etwas schneller.

Wenn du nur Blau malen willst, so gehst du folgendermaßen vor:
(Code aus LS202-RGB.bas)

'Blau malen
A = &HEF90
Gosub 16
A = &H0500       ' 00 => Bild wird von oben nach unten gemalt
Gosub 16
A = &H0800       'x1
Gosub 16
A = &H092B       'x2
Gosub 16
A = &H0A00       'y1
Gosub 16
A = &H0B7F       'y2
Gosub 16

EF90, 0500, 08..  09..  0A.. 0B..  sind die Grafikbefehle zum Malen
eines Punktes oder Ausschnittes. Du musst nur noch die Koordinaten
einsetzen. In meinem Beispielprogramm beginnt der Ausschnitt bei
x1,y1 = 0,0 und endet bei x2,y2 = 2B,7F (Hexadezimal) = 43,127
Diese Werte kannst du beliebig variieren, jedoch darf x nicht größer
als 131 und y nicht größer als 175 sein (0 wird mitgerechnet)
Als nächstes folgen dann die Farbwerte für die einzelnen Bildpunkte
im 16-Bit-Format RRRRRGGGGGGBBBBB
Wenn du also nur Blau malen willst, so hat jeder Punkt den Binärwert
0000000000011111 = 31
Für einen kompletten Bildschirm musst du 132*176 = 23232 mal den Wert
31 senden.

Alternativ gibt es die folgende Befehlssequenz:
EF90, 0500, 06x1, 07y1
Hier definierst du nur den Startpunkt, der Endpunkt liegt automatisch
bei 131,175

MartinK

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK

also ich habe das neue Beispiel von Dir ausprobiert. Das Bild baut sich
wesentlich schneller auf.

Wenn ich das ganzen Screen Blau malen will, dann mache ich es, wie du
geschrieben hast:



'Blau malen
 A = &HEF90
Gosub 16
A = &H0500                                                  ' 00 =>
Bild wird von oben nach unten gemalt
Gosub 16
A = &H0800                                                  'Start 00
Gosub 16
A = &H0983                                                  'Ende 131
Gosub 16
A = &H0A00                                                  'Start 00
Gosub 16
A = &H0BAE                                                  'Ende 174
Gosub 16

Das Display zeigt dann auf der ganzen Breite das Blaue, nur zeichnet es
nur 1/4 von oben nach unten. ist an meinem code was falsch ?

mfg Kay

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kay

Das letzte Kommando müßte korrekt A = &H0BAF (175) lauten, sonst hast
du eine Leerzeile.
Dein Problem mit dem 1/4 Bildschirm entsteht bestimmt durch eine
falsche Schleife. Versuch mal folgende Schleife:

Portc.0 = 0   ' RS auf low setzen für Bilddaten
F = 31   'binär 0000000000011111 für Blau
For R = 1 To 23232
A = F
Gosub 16
Next R
Portc.0 = 1   'RS high

MartinK

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK

also mit der schleife gehts auch nicht. da kommt die Fehlermeldung :

Value doesn´t fit into byte ---> bei For R = 1 to 23232

wenn ich keinen farbverlauf will, dann kann ich doch normalerweise nur
die schleife nehmen, die du im obern Post geschrieben hast oder ?

mfg Kay

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK

habs hinbekommen. musste R als Word definieren. jetzt habe ich einen
wunderschönen blauen screen. sehr gut. denkst du es wäre auch machbar,
Bilder auf dem Display mit Bascom darzustellen ?

mfg Kay

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK

hast du vor, das display mit Bascom per SPI anzusteuern ? ich denke mir
die geschwindigkeit des SoftSPI kann zwar nicht mit dem des Hardware SPI
des AVR mithalten, sollte aber dennoch schnell genug sein, um einen
kompletten Screen in sehr kurzer Zeit zu beschreiben. Und das gute an
SoftSPI ist ja, das man jeden beliebigen PIN als SPI Interface
konfigurieren kann.

mfg Kay

Autor: -- Outstanding --- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kay:

Schreibst Du unter 2 Nicks, oder wieso kenn ich Deinen letzten Post
schon: http://www.mikrocontroller.net/forum/read-4-243641...
???

Zu Deiner letzten Frage:
> denkst du es wäre auch machbar, Bilder auf dem Display mit
> Bascom darzustellen ?
Was sollte dagegen sprechen? Das ist fast schon wie: Denkst Du ich kann
mit dem Messer ein Brot schneiden? Meinst Du Luft ist zum atmen da? War
die Frage ernst gemeint, oder rhetorisch?
Meinst Du, ob es für DICH machbar wäre? Verlier den Mut nicht, aber
ließ bitte ein wenig im Datenblatt.

Grüße,
-- Outstanding ---

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kay

SoftSPI dürfte das gleiche wie Shiftout sein.
Mit Bascom werde ich mich sehr wahrscheinlich nicht weiter
beschäftigen, weil ich momentan einen M32C (Renesas) programmiere, und
da ist nur C angesagt (obwohl ich Basic eigentlich ganz gut finde)
Bilder auf dem Display darzustellen ist kein Problem, schau dir mal in
diesem Thread die Artikel von Fabian Thiele (ape) an.
Bascom unterstützt ja auch die serielle Schnittstelle.

MartinK

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK

ich werde mal sehen, ob ich das display mittels C ans laufen bekomme.
danke für Deine Hilfe

@all

habe das Display an einen Mega16 mit 16Mhz folgendermaßen
angeschlossen:

LCD --------- AVR

DAT           MOSI PB5
CLK           SCK  PB7
CS            SS   PB4
RESET         OC1B PD4
RS            OC2  PD7

da ich mit C noch nicht viel gemacht habe, würde ich gerne wissen, ob
es reicht in der lcd.h die Definierung der Ports zu ändern und in der
makefile den mega16 zu konfigurieren ?


mfg Kay

Autor: Simone Durchholz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Kay:
Nein das reicht nicht. Die Sourcen gehen davon aus, dass alle LCD
Signale an den gleichen Port angeschlossen sind. Also warum nutzt du
nicht auch Port B für RESET und RS? Ansonsten musst du die
Port-Zugriffe umschreiben

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Simone:

habe jetzt den PortB für das Display genommen.

DAT = PB5
CLK = PB7
CS  = PB4
RESET = PB3
RS  = PB2

hab dann in der lcd.h die Pins so konfiguriert und den mega16 im
makefile eingetragen. nur leider geht garnichts. ich denke, ich werde
den mega16 mal tauschen.

mfg Kay

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@The Daz:

könntest Du mir bitte deinen Mega16 Code für das display zukommen
lassen ?

mfg Kay

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

Bewertung
0 lesenswert
nicht lesenswert
@Kay,
klar doch (siehe Anhang).

  Daz

Autor: The Daz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kay,
Obacht ! Beim Mega16 liegt der PWM (OC2) Ausgang auf PortD Pin 7.

  Daz

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@The Daz,

danke für den code. hab meinen mega16 nun genauso beschaltet, wie in
der lcd.h beschrieben ( bis auf PWM ). Hab alle Leitungen überprüft.
Aber auf dem Display erscheint nichts. Das Display muss aber in Ordnung
sein, denn wenn ich das Display mit Bascom programmiere, funktioniert es
( bei Bascom benutz ich nur keinen SPI Port ).


mfg Kay

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@all

wieso wird in der lcd.h MISO definiert ? ich dachte, man benötigt nur
MOSI für die Dat Leitung.

mfg Kay

Autor: The Daz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MISO ist nur der Vollstaendigkeit halber da, wird aber tatsaechlich
nicht gebraucht (Zumindest nicht in diesem Fall). Ich hab selbst hin
und wieder Probleme, weil die LCD-Initialisierung nicht hinhaut. Vor
allem, nachdem ich den assembler code aus Christians Beispiel noch ein
bischen auf performance getrimmt hatte. Das scheint eine enorm
Empfindliche Sache zu sein. Vielleicht reichen ein paar zusaetzliche
NOPs um das Display bei dir ans Laufen zu kriegen. Nimm vielleicht mal
Christians Original-Code, verschiebe den Font ins Flash (PROGMEM) und
probiers nochmal.

Autor: Kay Pohl (kay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@The Daz

danke für die hilfe. aber ich glaube, ich muss mich jetzt erstmal
intensiv mit C beschäftigen, weil ich davon nämlich so gut wie
garnichts verstehe. Hab zwar im Tutorial was zu Progmem gefunden, weiß
aber immer noch nicht, wie ich den Font ins Flash schieben soll. Sollte
es dann doch irgendwann klappen, melde ich mich.

mfg Kay

Autor: The Daz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, wenn ich den SPI double speed mode waehrend der LCD Initialisierung
abschalte und hinterher wieder ein, klappt die Sache wunderbar. Der
Testaufbau auf nem Steckbrett scheint nicht das Gelbe vom Ei zu sein.

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe nun endlich auch mein Display (LS020) bekommen. Nachdem ich
aber mehr bei den PIC zuhause bin, habe ich Christians *.asm Code
versucht zu portieren.
Leider hakt es an irgend einer Stelle und ich bin an der Fehlersuche.
Dabei bin ich auf ein paar offene Fragen gestoßen. Zum einen erlaubt es
der PIC die Clock-Polarität einzustellen (Idle = Low/High), d.h.
Invertierung. Zum anderen muss ich angeben, wann die Daten an SDO
angelegt werden (Fallende/Steigende Flanke). Desweiteren habe ich
nirgendwo gefunden, ob MSB first oder LSB-first gesendet werden muss
(vielleicht bin ich auch blind :)).
Beides konnte ich aus dem Code und ermangels an AVR-Kenntnissen nicht
herausfinden.
Auch Martins BASCOM-code hält sich zurück. Sein Shiftout sieht so aus:

Shiftout portx.x, porty.y, A, A

Dabei sollte lt. Dokumentation gerade der vierte Parameter festlegen
wie gesendet werden sollte, der Dritte die Daten, also ??

Ich habe meinen PIC-code (Auszug aus einem größeren Projekt) als
Attachment angehängt. Kann mir jemand von Euch helfen?

Gruß
Mario

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mario,

das SPI musst du beim AVR auch entsprechend konfigurieren -> Datenblatt
könnte dir helfen.

Aber am besten schaust du dir die Screen-Shots auf der Reengineering
Seite an. Da kannst du folgendes sehen:
a) MSB first
b) Daten anlegen mit der fallenden Clock Flanke (übernahme im Display
mit der steigenden)

Achte auf die CS Ansteuerung. Die ist kriegsentscheidend.

Ist ganz schön blöd vor so einem leeren Display zu sitzen....

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Superuser,

danke für die Antwort, damit sind schopn mal einige meiner Fragen
geklärt. Das langwierige Durchstöbern der AVR Datenblätter wollte ich
mir sparen, das Wissen sollte wohl da sein.
Ich habe mich auch an dem Screenshot vom Reengineering orientiert,
demach ist die clock-polarity auch festgelegt, nur leider wusste ich
nicht ob da eine Invertierung zwischengeschalten ist, bzw. was welcher
Leitung entspricht ... (RS/RESET/CS)

Der Sarkasmuss am Ende motiviert mich leider nicht, aber stimmt,
Fehlersuche ist so ziemlich das nervigste ....

Aber eigentlich bin ich auf der Suche nach jemandem der mal schnell
einen Blick auf den Source-wirft. Vier Augen sehen mehr als zwei, etc.
Und vielleicht gibts auch noch einen anderen, der ausser am AVR auch an
einem PIC-code interessiert ist.

Mario

Autor: HscH (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wie steure ich dieses S65 Siemens Display an?
Geht dies über I2C Bus oder SPI Bus?

Woher bekomme ich ein Beispiel wie man so was ansteuert?

Brauche ich da noch andere Spannungen?

Autor: Jens D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HscH
fang am besten mal oben an zu lesen, all deine fragen wurden schon zich
mal beantwortet

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
um zu sehen wie man sowas ansteuert kann man sich die alte glcd library
für das Nokia 6100 Display anschauen die war noch in C. Die hatte ich
auch mal nach Codevision portiert, aber dann doch mit Winavr angefangen
wegen der besseren neuen Library.

Ich hab auch mal 3 Displays bestellt und werd mich wohl dran machen die
glcd Library in Codevision bzw. ANSI-C kompatiblen C-Code umzuwandeln.
Sowas in Assembler programmieren macht kaum noch Sinn, da die Compiler
heutzutage doch recht Codeeffizient sind.
Die Ansteuerung selbst gibts sowieso keine Geschwindigkeitsprobleme,
wenn man icht grade 3D-Ballerspiele programmieren will.
Problematischer ist eher der hohe Speicherbedarf für die Fonts.

Allein zum Testen reicht normalerweise glcdinit da sollte das Display
schon die Farbe wechseln, wenn es erfolgreich war, so zumindest beim
Nokia Display

Autor: André Kronfeldt (freakazoid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

> Sowas in Assembler programmieren macht kaum noch Sinn,
> da die Compiler heutzutage doch recht Codeeffizient sind.
Täusch Dich mal nicht. Da der GCC ein Allrounder ist und nicht für den
AVR optimiert, produziert er manchmal Code, der ein erblassen läßt.
Ein PORTD|=0xFF generiert bei O3 z.B.:

in R24, PORTD
ldi R24, 0xff
out PORTD, 0xff

Da haut's einen schon um. Zudem ist gerade sowas wie Scrolling und
schneller Bildwechsel sehr empfindlich (Ruckler). Wieso sollte man die
GLCD wieder nach C übersetzten? Ich denke die läßt sich problemlos
gegen ein C-Programm linken?

Grüße,
André

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gab 3 wichtige Gründe warum ich die GCLD in Assembler portiert habe:

1.) ich wollte eine echte Link Library bauen. Das wäre auch in C
gegangen, aber wenn man es eh einmal macht dann möchte man ja auch
gleich mehrere Vorteile haben, und so kommen wir zu den 2 anderen
Vorteilen

2.) die ASM GLCD benötigt für mehr Funktionalität ca. nur 50% an Flash
! Es zeigte sich also sehr wohl das der Mensch bei weitem besser
optimiert als der Compiler. Und gerade beim WinAVR GCC sind einige
Stellen die er bei weitem besser hätte optimieren können. Ich habe in
den letzten 20 Jahren einiges an Compiler benutzt und muß sagen das der
GCC bei weitem einer derjenigen ist die nicht so gut optimieren. Diese
Aussage soll den WinAVR GCC nicht diskretitieren, denn als eine freie
Alternative entwickelt von Enthustiasten ist der GCC eine sehr stabile
Entwicklungsumgebung.

Die letzendlichen Resultate sind:
4500 Bytes an Code für die alte C Version
2800 Bytes an Code für die neue ASM Version, wobei diese aber auch mehr
Funktionalität besitzt.

4500 Byte an Code in der C Version, egal welche Funktionen man
benutzt.
600 Bytes an Code in ASM Version wenn man nur die nötigsten Funktionen
braucht.

3.) die Performance der ASM Version ist ebenfalls bis zu 5 mal besser.
Dies hat 3 Gründe: a) die ASM Version geht mit den Registern und
Paramatern wesentlich optimaler um. In C sind defakto alle Parameter
immer 16 Bit breit auch wenn man nur uint8_t benutzt. Die Asm Version
benutzt nun die unbenutzten Register die durch die Aufrufkonventionen
vorgeschrieben sind als lokale Variablen. b) die ASM Version ist so
konstruiert das die meisten Aufrufenden Funktionen wissen welche
Register in den aufgerufenen Funktionen benutzt werden. Ich habe die
Register also so verteilt das zb. sehr wichtige Funktionen immer die
gleichen Register benutzen und die übergeodneten Funktionen diese
Register nicht benutzen. Ergo: es werden wesentlich weniger PUSH/POPs
benötigt. c) viele grafik Funktionen wie Linien/Kreise/Ellipsen und
Fonts können in Assembler ganz bestimmte Möglichkeiten der CPU benutzen
die so in C garnicht verfügbar sind. So zum Beispiel rechnet die
Linienfunktion mit 24Bit Integer statt mit 32 Bit Integern in C.

Es macht also aus Sicht der Performance und Resourcenverbrauch sehr
wohl einen gewaltigen Unterschied aus.

Es gibt aber auch Nachteile:
1.) C ist portabler, und gerade die GCLD wurde nun schon auf den PIC,
MSP etc. portiert.
2.) Assembler ist wesentlich schlechter wartbar
3.) Erweiterungen von neueren Displays sind in der C Version viel
schneller umzusetzen.
4.) die Trennung von HAL und TopLevel Schnittstellen ist in C
einfacher.

Gruß Hagen

Autor: André Kronfeldt (freakazoid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen

genau ähnliche Argumente sehe ich auch. Der AVR-GCC wird von mir nur
für das eigentliche Programm benutzt. Die Libraries (MMC, LCD, ...)
sind meistens in ASM und werden gegen den C-Hauptteil gelinkt. So kann
man den Vorteil beider Welten nutzen.

- Höhere Geschwindigkeit.
- Minimaler Code (gerade für kleine AVRs).
- Dank des Linkers nur Code, der auch benötigt wird.
- Schnelle Entwicklung und einfache Wartbarkeit des C-Hauptteils.

Ebenso wie Hagen versuche ich PUSH und POP zu vermeiden, indem die
Register optimal ausgenutzt werden. Sind ja genug da ;-)

Einer der großen Nachteile ist allerdings die schlechte Portierbarkeit.
Da ich mich aber nur bei den AVRs wohlfühle (und selbst die mit ihrem
IO-Zugriff etwas konfus sind - Historie?) trifft mich das nicht so. Ein
anderes LCD? Einfach eine andere (sowas ist relativ schnell portiert)
LCD-Lib linken und gut ist - vorrausgesetzt die Funktionen sind
gleich.

Zudem frag ich mich, warum der AVR-GCC mit O0 fehlerhaften Code
(bezogen auf IO-Funktionen) erzeugt. Aber das steht wohl auf einem
anderen Blatt. Er ist jedenfalls für Entwickler der beste
Freeware-Compiler (wohl auch der Einzigste, oder?). Wenn man erstmal
gechecked hat, daß O2(?) mindestens Pflicht ist, geht der Rest relativ
locker von der Hand.

Grüße,
André

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Ein anderes LCD? Einfach eine andere (sowas ist relativ schnell
>> portiert) LCD-Lib linken und gut ist - vorrausgesetzt die
>> Funktionen sind gleich.

Tja, wenn man die Libs komplett austauschen kann dann ist das noch ok.
Aber im Falle der GLCD entsteht ein spezielles Problem. Die sagen wir
mal HighLevel Funktionen wie Fonts, Linien, Kreise etc.pp. graifen
optimiert auf spezielle HAL-Funktionen zu. Leider stelen diese eben
auch eine Funktionalität extra zugeschnitten auf den Display Controller
zu Verfügung und sind in der ASM Version eben nicht strikt von den
HighLevel Funktionen getrennt. Das wieder auseinanderzuklabüsern ist
doch recht schwierig.

Ansonsten ist der WinAVR GCC eine recht passable Alternative zu purem
ASM oder eben teueren Compilern.

Gruß Hagen

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, ich hab auch eigentlich einen richtigen Compiler gemeint. :-)
Was da rauskommt ist oft nicht mehr viel zu optimieren.
Der Assembler Code ist halt immer schwierig zu portieren.

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen

> C ist portabler, und gerade die GCLD wurde nun schon auf den PIC,
> MSP etc. portiert.

Hast du für den MSP430 einen Link?

MartinK

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK:

Nein habe ich nicht, ich weis halt durch EMails das einer es portiert
hat und wegen par Problemen bei mir nachfragte.

Gruß Hagen

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe gesehen, dass mein Hilferuf bzgl. des PIC-codes zwar noch
keinen Hinweis auf einen Fehler gebracht hat, aber vielleicht hat ja
einer der den Code heruntergeladen hat das Display zum laufen gebracht
damit. Würde heissen, meins ist kaputt, bzw. eine Leitung ist nicht
durchkontaktiert (Habs zwar schon geprüft, aber ...).
Also Erfolgsmeldungen auch hier posten - schließt für mich eine
Fehlerquelle aus - Danke!

@Martin:
Warum schaut Dein BACOM Shiftout so aus?

Shiftout portx.x, porty.y, A, A

Vierter Parameter sollte aus {0,1,2,3} sein. A sind aber die Daten?

Gruß
Mario

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Nachtrag zu meinem vorangegangenen Post. Ich habe nun die Sourcen nach
einer Woche nochmals durchgesehen und entsprechend dem Kommentar von
SuperUser angepasst.
Die Leitungen (CS, RESET, RS) sollten nun auch soweit alle richtig
sein- vorausgesetzt ich kann die *.asm Befehler für den AVR richtig
deuten. Auch das SPI-Timing sollte passen. Ein paar andere dumme Fehler
sollten nun auch draussen sein. Leider funzts nachwievor nicht.

Anbei die neuen Sourcen. Vielleicht funktionieren sie bei jemandem
anderen, dann wirds eng für mein Display - also vielleicht doch
"tot"?

Gruß
Mario

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Super, endlich hat es geklappt! CKE-war falsch gesetzt.
Zusätzlich hab ich noch ein sauberes RESET nach Martin's BASCOM-source
eingebaut.
Manchmal hilft es einfach zu schreiben das es hakt, dann bekommt man
die Idee wo's noch haken könnte.
So jetzt überflute ich das Forum nicht mehr mit meinen Problemchen.

Gruß
Mario

Autor: Mikro Avr (mikroavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Poste doch mal dein Programm, dann haben alle was davon

Autor: Hsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, verkauft jemand so ein Grafikdisplay von SIEMENS S65?

Autor: André Kronfeldt (freakazoid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ein gewisser Herr 'eBay' hat sowas von viele. Der gibt bestimmt
welche ab:

http://search.ebay.de/search/search.dll?sofocus=bs...

Autor: HELLEN PAGANI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DEAR SALES,

I WOULD LIKE TO REQUEST YOUR BEST PRICE AND LEAD TIME TO ORDER

4100PCS
LS020 COLOR DISPLAY
SIEMENS

PLEASE ANSWER ME BACK AS SOON AS YOU CAN.

THANK YOU SO MCUH

HELLEN PAGANI
hellen@netcondigy.com.br
55 11 4996-7205
5511 4996-7203
www.netcondigy.com.br

Autor: Hsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist mir schon klar, dass ich bei Ebay diese Displays erwerben kann.
Aber dort erhalte ich nur Displays ohne Anschlusskabel oder Stecker die
zur Platine führen. Ich weiss halt nicht wie ich an dem flachen Kabel
was anlöten kann. Deshalb frage ich hier in diesem Forum ob jemand ein
Display verkauft, mit dem ich gleich loslegen kann.

Autor: DerMax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An den Displays sind Kontakte im 1,27mm Raster ist ja wohl kein Problem
da nen paar Drähte dran zu löten...

Autor: Jens D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@DerMax
Doch...
es soll ja Leute geben, die SMD per Dachrinnenloeter versuchen zu
loeten ;)

Gruss

Autor: Mark de Jong (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@DerMax,

Der abstand ist 1,5mm, nicht 1,27mm

@Hsch:
Eine Platine(oder Fertiges Modul) wird ab übernächste verfügbar sein.

Grüße Mark,

Autor: Hsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Mark,

ja was soll denn dieses Modul kosten? Ist es ein Modul ohne
Coontroller?

Autor: Jens D. (jens) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich habe heute ein LS20xx Display bekommen, wie sieht das mit der
Spannungsversorgung aus?
Sind 3,3V zuviel oder noch gerade so in ordnung?

Autor: ThJoedi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Freaks,

Ich habe mal ein bischen recharchiert und da ein Datenblatt von einem
TFT Display gefunden was bestimmt den gleichen controller
(LR38825+LH169C) drauf hat wie das LS020. Für Cellular Phones werden
diese oder aber der LR38826 eingesetzt, die zu dem LS020 passen würden.
Nu aber zum Eigentlichen...
Versucht mal folgende shut down sequence:

0xEF00,0x1B04,0xFEFE,0xFEFE,0x7E04,0xE304,0xE404,0xE201,0x8000,0xE001,0x 
7F01

5µS (MIN)

0xE000,0x7F01

5µs (MIN)

0x0101

Nach der Sequence werden bei meinem Display alle Pixel weiß, und nach
Abschalten der Spannungsversorgung bleibt es unverändert (Kein
Verschwimmen der Pixel oder so zu erkennn). Scheint also zu
funktionieren. Ihr könnt ja mal die Pegel etc. checken ob die
Abschaltung auch elektrisch am Interface ok ist. Ich hab dazu jetzt
keine Nerven.
Ich habe nen Kumpel der bei Sharp arbeitet, vielleicht bekomm ich noch
mehr raus.
Viel Spaß beim probieren :D

Gruß
Joedi

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jens,

ich hab mein LS020 gemiiensamt mit dem PIC an eine Lithium-Knopfzelle
gelegt - direkt ohne Pegelwandler etc.. Lt. Multimeter (ist nicht sehr
genau) ist die Spannung 3,3V. Funktioniert prima.

Es gibt da aber ohnehin zwei Spannungen. Der Logik-Pegel wird auch in
Christians Schaltung von 1V8 auf 2V9 gelegt. Die meisten Controller
Vertragen aber bis 3.3/3.6V. Den 2V9 sollte man nicht über 3.3V anheben
(lt. Kommentar in Martin's BASOM Source). Warum, wieso??

@ThJoedi,

danke. Werde mal ausprobieren ob es funktioniert. Kannst Du die
Datenblätter zu den Controllern ins Forum stellen?

Gruß
Mario

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sollte natuürlich "gemeinsam" heissen und nicht ... ja was auch immer.

Autor: KennyOswald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Kennt einer einen Seriösen eBay oder normalen Shop?
Suche schon seit zwei Wochen nach einer guten Quelle. Habe aber nur
abzocker gefunden.

Brauche 8x Stück für mein Mischpult.
www.ucapps.de

mfg
KennyOswald

Autor: Rainer Stamm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MartinK

>>EF90 0000 nach der Initialisierungssequenz auf dem Bildschirm
>>nichts erscheint. (in deinem Asm-File steht dazu: I think not
>>necessary...)

Genau dieser Fehler hat mich auch ein paar Stunden Fehlersuche
gebracht!!!

Mein Display ist ein LS020B8UD05 (braun) und hat ohne EF90 0000 am ende
der Init auch nichts angezeigt.

#####################################
Könnt man im PDF mal drauf hinweisen.
#####################################

Nebenbei nutze ich das Display an einem MSP430 bei 3V, noch per
Soft-SPI.

Vielen Dank allen die es mir ermöglicht haben dieses Display zu nutzen,
besonders Christian!

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rainer
Verstehe ich nicht. Meinst du den original Code? Da steht zwar der
Kommentar, aber die Sequenz wird trotzdem zum Display gesendet. Wie
kommt es zu diesem Fehler?

Autor: Rainer Stamm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Superuser

ich habe meinen eigenen Code für den MSP430 geschrieben und zwar nach
dieser Seite:

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

Dort fehlt hinter INIT3 das "EF90 0000", ebenso in dem PDF das ich
hier mal runtergeladen habe.

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ThJoedi

Die shut down sequence funktioniert bei mir.
Allerdings liegt danach der Stromverbrauch noch bei etwa 50 uA.

MartinK

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

Bewertung
0 lesenswert
nicht lesenswert
Hy Leute,

Hab das PDF Upgedatet also es ist jetzt wieder auf dem
neusten Stand. Auch das mit dem "EF90 0000" am Ende
der INIT3 wurde korrigiert.

Mfg. Lightning

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kann mal einer die Dicke des Displays ausmessen? (inkl.
Kunststoff-Teil).
Die Gesamtmaße habe ich aus dem Bild auf Christians Seite
rausgemessen:

Über alles:        39 * 56mm
Aktives LCD-Feld:  31 * 42mm

Vielen Dank, Stefan

Autor: Lightning (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan Kleinwort

Die genauen Maße stehen ja im PDF.
Die Dicke ist 3,60 mm

Mfg. Lightning

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lightning:

Vielen Dank!

Ich hatte natürlich nur im alten pdf geschaut ... oh mann ...

Gruß, Stefan

Autor: ThJoedi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MartinK:
Mit der Power down sequence wird ja bestimmt nicht der ganze controller
abgeschaltet sondern nur die LCD glass driver.

@All:
Der Controller des LS020 ist ein Sharp LR38826. Die power off sequence
ist vom LR38825+LH169C. Es könnte sein dass einige register miteinander
komatibel sind. Ich bleibe dran.....

Autor: Smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mal angefangen mit der Initialisierung mit dem AT91SAM7 aus dem Oszi


Ist das korrekt, daß RS während der ganzen Initialisierung high ist?
Welcher SPI-Mode ist der beste 0,1,2 oder 3?
Verändert sich das Display während/nach der Initialisierung wie auch
das Nokia Display, so daß man sieht, ob man erfolgreich war?
Liefert das Display auch igendwelche Daten zurück?

Autor: Smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
irgendwie fehlt was.
wollt schreiben auf dem Oszi siehts schonmal ganz gut aus aber Display
tut nichts

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach der Initialisierung zeigt es beim ersten mal normalerweise bunte
Zufallsmuster. Am besten du machst noch einen clear-screen mit einer
nicht weissen Farbe, dann siehst sicher du ob es geht.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Smartie,

hatte zunächst auch Probleme, da ich den Code auf den PIC portiert habe
(Code siehe weiter oben im Thread). Schau am besten in Martin's
BASCOM-Basic Source. Der ist weitgehendst selbsterklärend.

Aber Achtung beim Nachbau. Das CS-Signal ist entscheidendend, also
vorerst nicht "optimieren" !! Das hat mich einiges an Zeit gekostet
:(

Gruß
Mario

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das CS macht der ARM ja alleine. Das Nokia Display ändert die Farbe nach
der Initialisierung da kann man gleich sehen daß man erfolgreich war,
deswegen meine Frage, ob das Siemens das auch macht.
Wann genau zeigt das Display die Zufallsmuster, erst nach allen drei
Init-Sequenzen oder schon vorher?

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die controller gibt es doch datasheets zum runter laden, oder? Kann
man die restlichen Funktionen nicht aus den datasheets entnehmen?
(z.B. power down)

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann gib doch mal an wo

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab nur für das grüne gesucht:
http://www.tianma.com/spec_sheets/HD66773.pdf

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von Sharp hab ich was gefunden steht aber nicht viel drin:
http://sharp-world.com/products/device/ic/pdf/lr38826_e.pdf

Epson hab ich nur einen TFT Controller gefunden das ist der S1D19105
http://www.epson-electronics.de/upload/PresidioInd...
der S1D15G10 hat nur 132x132 und ist kein TFT
http://www.epson-electronics.de/upload/PresidioInd...
aber komplettes Service Manual vom S6 hab ich gefunden:
http://www.siediyer.com/Doc/x65SRD.pdf
Da steht drin daß die verschiedenen Displays Hardwarecodiert sind also
irgendwo wohl Brücken gesetzt und die Software demensprechend das
Display nimmt. Dann dürften die aber auch im Handy nicht untereinander
tauschbar sein.

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Natürlich kann man nicht mehr verlangen, dass man sich den ganzen Thread
hier durchliest... Aber neues habt ihr bis jetzt leider noch nicht
ausgegraben :-(

Die verschiedenen Display's werden an Pull's in den Display's
unterschieden. Die SW findet so heraus welches Display angeschlossen
ist und benutzt dann den entsprechenden Treiber. D.h. ein Phone
unterstützt jedes der Displays.

Autor: Smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja wird halt auch schnell unübersichtlichg so ein Thread.
Hab mal in das Datenblatt von dem Hitachi-Chip reingeschaut,
das scheint eine komplett andere Kommunikation zu sein. Kommt immer
erst ein Startbyte, wo auch das RS mit drinsteckt und dann Daten und
alles 8-Bit-Weise.

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Treiber Code kannst du ja runterladen und dir anschauen. In diesem
Fall reiner C-Code

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal eine frage, Kay Pohl hat geschrieben das der Bildaufbau 2-3
sekunden dauert bei 16 mhz - ist das normal oder ist das nur bei basic
so? :P

Das ist ja für eine echte Anwendung unzumutbar, was für "framerates"
haben die anderen denn so hin bekommen? Ich hab mir überlegt das
Display in verbindung mit einem ARM für flüssige Animationen zu
verwenden, der ARM wäre ja schnell genug - könnte das gehen oder soll
ich das lieber sein lassen?

Ansonten ist mir noch das display von http://www.shop.display3000.com/
aufgefallen, ich hab zwar erst gedacht das wäre ein nokia 6100 display
aber das scheint ja 16 bit anstatt 12 bit farbe zu haben... hmm

Autor: Mikro Avr (mikroavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lupin: bei display3000 sind doch Nokia 6100 Displays - Mit Epson
Chipset.

Autor: peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich will ein scrollbares menü machen deshalb interessiert mich die
benötigten Bit/s vom µC auch.


16 bit  132 rows  176 cols = 371712 bit pro frame.
Wenn der maximale SPI Takt des Displays 13 MHz ist ist die max.
Bildfrequenz 13e6/371712= 34,97 Frames/s

Mit nem schnellen Controller kein Problem mit nem ATMEGA wirds
schwierig da SPI max 10 MHz

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit einem 16MHz AVR (8 MHz SPI) kann man den kompletten Bildschirm in
ca. 50ms schreiben

Autor: peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"mit einem 16MHz AVR (8 MHz SPI) kann man den kompletten Bildschirm in
ca. 50ms schreiben"

schon aber du hast ja auch noch andere Aktivitäten des µC. Ausser du
hast schon die ganzen Bildinhalte in einem externen Speicher und
schaufelst sie nur noch ins Display.

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Controller mit mindestens 371712/8=46464 Byte RAM gibts von Atmel nur
als ARM. Ob das Sinn macht, den spärlichen RAM-Speicher so zu
mißbrauchen, da kann man sich drüber streiten.
Scroll-Menüs kann man auch textbasiert realisieren, hab ich bei dem
Nokia-Display auch gemacht mit nem 16-MHz-AVR. Oder alles aus einzelnen
Bitmaps zusammenbauen, die man im Flash ablegen kann. Außerdem kann man
sich bei der Grafikausgabe auf einen Frame beschränken, der kleiner ist
als das eigentliche Display.

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am besten ist es wenn man sich auf klassische Konsolen-methoden wie
Hintergründe, die aus einzelnen Blöcken zusammen gesetzt sind,
beschränkt und nur in Ausnahmefällen sprites zeichnet, das könnte man
dann doch alles direkt ins display zeichnen und die grafiken vom flash
laden, oder? Wenn man es dann dynamischer braucht muss man sich halt
Speicher reservieren.

Nun frag ich mich aber wie die 2-3 sekunden für den Bildaufbau zustande
gekommen sind.

Autor: peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, habe mein Display bekommen und es hat sofort funktioniert.
Also vielen Dank an Christian für die tolle Arbeit die du geleistet
hast!!!

Autor: Rainer Stamm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat jemand funktionierenden Quelltext für Hardware-SPI, MSP430 und
LS020?
Bis jetzt klappt es bei mir immer noch nur per Software-SPI, habe alles
ausprobiert und stehe auf dem Schlauch...

Autor: Mark Hämmerling (haemi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Salve,

zuerst mal herzlichen Dank an Christian. Wirklich tolle Arbeit! Hab
gestern von Cellow mein Display bekommen (LPH88, steht direkt drauf).
Ich glaube aber, es hat durch den Versand was wegbekommen. Eine Ecke
ist angeknickt (war auch nur in Luftpolsterfolie verpackt, ohne
Knickschutz). Dummerweise hab ich das erst gemerkt, nachdem ich es
angelötet und getestet hatte.
Folgender Defekt tritt auf: In der unteren Displayhälfte ist jede
Zweite Zeile weiß, egal welche Daten ich dort in den GRAM schreibe. Mir
fiel auch auf, daß die erst noch etwas bunt sind, und erst dann richtig
weiß werden (nach 1-2 Sekunden Betrieb). Ich vermute ganz stark, daß
durch den Knick die Treiberleitungen beschädigt wurden. Die
init-Routinen hab ich von Christian übernommen, und auch schon
verändert. Die defekten Zeilen sehen so aus wie wenn ein Teil des
Displays nicht gescannt wird (kann man in der Init ja festlegen).
Falls jemand schonmal etwas ähnliches erlebt hat, wäre eine kurze
Nachricht sehr nett. Ansonsten muß ich sehen, ob Cellow das Display mit
Lötzinn dran zurücknimmt. ;(

Danke schonmal für Tips,
Mark

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

Bewertung
0 lesenswert
nicht lesenswert
Hi,
im Anhang ein kleines Tool zum erstellen von 16 bit Farb defines aus
der Windows Farbpalette. Man kann nur die Grundfarben oder die erste
custom color zur Liste hinzufügen.

Autor: Smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema Hardware-SPI hatte ich auch mein Problem.
Die Lösung:
ich hatte nur gesendet und nicht gewartet bzw. abgefragt ob fertig.
Hab dann nach jedem Word 15µs gewartet und dann hats auf Anhieb
funktioniert.

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

Bewertung
0 lesenswert
nicht lesenswert
Hab eine Platine gemacht, auf die genau das Sharp-Display passt, zwei
Spannungsregler für 2,9V und LED-Spannung damit das Display mit 12-15V
betrieben werden kann und Spannungsteiler für 5V Ansteuerung und
Schalttransistor zum Ein- und Ausschalten der LEDs. Die Bauteile sitzen
alle direkt in den Aussparungen des Displays, so daß die Rückseite plan
ist.
Anbei die Eagle-Dateien, Fotos (leider nur mit Webcam) und meine Demo
auf dem Arm7 von Atmel AT91SAM7S256

Autor: peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich steuere das Display mit dem R8C an. Ich habe folgendes festgestellt:
Wenn ich einen Bereich mit 0xef90 0x0504 auswähle, dann muss ich nun
y1,y2,x1,x2 angeben und nicht x1,x2,y1,y2 wie im PDF steht. Ich gebe
auch die Pixeldaten von links oben an zeilenweise nach unten an, im PDF
ist es von links unten zeilenweise nach oben angegeben. Hat das auch
schon jemand bemerkt ?

Autor: DerMax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@smartie:
Hi, welchen Compiler verwendest du für den ARM?

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab jetzt noch ein bischen das Timing optimiert und festgestellt, daß
man bei der Initialisierung nach bestimmten Sequenzen dem Display ein
paar µs Zeit geben muß sonst klappts nicht.
Die Wartezeit nach SPI send hab ich jetzt bis auf 2 µs
runtergeschraubt.
Bin jetzt noch am überlegen, wie man die SPI noch optimieren könnte,
weil ja immer 2µs gewartet werden muß. Ginge eigentlich nur über einen
Software FIFO und ein Interrupt, der die SPI bedient, der müßte dann
aber auch mit 1-2µs laufen.

Hab noch schnell zwei kleine Routinen fillrect und rect geschrieben,
kann ich mal posten falls es jemanden interessiert, ist aber nichts
dolles.
Verwende die embedded Workbench von IAR, war bei dem Bundle von MSC mit
dabei für 149 Euro, ist aber auf 32KB Code beschränkt. Finde die zwar
lange nicht so gut wie Codevision für den AVR aber man kann mit
arbeiten.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Smartie:

schau mal im Datenblatt unter 29.6.3.4, Figure 29.7: die
SPI_Schnittstelle des SAM kann selbstständig Delays erzeugen.

Viele Grüße, Stefan

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich will ja grad keine delays. Ein Fillscreen hat fast 45 KBytes. Bei
2µs sind das bei 16 Bit SPI fast 100ms, die die CPU nur wartet.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ahhh ... ich hatte verstanden, dass das Display die 2us braucht, um
korrekt die Daten annehmen zu können.

Warum schreibst Du die Daten nicht in einen Out-Puffer und startest
dann den DMA des SPI? Die Daten werden dann völlig selbstständig
ausgegeben. Währenddessen kannst Du die nächsten Daten vorbereiten, in
einem anderen Datenblock.

Viele Grüße, Stefan

Autor: Smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
werd mir das mit dem DMA mal anschauen, bin halt noch ganz am Anfang mit
dem Arm.
Die 2µs braucht es nur bei der Initialisierung, beim Daten schreiben
nicht.

Hab auch grad nochwas rausgefunden:
nach
  lcd_wrcmd(0xEF90);
  lcd_wrcmd(0x0504);
  lcd_wrcmd(0x0800+y1);
  lcd_wrcmd(0x0A00+x1);
  lcd_wrcmd(0x0900+y2);
  lcd_wrcmd(0x0B00+x2);

funktioniert
  lcd_wrcmd(0x0504);
  lcd_wrcmd(0x0600+y1);
  lcd_wrcmd(0x0700+x1);

nicht mehr richtig, es wird durch den Frame von vorher begrenzt, läuft
also über.
d.h mit der ersten Befehlsfolge wird definitif ein Clipping-Fenster
gesetzt, was für alle weiteren Schreibbefehle gilt.

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Freunde des LS020 Displays...

Nachdem ich nun mehrere Display's in Betrieb genommen habe, musste ich
noch einmal die INIT-Sequence ändern. Sonst scheinen einige Displays
nicht stabil zu starten. Ich hatte erst Wackelkontakt vermutet bzw.
Display beim Löten beschädigt. Allerdings hat sich mal wieder die
Software als nicht perfekt erwiesen.

Ich habe die Web-Page und die glcd upgedated. For den letzten Command
(bedeutet vmtl. Display On) muss noch eine Wartezeit eingehalten
werden.

Tschüss und guten Rutsch
  Christian

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo täusch ich mich oder muss in LCD.asm in der
send window write start sequence: nicht r24 stehen?
Im orginal ist dort r30 angegeben.

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da hast du wohl recht...

Fällt hier aber nicht auf, da die Funktion nur einmal benutzt wird und
beim init das window schon richtig gesetzt wird.

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

Bewertung
0 lesenswert
nicht lesenswert
korrigiert

Autor: Rainer Stamm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das LS020 ist wirklich ganz schön zickig...
Im Prinzip läuft jetzt zwar alles bei mir, auch Hardware-SPI am MSP430,
aber wenn ich was ändere dann klappt meistens nichts mehr.
Software-SPI geht, Hardware-SPI mit 4Mhz geht auch, Hardware mit 2Mhz
aber NICHT.
Kann ja auch sein das ich irgendwo einen blöden Bug in meiner Software
habe, aber so komisch hat sich bis jetzt noch kein Display angestellt.
Trotzdem, wenn es klappt, dann ist es klasse. Nur eine Anwendung habe
ich immer noch nicht gefunden :)

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

als Anregung (und 300'te Post in diesem Thread) hier mal ein Beispiel
was ich gerade mit dem Display mache.

Im grunde handelt es sich um eine mobiles universelles Gerät, z.B. zur
Datenerfassung. Es unterstützt verschiedene Möglichkeiten zum
Datenaustausch. Als User-Interface gibt es einen Drehgeber mit
push-Taste, sowie zwei Tasten und/oder einem Ziffernblock (z.B. als
Folientastatur)

Visuell hat es das S65-Display sowie zwei LED's und einen kleinen
Lautsprecher oder pieco.

Das Gerät wird mit Akkus (LiIon/NiMh) betrieben, mit kompletter
Ladeelektronik (für software gesteuertes Laden). Das Gerät lässt sich
über eine Taste ein- und ausschalten. Im ausgeschalteten Zustand hat es
einen sehr geringen Stromverbrauch, über eine externe RTC (mit
Batteriespannung) läuft Zeit&Datum weiter.

Das aufwändigste ist (wie immer) die Software Entwicklung. Insbesondere
das User-Interface verschlingt sehr viel Zeit (und ich habe noch fast
alles vor mir....)

Daher ein Vorschlag: Ein grafisch-gesteuertes User-Interface wird wohl
jeder brauchen, der mit höher auflösenden grafischen Displays arbeitet.
Könnte man das nicht gemeinsam entwickelnt?

Grüße und frohes neues Jahr 2006
  Christian

Autor: Mark de Jong (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

Güte Idee, bin dafür ein standart library zu machen.

Ich schreibe gerade mein grafik libraries, für alle displays.
alles in standard C, also portierbar.

nur die low-level routinen sind naturlich abhängig von der hardware.

Meine HW targets sind:
-Keil C167
-Keil C51
-Keil ARM
-IAR MSP430

Hast Du einen vorschlag für ein algmeines interface?

Grüße Mark de Jong,

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht etwas in der Art:

Steuerung über Drehgeber (drehen hoch/runter bzw. links/rechts
Auswahl push-Taste)

- Eine Display-Text Zeile als Menu (obere oder untere)
  -> 1-4 Auswahlmöglichkeiten (li/re) (aktuelles invers dargestellt)
  -> push-Taste wählt das Menu
- Ein Frame des Displays wird als Menue-Fläche definiert
  -> Die Applikation muss diesen Frame immer neuzeichnen können, da
     Display Inhalt ja mangels Speicher nicht gesichert werden kann
- In diesem Frame kann man ein Menu-Window (single select) öffnen
  -> Anfangs rein textbasiertes Menu (hoch/runter)
  -> natürlich sind sub-menues möglich
- oder in diesem Frame kann man ein Eingabe-Window öffnen
  -> Zahleneingabe (mit Drehgeber support) Texteingabe?

.....

Autor: Rainer Stamm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Christian,

eigentlich arbeite ich an etwas ähnlichem. Zur Zeit befasse ich mich
hauptsächlich mit Grafik-Dateiformaten um Icons usw darstellen zu
können. Habe mir ein Tool geschrieben das aus einer BMP-Datei ein
Headerfile mit Farbtabelle für das LS020 und Bilddaten macht. Dadurch
habe ich zwar nur 256 Farben pro Icon, brauche aber auch nur 1 Byte pro
Pixel. Je nach Grafik bringt RLE-Codierung auch noch Platz. Dieses kann
man dann leicht in seinen Quelltext einbinden.
Für Zeichensätze benutze ich das XBM-Format da dieses eh C-Quelltext
ist und sich leicht mit Gimp oder Editor bearbeiten lässt.

Würde mich interessieren welche Wege ihr da geht.

Autor: Rainer Stamm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian, habe mit gerade nochmal dein Board angesehen. Ist eigentlich
genau das was ich auch brauche, nur mit einem MSP430 drauf :)
Als nächstes wollte ich mich mit der SD-Karte usw beschäftigen.
Eine Anwendung hätte ich auch dafür, nennt sich "Tagesgradzähler" und
muß über mehrere Monate eine Wassertemperatur aufzeichnen und einen
Tagesdurchschnittswert addieren. Ist eigentlich kein Problem, aber
irgendwie bisher immer am Gehäuse und der Stromversorgung gescheitert.
Mit einem AVR hatte ich es mal so gut wie fertig, aber dann wollte ich
doch lieber ein Grafikdisplay anstelle von Text, bin   auf MSP430
umgestiegen usw. Jetzt will ich Farbe und wahrscheinlich kommt dann
doch noch etwas anderes...

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mir auch ein S65 display bestellt, ich habe vorgehabt JPEGs zu
laden... das soll später mal teil eines kleinen Projektes werden. Die
JPEGs liegen dann auf einer MMC karte. Den code zur Dekomprimierung hab
ich schonmal auf einem GBA laufen gesehen, sollte also mit einen ARM
mikrocontroller nicht so schwer sein.

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

Bewertung
0 lesenswert
nicht lesenswert
Ich Experimentiere gerade am Ls020... mit dem TEST.C rum:

#include <inttypes.h>
#include "../glcd/glcd.h"
#include "../glcd/lfsr.h"
#include "../font/nums.h"
#include "../font/f9x14.h"
#include "../font/f15x22.h"
#include "../font/f8x11.h"
#include "../font/f8x8.h"

void demoScreen(void){
glcdSetOrientation(0);

      glcdSetColor(0, SCREEN_COLOR);
      glcdSetColor(1, BLACK);
      glcdSetColor(2, GOLD);
      glcdSetColor(3, RED);
    glcdClearScreen(BLACK);
     glcdSetFgColor(BLACK);
     glcdSetBkColor(WHITE);

    glcdFrame(0,0,130,175);
    glcdFillRect(110,110,130,130,SCREEN_COLOR);
glcdMoveTo(10,10);
 glcdSelectFont(f9x14, 0);           // font is stored in FLASH,
demontrate read callback
   glcdPrint("Siemens S65 LS020... \n geb 13.04.1966\n", 0);
   glcdSelectFont(f9x14, 0);
    glcdSetFgColor(BLUE);
  glcdMoveTo(11,100);
   glcdPrint("12345678901234567890",0);
   glcdSetBkColor(RED);
   glcdCircle( 80,80,10);
   glcdLine(90,80,100,100);

 }


   int main(void) {
#define cnt  1

#ifndef USE_AUTOINIT
    glcdDisplayInit();
#endif

    glcdClearScreen(1);
//    glcdDisplayOn();

    uint8_t o = 0;

    demoScreen();

    while (1) {




    }
}

Jetzt habe ich in der GLCD.inc

define ORIENTATION_DEFAULT         ORIENTATION_270 or _90

#ifndef SCREEN_WIDTH
#define SCREEN_WIDTH                175   // Siemens S65
#endif
#ifndef SCREEN_HEIGHT
#define SCREEN_HEIGHT               131   // to (0,0,131,175) to
support hardware scrolling and splitting of display
#endif
#ifndef SCREEN_LEFT
#define SCREEN_LEFT                 0
#endif
#ifndef SCREEN_TOP
#define SCREEN_TOP                  0
#endif
#ifndef SCREEN_RIGHT
#define SCREEN_RIGHT                (SCREEN_WIDTH -1)
#endif
#ifndef SCREEN_BOTTOM
#define SCREEN_BOTTOM               (SCREEN_HEIGHT -1)
#endif

eingestellt und bekomme siehe Anhang , alles Spiegelverkehrt angezeigt.
Habe ich was vergessen ?

Und bei glcdSetOrientation(0); kann ich 1, 2,3 etc einstellen und
passiert. Ich wollte die Anzeige Quer verwenden.

Und was ich nicht verstehe -> glcdPrint("12345678901234567890",0);
wenn anstatt eine 0 -> eine 1 reimache wird das Bild immer wieder
aufgebaut. Warum?

Da ich nur wenig mit C - Gemacht habe, habe mit Bascom gearbeitet.
Sind Tips immer gut. Ein gutes Projekt!!

Autor: ChristianK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

dann könnte dieser Link für dich interessant sein...
http://focus.ti.com/lit/an/slaa281/slaa281.pdf

Heute würde ich den Atmega 128 auch nicht mehr nehmen, sondern einen
ARM7. Mittlerweile ist aber zuviel Zeit in das Projekt geflossen um
noch den µC zu wechseln. Ausserdem reicht er.

Vorteile vom ARM sind:
- mehr Performance
- mehr Speicher
- weniger Stromverbrauch
- niedrigere Versorgungsspannung
- nahezu gleicher Preis

Den AVR habe ich genommen, weil es dafür soviel Software im Netz gibt.
Und das ist immer noch ein gutes Argument für den AVR.

Hallo Dirk,

die glcd unterstützt derzeit nur eine Orientierung. Das liegt daran,
dass der Display Controller lange nicht so flexible Addressierungs modi
des Display-RAM's unterstützt wie der Philips Controller für die die
GLCD ursprünglich geschrieben wurde. Zumindest sind mir bis heute nur
die dokumentierten Modi bekannt. Also wenn du Lust hast, kannst du ja
mal versuchen eine andere Orientierung einzubauen.

Wenn ich mich richtig erinnere, gibt der letzte Parameter von glcdPrint
an, ob die Daten aus dem Program-Flash oder dem RAM gelesen werden. Wenn
du aus dem Flash lesen möchtest, musst du die Daten auch dort speichern,
sonst ist nicht definiert was passiert...

Autor: Smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich finde das Board auch interessant,hab auch schon was ähnliches im
Eagle angefangen. Würde es aber auch mit einem Arm7 machen, das Ding
hat massig Speicher, RAM, USB und gibts auch mit Ethernet. Die
Programmierung ist auch nicht so kompliziert.
Da aber irgendwie jeder seinen Lieblingsprozessor hat, ist es
vielleicht besser, entweder verschiedene Boards entwickeln oder ein
Universal-Board mit aufsteckbaren Prozessoren machen, dann wäre jedem
geholfen.
Bei der Softwareentwicklung sollte alles modular sein, und möglichst
universell für alle CPUs verwendbar.

Mit nem ATMEGA und dem Nokia-Display hab ich mal nen
Tempomat/Bordcomputer gebaut, der nur über einen Drehencoder mit Button
programmiert und eingestellt wird. Da hatte ich zum Beispiel kurz
Drücken für on/off, länger Drücken Geschwindigkeit übernehmen, ganz
lang Drücken Menü.