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

Andy

Hallo Christian,

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

MartinK

Hi,

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

mfg Kay

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

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


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



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

Hy Leute,

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

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

Gruß Lightning

@Christian:

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

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

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

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

Kann man den DisplayRAM des LCDs auch wieder auslesen ?

Ansonsten super Arbeit.

Gruß Hagen

@ Tobias Schneider

Hallo,

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

Gruß Lightning

hi, nochmal zu bascom ...

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

mfg Kay

In Bascom nicht aber in Assembler.

Gruß Lightning

@Christian:

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

Schlechter Test ;) versuche mal 4 Linien mit den Koordinaten

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

Deren Steigung ist < 1 in Y Richtung

Dann noch

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

Deren Steigung ist ebenfalls < 1 in X Richtung

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

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

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

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

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



Gruß Hagen

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

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

alles klar danke

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

mfg Kay

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

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

Leider tat sich nichts

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

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

MartinK

@MartinK

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

Mfg. Lightning

@Lightning

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

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

MartinK

@Christian

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

MartinK

abo

Martin,

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

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

Grüße
  Christian

@ChristianK:

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

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

Grüße,
André

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

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

Hilfe! Farbenwahn!

Grüße,
André

@Christian

Hast du das grüne Display mal ausprobiert?


@André

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

MartinK

Hm.

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

AK

Zum Aufklären des Farbwirrwars:

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

Diese drei verhalten sich gleich.

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

Hy Leute,

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

Gruß Lightning

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

Gruß
Roland

hi,

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

mfg Kay

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

@Christian,

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

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

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

Michael

Hi,

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

Grüße,
AK

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

müsste auch passen

@André

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

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

MartinK

@MartinK

Ergebnisse kommen (wohl frühestens am WE).

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

Grüße,
AK

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

   Daz

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

hi ape,

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

mfg Kay

mhh ich meine natürlich Spannungsregler ...

@ape

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

MartinK

@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

@ape

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

MartinK

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

MartinK

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

mfg Kay

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

Gruß Hagen

@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

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

@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

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

@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?

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?

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

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

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?

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

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.

@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

@Mark:
Google:
http://www.inside-handy.de/handydatenbank/Siemens/...

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 !!!

@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

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

MartinK

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

@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

@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

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

Hallo Mark,

--> Soll noch etwas mit drauf?

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

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.

@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

Ich will ne Kaffeemaschine mit drauf haben!

@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

@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

@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

kurze frage:

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


mfg Kay

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

danke, schau ich mir gleich mal an

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é

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é

@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

@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

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

Gruss Lightning

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!!!!

@Mark de Jong

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

~ Lightning

@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

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

Gruß Lightning

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 :-/

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

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

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

@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

@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

@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é

@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).

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

@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) ...

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

@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

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

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

@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é

@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

@Christian

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

MartinK

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

@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*).

@MartinK

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


mfg Kay

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

@The Daz

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

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

@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

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

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

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

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

Gruss

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

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

@Lightning
vielen Dank

@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

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

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

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

@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

@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

@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

@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 ---

@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

@ 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

@Kay,
klar doch (siehe Anhang).

  Daz

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

  Daz

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.

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.

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

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

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

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?

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

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

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

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

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.

@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

@MartinK:

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

Gruß Hagen

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

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

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

Hi, verkauft jemand so ein Grafikdisplay von SIEMENS S65?

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

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.

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

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

Gruss

@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,

Hi Mark,

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

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,0x7F01

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

@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

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

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

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!

@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?

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

@ThJoedi

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

MartinK

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

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

@Stefan Kleinwort

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

Mfg. Lightning

@Lightning:

Vielen Dank!

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

Gruß, Stefan

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

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?

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

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.

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

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?

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)

dann gib doch mal an wo

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

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.

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.

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.

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

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

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

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

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

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.

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.

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

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

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.

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.

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

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 ?

@smartie:
Hi, welchen Compiler verwendest du für den ARM?

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.

@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

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.

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

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.

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.

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 :)

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,

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.

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

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.