Nicht mal das grosse G weiß was. ich würd Abstand nehmen, ich geh zwar
von einem Controller aus, aber welcher und welche Anschlüsse???

Nosnibor wrote:
> Man sieht vier Zeilentreiberchips (zu je 100 Zeilen), je zehn
> Spaltentreiberchips (für 80 Spalten) oben und unten, von denen jeweils
> einer nicht angeschlossen ist,

Klingt für mich etwas merkwürdig. Wiso sollten ICs verbaut, aber nicht
angeschlossen werden ?
Eventuell gehen alle Leitungen unter dem IC weg ? Dann hätte das Display
800x400.

> außerdem einen 74HC245 (bidirektionaler Bustreiber

Sowas habe ich noch nie auf einem LCD gesehen, vermutlich als Puffer für
die Datenleitungen um alle 10 Spaltentreiber damit zu versorgen.

> einen C324G (vierfach OP),

Spannungsaufbereitung für die LCD Spannungen

> einen SLA6050M (Gate Array),

Interessant. Mit rund 500 Gates auch nicht mal besonders klein. Ich
würde vermuten, dass damit das AC Drive Signal (M) erzeugt wird. Dazu
benötigt man einen Counter der alle n Zeilen eine Leitung toggelt. Das
könnte man genausogut mit Standard CMOS ICs machen.

> Das paßt nicht alles in 14 Pins, also wird wohl das Gate Array einen
> Teil der Signale selbst erzeugen.

Mindestens notwendige Signale bei einem Dual Scan Display:
- 8 Datenbits
- Shiftclock
- Latchpuls
- First Line Marker
- 5V
- GND
- VLCD

Passt also genau.

> Datumscodes auf den ICs von Mitte 1990, also hat da wohl jemand ein
> Ersatzteillager geräumt.

Scheint so. Ist bei Pollin aber normal. Schade dass das LCD
Kundenspezifisisch ist (ECM = Epson Custom Made). Ein Datenblatt ist
also komplett ausgeschlossen, außer der Kunde hat dies veröffentlicht.

Mittlerweile hat solch ein LCD auch seinen Weg zu mir gefunden.
Die Aufloesung scheint bei 720x400 oder 720x320 zu liegen.

So wie es aussieht, sind nur 12 der 14 (+2) Pins wirklich belegt, Pin 5
und 6 scheinen nicht verbunden zu sein.
Ausserdem gibt es 2 Pins fuer die Displayspannung, es bleiben also nur 8
Pins fuer Steuersignale und Daten uebrig.
Meine Vermutung: Das LCD bekommt die Daten als 4bit und zwar fuer die
obere und untere Haelfte nacheinander, was die ganze Sache einerseits
etwas unschoen macht, andererseits aber das LCD mit einem S1D13305
ansteuerbar machen sollte (wenn es wirklich so ist).

Das Gate Array dient vermutlich zur Erzeugung des M/AC Drive Signals.
Wie man auf dem Foto sieht, sind nahezu keine Pins verwendet, und alle 8
Ausgaenge
des HC245 gehen direkt zu irgendwelchen Pins der Zeilen und
Spaltentreibern. Nur am LP Signal haengt das Gate Array.

Ich denke ich habe die Anschlussbelegung, ich muss das ganze nur noch
ausprobieren. Anscheinend gibt es getrennte Takte fuer obere und untere
Haelfte.

Hallo Benedikt,

ihr bringt mich immer wieder zum stauenen (Hut ab!!). Ich hab das
Display erst heute per DHL bekommen und ihr habt schon die
Anschlussbelegung. Ihr nehmt einem aber auch jeden Spass :-)

Aber ist schon OK... Wozu ist denn der zusätzliche, 2-polige Anschluß?
Hintergrundbeleuchtung?

Der ist fuer VLCD (grob geschaetzt etwa -15 bis -20V) ist mit Pin 3 und
7 (auf meinem Bild ist oben Pin 1) von dem 14 poligen Stecker verbunden.
Er ist also unnoetig. Ich bin gerade am Kabel anloeten, spaetestens
morgen kann ich genaueres sagen wie man das LCD ansteuern muss.

PS: Ich habe das Display auch heute erst bekommen. Ach ja, falls jemand
die das Display zerlegt: Verdammt aufpassen, die Verbindungen an den
Treiber ICs zum eigentlichen Display sind verdammt empfindlich (auf dem
Foto die silbernen Bereiche ganz aussen an den Flexfolien wo die ICs
drauf sitzen).

Benedikt

OT:
Ich staune über die sehr gute Qualtät von Deinem Foto. Wie hast Du es
gemacht, einfach auf den Scanner gelegt?

Torsten

Ja, eingescannt. Ein Scanner ist eindeutig die billigste Variante einer
140MPixel Kamera.
Das volle Bild mit 1200x1200 dpi wollte ich hier nicht unbedingt
hochladen...

Gute Neuigkeiten: Das Display läuft !

Hier die ersten Fakten:
- 720x400 (Nosnibor hatte mit seiner Vermutung also recht), Dualscan
- Angesteuert werden obere und untere Hälfte ueber die selben 4bit
Datenleitungen. Zum Umschalten wird anscheinend der Takt umgeschaltet,
denn der Takt ist fuer die obere und untere Hälfte getrennt rausgefuert.
- Die Anschlussbelegung der Displayspannung ist mir noch nicht ganz
klar.

Ich habe die Software fuer ein 320x240 LCD etwas angepasst, daher
erscheint alles 4x. Wie man die Ansteuerung der beiden Hälften am besten
loest, muss ich mir noch einfallen lassen.

Offtopic: Kann mir mal jemand sagen, wie man ein LCD ohne Backlight
ordentlich fotografieren kann ? Das hier ist das beste von ueber 20
Fotos...

Vielleicht mit Auflicht ?

Ein HOCH, HOCH, HOCH auf unseren LCD-Guru !

zu Offtopic: Evtl mit Ministativ und ohne Blitz.

Grüsse Tobias

PS: Gratulation

zu Offtopic:
auch mit dem Scanner .....

Glückwunsch

Respekt Benedikt! Du bringst mich immer wieder zum Staunen...

Eigentlich ist es ganz einfach:
GND ist klar, das ist die Masseflaeche
+5V sucht man an einem Keramik C oder an einem Logik IC
VLCD findet man am V- Pin des LM324
Das war der ganz einfache Teil, jetzt wird es ein kleinwenig schwerer:
FRAME ist nur bei den Zeilentreibern zu finden.
Shiftclock nur bei den Spaltentreibern
LP bei beiden
Der Rest sind Datenleitungen.
In diesem Fall war es etwas schwieriger, da die Ansteuerung mit 2
Schiebetakten etwas unueblich ist. Da musste ich ein wenig ueberlegen
und ausprobieren.

Ich bin gerade am ueberlegen:
Wenn man das LCD umbaut und die oberen und unteren Treiber in Reihe
schaltet (dazu muss man auf dem LCD ein paar Leiterbahnen anpassen),
dann sollte man das LCD mit einem S1D13305 oder S1D13700 ansteuern
koennen.
Ohne Anpassung im LCD Modul braucht man eine zusaetzliche Logik die nach
180 Takten auf den Taktanschluss der unteren Treiber umschaltet.

Super Thread! Hab mir gleich mal 2 von den Dinger bestellt, nebst
"LCD-Modul HLM8070" (kann ich nur empfehlen, nicht größer als 2x16
Displays, trotzdem 4 Zeilen).

1  +5V
2  GND
3  Vlcd
4  LP
5
6
7  Vlcd
8  FLM
9  CLK O
10  CLK U
11  D0
12  D1
13  D2
14  D3

Falls mal jemand den genauen Zweck von Pin 3 und 7 rausfindet, waere das
schoen. Es scheint so, als wuerden beide Pins an eine Diode und einen
Transistor gehen, und von da aus an die eigentliche Schaltung.

Zum Fotografieren:
Einscannen liefert ein ganz gutes Bild, da der Scanner aber schraeg von
der Seite scannt ist der Blinkwinkel und somit der Kontrast schlecht.
Schraeg von unten Fotografieren ist auch nicht gut, da das Bild dann an
einer Stelle unscharf wird, da die Schaerfentiefe des Fotos begrenzt
ist.
Die einzige Moeglichkeit die ich kenne, ist eine grosflaechige,
gleichmaesige Beleuchtung. Aber wer hat schon eine blendfreie 1x1m
Beleuchtung ?

Wenn ich die SMD Codes richtig erkannt habe, dann müsste die Schaltung
in etwa so aussehen. Interessanterweise funktioniert das ganze, wenn ich
nur an Pin 7 die Spannung anlege.

Sebastian wrote:
> Wenn du die blende größer machst (also das Loch kleiner...) vergrößert
> sich der scharfe bereich.
> Auch wenn du mit dem Foto etwas weggehst und dafür ranzoomst gewinnst du
> einen größeren Schärfebereich.

Das Problem dabei ist nur: Dann brauche ich eine noch längere
Belichtungszeit. Ich bin jetzt schon bei 1/8...
Und durch den höheren Abstand verwackelt alles noch leichter.

Sebastian wrote:
> Geblitzt 1/8? Das erscheint mir mysteriös... Da brauchst du eigenltich
> schon fast ein Stativ.

Nein, ungeblitzt (mit Arbeitslampe). Mit Blitz erkennt man garnichts.

Ich glaube das beste ist immer noch der Scanner.

Back to Topic:
Ich habe mir ein paar Gedanken zur Ansteuerung gemacht:
- AVR wie bei meinem 640x480 LCD Controller:
 Prinzipiell möglich, allerdings ist dieser dann zu 100% mit der
Datenausgabe beschäftigt, da die Bandbreite zwischen AVR und LCD nur
halb so groß ist, da nur 4 statt 8bit genutzt werden.
- großer LCD Controller wie S1D13704/5/6, S1D13504/5/6:
 Funktioniert nicht, da diese nur Dualscan Displays mit 8bit ansteuern
können. Würde man das Display als 1440x200 ansteuern würde es
theoretisch funktionieren, aber diese Controller können maximal
1024x1024
- kleiner LCD Controller wie SED1330/SED1335/S1D13305:
 Diese können Dualscan Displays mit 4bit Ansteuern, allerdings nur
maximal 256 Zeilen. Daher muss das ganze mit einem Trick geschehen:
 Das Display wird als 1440x200 angesteuert, in der Software muss man
dies halt berücksichtigen, dass immer abechselnd eine Zeile obere Hälfte
und eine Zeile untere Hälfte kommen. Dafür ist dieser Controller leicht
und günstig erhältlich.

Momentan habe ich einen S1D13700 angeschlossen (Nachfolger des S1D13305
mit 32kB SRAM intern, benötigt werden aber 36kB). Wegen dem zu geringen
SRAM die Streifen rechts und der Fehler links unten. Mit ausreichend
SRAM ist das Bild komplett OK.

Benedikt!

Mach doch eine komplette Schaltung (inklusive Platinenlayout) daraus und
verkauf das ganze an Pollin. Ich bin sicher, die würden das gerne
verkaufen, da sie die Displays dadurch besser los werden.

Damit die Ansteuerung so gut geht, und die untere Hälfte automatisch
nach der oberen kommt, muss man das LCD etwas modifizieren.
Wenn man das Display zerlegt hat (Schrauben entfernen, Display auf die
Rückseite legen, Schutzfolie abziegen, vorderen Rahmen entfernen,
Klebeband rund um das Display vorsichtig abziehen, vorderen Rahmen
wieder drauf, Schutzfolie wieder drauf, Display auf die Vorderseite
legen, Rückseite entfernen) muss man an der rot gekennzeichneten Stelle
die Leiterbahn durchtrennen und den blau eingezeichneten Draht einlöten.
Der Zusammenbau funktioniert umgekehrt wie das Zerlegen.

Der Hintergrund ist folgender:
Wenn man die Platine betrachtet, sieht man immer eine Leiterbahn die von
einem Treiber zum nächsten gehen. Diese Signale sind jeweils das Enable
Signal für die Schieberegister die jeder Treiber an den nächsten
weitergibt. Der jeweils erste Anschluss liegt dauerhaft auf High. Dies
wird beim unteren Treiber geändert und dieser wird an den Ausgang des
letzen der oberen Hälfte angeschlossen.

Könnte man auch. Würde warscheinlich auf einen ähnlichen Aufwand hinaus
laufen: Leiterbahnen trennen und die zusätzlichen Signale rausführen.

Segor hat als Restposten VRAMs 64Kx4, also DRAMs mit zusätzlich 4 256
Bit Schieberegistern. Vielleicht sind die bei solchen Displays ganz
nützlich.

Screenshot

PWM glaube ich nicht, denn die Spannung am Ausgang des Reglers folgt der
Spannung an Pin 7. Pin 3 wird also z.B. auf -24V gelegt und an Pin 7
kommen dann etwa -19,5V (bei diesem LCD). Eigentlich ist das ganze
unnötig, denn wenn man sowiso eine Spannung extra erzeugt, kann man
diese auch direkt an Pin 3+7 legen. Sowas macht nur Sinn, wenn man z.B.
-24V sowiso schon in der Schaltung hat.
Hier mal eine Schaltung aus dem SP14Q001 (320x240 LCD) Datenblatt. Bei
dem ist das genauso. Nur dass hier V0 an den Eingang eiens als Buffer
geschalteten einen OPs geht, und Vee die negative Betriebsspannung des
OPs ist. So macht das ganze nämlich mehr Sinn.

Christof Rieger wrote:
> Ich habe noch nie mit Graphikdisplays ohne Steuerelektronik gearbeitet,
> was hat es denn mit dem LP und FLM Signal auf sich. Ich habe nähmlich
> auch so ein Teil mal geschenkt bekommen.

LP = HSync, FLM = VSync

> Von der Bildaufbereitung muss man dann ähnlich vorgehen wie bei einem
> CRT-Controllern auf AVR-Basis, nur dass man vier Bit paralell ausgeben
> muss.

Ja. Nur dass obere und untere Displayhälfte parallel ausgegeben werden.

Welche Dauer verwendet man hier für die Bildwiederholrate ?

Mindestens 60Hz (sonst flackerts), maximal etwa 100Hz.
Aber mehr ist aber auch garnicht möglich: Die maximale Taktfrequenz
liegt meist bei 5-6MHz.
Gehen wir mal von 6MHz aus, dann könnte man pro Sekunde
6MHz*4bit=24MPixel übertragen. Bei 288k Pixel pro Bild wären das maximal
83Hz. Üblich sind 70-75Hz.
Außer man modifizier das Display so wie Ale es vorgeschlagen hat, und
erweitert den Datenbus auf 8bit indem man obere und untere Hälfte
gleichzeitig mit Daten versorgt.

Nein, alle Signale (außer FLM) sind auf der negativen Flanke aktiv.
Allerdings müssen LP und FLM die meiste Zeit auf Low sein, damit es
funktioniert:
LP speichert auf der negativen Flanke die Daten einer Zeile und springt
in die nächste Zeile. Wenn während dieser Flanke FLM aktiv ist, wird mit
der 1. Zeile weitergemacht. CLK speichert bei der fallenden Flanke die
Daten.

Christof Rieger wrote:
> Somit:

> 4  /LP

Eigentlich ist das falsch, denn das würde bedeuten, dass der Impuls low
aktiv ist, und somit im Ruhezustand auf high liegt, was aber nicht sein
darf (dann macht das LCD irgendwas undefiniertes). Es ist ganz einfach
ein kurzer high Impuls. Zusätzlich zur Flankentriggerung dient LP
nämlich noch als asynchroner Reset des Spalten Schiebregisters
(zumindest verhält er sich so, wie es genau ist das verraten die
Hersteller nicht).

Christof Rieger wrote:
> O.K. dann hat LP kein Registerverhalten, sondern ein Latchverhalten und
> ist somit nicht invertiert.

Es hat beides, da es mehrere Signale in einem sind:
- High aktiver Reset für den Schreibadresszähler des Spaltenregisters
- Auf fallende Flanke getriggerter Takt für das Zeilenschieberegister
- Auf fallende Flanke getriggerter Latchimpuls für die Spaltendaten

Bei manchen LCDs gibt es daher LP und Y Schiebetakt als getrennte
Signale.

Was jetzt genau in dem Sonderfall passiert, wenn LP aktiv ist, und ein
Schiebetakt kommt passiert, kann ich jetzt auch nicht genau sagen. Ich
vermeide diesen Fall daher immer und halte den Schiebtakt an, wenn der
LP aktiv wird.

Wie gesagt: Was genau in den Zeilen/Spaltentreiber ICs abgeht weiß nur
der Hersteller.
Eigentlich betracht man z.B. das Spaltenregister als Schieberegister.
In der Praxis ist das aber ganz anderst, es ist nämlich vielmehr ein
Speicher mit eingebautem Adresszähler der sequentiell Pixel für Pixel
einliest.

Wenige 100ns. Je nach Display habe ich Angaben von 50ns bis 200ns als
Minimalwert. Ich verwende meist 500ns und hatte damit noch nie Probleme.

Um das ganze mal zum Abschluss (zumindest für meine Displays) zu
bringen. Ich habe das ganze jetzt so gelöst:
Das LCD intern so verdrahtet wie ich es schonmal beschrieben habe.
Auf die Rückseite der Platine habe ich eine Platine mit einem S1D13305
LCD Controller und 64kByte SRAM geklebt. Der 13305 ist nicht ganz für so
große Displays geeignet, da er nur maximal 8,9MHz Pixeltakt unterstützt.
Das Display bräuchte etwa 20MHz. Von daher habe ich den Controller von
maximal zulässigen 10MHz auf 16MHz übertaktet. 16MHz laufen meiner
Erfahrung nach stabil, erst ab etwa 20MHz fangen die Probleme an.
Die Framerate ist zwar immer noch etwas niedrig, aber abgesehen von der
Lösung mit dem Umbau des LCDs auf 8bit Datenleitungen fällt mir nichts
besseres ein.
Das LCD scheint echt ein absolut kundenspezifisches Teil zu sein, denn
man kann es mit keinem von den Standardcontrollern ordentlich ansteuern.

Und hier noch ein Testbild: Ich habe ein Screenshot von dieser Seite
hier geladen. Man könnte aber auch den Textmodus des 13305 verwenden,
funktioniert alles wunderbar. Man muss nur beachten, dass der Controller
auf 1440x200 eingestellt wird, und dass jede Zeile daher aus 180 Bytes
besteht, von denen die ersten 90Bytes in die obere Hälfte kommen, und
die zweiten 90Bytes in die untere Displayhälfte.

Dadrauf könnte ich mir vorstellen das Forum zu lesen, so für unterwegs
:P

Ja, sowas in der Art habe ich damit vor:
Eine PDF zu lesen und zu dekodieren, möchte ich einem AVR nicht antun,
ich werde diese daher vorher in BMPs umwandeln und auf eine SD Karte
kopieren.
Ein Scrollrad aus einer alten Maus soll zum weiterblättern dienen.

Hi,
wo könnte man son SID13305 käuflich erwerben, hab da mal ein bischen
gegoogelt, aber ohne Erfolg

Wigbert

http://www.csd-electronics.de

Ist zwar als Auslaufartikel gekennzeichnet, aber noch erhältlich.
Wenn dieser irgendwann nicht mehr erhältlich sein wird, das ist ein
angeblich (angeblich deshalb, weil er timingkritischer ist) kompatibler
Ersatztyp:
http://www.mitsutech.com/RA8835.html

Müsste man da nicht was mit einem CPLD stricken können? Dazu 2*32kB
SRAM, steckt massenweise in 486er Boards. Die Dinger schaffen 40MHz, mit
Multiplexer im CPLD ergibt das bis zu 640MHz Pixeltakt (bzw. soviel wie
der CPLD hergibt).
Dual-Port kann man über abwechselnde Lese- und Schreibzugriffe
realisieren, dann sind's noch 320MHz Pixeltakt.

Passender CPLD kostet bei Reichelt 3€.

Machbar ist das, aber ein 9572 wird knapp. Die Ausgabe der Daten zum LCD
ist ein Kindenspiel, das schreibt man in 5 Minuten. Das Hauptproblem an
der Sache dürfte die Schnittstelle zum µC sein, wenn diese asynchron
laufen soll.
Ich bin am Ende immer bei einem 95108 oder 95144 gelandet.

Braucht ja nur ein kleiner Teil asynchron zu sein. Geschrieben wird
immer jeden 2. Takt, nur der Updatezeitpunkt für Adress- und
Datenregister ist asynchron. Tut ja nix wenn die Daten jedesmal neu
geschrieben werden, ist ja SRAM.

Werd mir das mal angucken, Montag hab ich die LCDs.

Vielleicht sollte ich das etwas besser beschreiben:
Rechnen wir mal:
Für rund 70Hz braucht man 720x400x70Hz = 20,16MPixel/s, also rund 5MHz
Takt auf der Datenleitung. Den CPLD würde ich daher mit 10MHz Takten.
Die SRAM Bandbreite beträgt dann 10MByte/s, wovon 2,5MB/s für das LCD
verwendet werden.
Für den µC stehen also 7,5MB/s zur verfügung, was reichen sollte.
Das Problem das ich hatte, als ich sowas zuletzt ausprobiert habe:
Ab und zu hatte ich den Schreibzeitpunkt so ungünstig getroffen, dass
die Schreibsignale zu kurz anlagen, und daher falsche Pixel geschrieben
werden.

Falls es hilft: Den eigentlichen LCD Controller kann ich als VHDL Code
beisteuern, nur beim Businterface muss ich passen.

Du kannst den CPLD ja feste Zyklen fahren lassen, immer abwechselnd
einen Lese- und dann einen Schreibzyklus. Also der Schreibvorgang wird
nicht vom uC angestoßen, sondern vom CPLD.

Also halt so:
Takt 1: Daten lesen
Takt 2: Daten schreiben
Takt 3: Daten lesen
Takt 4: Daten schreiben

usw.

Was der CPLD bei jedem Takt schreibt wird intern in Registern gehalten.
Soll nichts geschrieben werden, schreibt er immer wieder die Daten vom
letzten Schreibvorgang, was aber nicht stört.

Der uC verändert nur die Register im CPLD, die Daten und Adresse für die
Schreibvorgänge enthalten.
Könnte man noch so erweitern, dass man 4 Schritte macht. So könnte man
auch Daten aus dem Framebuffer zurücklesen.

Bei einem FF pro Makrozelle braucht man min. folgendes:

- 8 FF: 8Bit Daten für Multiplexer zum LCD
- 19 FF: 16Bit Adresszähler für Leseop. (15Bit+1Bit Chip select) + 3Bit
Bitzähler für Multiplexer
- 8 FF: 8Bit Datenregister für Schreibop.
- 16 FF: 15Bit Adressregister für Schreibop. + 1Bit für Chip Select

Macht also schonmal min. 51 Makrozellen. Man könnte ein Write Enable
einführen (es wird also nicht immer geschrieben), und der uC muss bei
einer Schreibop nachdem die Adressen gelatched wurden die Daten am CPLD
anliegen lassen. Spart 8FF für Daten, Write Enable muss aber auch durch
ein FF.

I_ H. wrote:
> Was der CPLD bei jedem Takt schreibt wird intern in Registern gehalten.
> Soll nichts geschrieben werden, schreibt er immer wieder die Daten vom
> letzten Schreibvorgang, was aber nicht stört.

Ich hatte das etwas anderst gelöst:
Einen Adresszähler fürs schreiben, so dass ich mir die 15 Adressbits (in
meinem Fall waren es 18, da das ganze 512x256x8bpp x2 Pages konnte)
sparen konnte, und sequentiell die Pixel geschrieben habe.
Das Problem war anscheinend, was passiert, wenn ich während einem
Schreivorgang von Register ins SRAM neue Daten ins Register schreibe ?
Dann waren eventuell die Daten nicht ausreichend stabil, so dass eine
Mischung aus alten und neuen Daten geschrieben wurde. Grob geschätzt
waren dann auf das 512x256 Bild (also auf 128k) etwa 100 Pixel falsch.

> Macht also schonmal min. 51 Makrozellen.

Nicht zu vergessen: Adress und Datenmultiplexer. Das schlägt auch
nochmal mit einigen Makrozellen zu. Wie gesagt: Ein 9572 wird knapp.


Und direkt noch eine Frage:
Wie würdet ihr die Speicherorganisation machen ?
Einfach: So wie die übertragen werden, also immer abwechselnd Zeile 1,
Zeil 201, Zeile 2, Zeile 202 usw.
Aufwendiger, aber logisch: So wie sie sichbar sind, also Zeile 1, Zeile
2, Zeile 3 usw.
Wie würde man das letzeres elegant lösen ?
Mit 2 Adresszählern für X und Y und einer Berechnung der SRAM Adresse
aus X und Y (multiplikation erforderlich, also vermutlich nicht
machbar), oder mit 3 Adresszählern: Einen für X, einen für Y und einen
für die Speicheradresse.

M ist es ganz sicher nicht, denn das wird von dem Gatearray erzeugt.

Ich denke physikalisch nicht benutzt, denn wenn ich gegen Vcc/GND messe
ist alles offen und auch optisch sieht man keine Leiterbahnen.

Ich habe mal ein bischen VHDL Code zusammengebastelt. In der Simulation
sah es gut aus, die Framerate liegt bei etwa 70Hz.
Ob die Daten richtig rauskommen usw. habe ich noch nicht nachgeprüft.
Ein XC9572XL ist zu 94% voll.
Anscheinend gibt es diesen nicht als PLCC84 Version so wie den XC9572
(der verdammt teuer geworden ist).

Die Adressierung ist noch nicht wirklich fertig, aber ich denke man kann
drauf aufbauen.

Du meinst also den LPC2101 als LCD Controller missbrauchen ?
Müsste man mal ausrechnen ob das vom Timing her passt. Die ARMs sind ja
nicht gerade die schnellsten, wenn es um das Pingewackel geht.
Ich denke da wäre ein AVR fast besser geeignet.

@Benedikt:

So wie ich das sehe, ist ja in deinem Code von µC Seite aus nur das
Schreiben in den RAM gestattet. Es werden aber pro Byte 8 Pixel
abgespeichert. Um also einen einzelnen Pixel zu ändern müsste man
Schreiben und lesen können. Oder hab ich jetzt was übersehen?

Ja, das war bei der alten Version noch nicht drin. Die neuen können auch
lesen.

Ah ok :-)
Kannst du mal den Code online stellen?

Ich habe erst kürzlich das gleiche versucht (anderes Display). Meine
Lösung ist mit 66Mhz getaktet und der XC95144 ist so klein, dass ich
keine freie Pinauswahl mehr habe.

Ich hab daran ca. 4 Wochen gearbeitet und stand zeitweise kurz vor einem
Nervenzusammenbruch, da es ständig schreib/lese Fehler auf der µC Seite
gab. Der einzige grundlegende Unterschied zu deinem Design ist, dass ich
den CPLD über das XMEM-Interface des ATMegas angeschlossen habe und
daher, was die Timing angeht, doch relativ festgelegt war.

Daher würde mich deine Lösung mal interessieren, die anscheinend
wesentlich effizienter ist als meine :-)

(Mir kommen die Tränen, wenn ich an die wochenlange Arbeit denke...)

Hi Benedikt,
hab ein LH5164N-10L SHARP rausgekramt, sollte doch als SRAM gehen,oder?

Wigbert

Achso, du meinst den VHDL Code ? (Ich dachte du beziehst dich auf den
AVR Code.)
Der VHDL funktioniert vermutlich noch garnicht, denn den habe ich vorhin
in 10 Minuten schnell zusammengebaut und dabei nur Wert auf das LCD
Timing gelegt.
Wie zuvor schon geschrieben: Ich hatte mit dem XMEM Interface auch
ziemliche Probleme, und bin daher von der CPLD Lösung als LCD Controller
wieder weg.
Prinzipiell läuft das ja, nur das Interface zum AVR macht Problem. Daher
hoffe ich jetzt, dass I_ H. hier mehr Ahnung hat als ich, und das
hinbekommt.

Wigbert Picht wrote:
> Hi Benedikt,
> hab ein LH5164N-10L SHARP rausgekramt, sollte doch als SRAM gehen,oder?

Das dürfte ein 8k x8 SRAM sein, also etwas zu klein. Mit vielen davon
wird es gehn, aber die Arbeit willst du dir sicherlich nicht machen...

Ja genau, ich denke, dass wenn ich nicht auf das XMEM Interface
bestanden hätte, wäre ich auch schneller und einfacherer zum Ziel
gekommen. Aber der AVR gibt eben das ganze Timing diesbezüglich vor und
wird sehr zickig, wenn da was nicht stimmt. Gestaltet man den Zugriff
des µCs in Software statt in Hardware (auf den CPLD) kann man ja
wesentlich flexibler sein.

Meine Lösung läuft jetzt zwar sehr gut (absolut keine Lese/Schreibfehler
mehr) aber ich benötige dazu eben auch 66Mhz und nahezu den kompletten
XC95144.

Ich bin noch nicht ganz fertig mit dem Projekt, hier und da kann sicher
noch ein Register oder so eingespart werden, aber wenn jemand soetwas
mit wesentlich geringerer Taktrate und Ressourcenbedarf im CPLD
hinbekommt, dann bin ich gerne Bereit ihn in Zukunft als "meister"
anzusprechen ;-) Ne würde mich echt mal interessieren, ob ich einfach
nur zu blöd bin oder die Aufgabe einfach nur zu anspruchsvoll für eine
einfachere Lösung.

A. N. wrote:
> Ne würde mich echt mal interessieren, ob ich einfach
> nur zu blöd bin oder die Aufgabe einfach nur zu anspruchsvoll für eine
> einfachere Lösung.

Eindeutig letzteres. Asynchron und CPLD passen einfach nicht zusammen.
Ich bin mal gespannt ob es jetzt jemand schafft, den CPLD an den AVR zu
bekommen, ohne per Software ein extrem schlaffes Timing vorgeben zu
müssen (wobei mir das schreiben schon reichen würde, denn lesen schaffen
auch die echten LCD Controller meist nur mit waitstates oder dummy
read).

LCDs sind da, hab über das Wochenende aber leider keine Zeit. Also erst
nächste Woche.

Nun meine letzten Tests gingen mit 16MHz und doppelten Waitsate.
Allerdings sind die Timings in der dafür zuständigen FSM im CPLD noch
recht großzügig. Ich wollte mich in den kommenden Semesterferien noch
einmal hinhocken und etwas dran schrauben. Ich bin zuversichtlich, dass
ich ein Lesen/Schreiben bei 16MHz zumindest mit nur noch einem Waitstate
hinbekomme. Ob es auch völlig ohne geht... naja, da will ich nicht zu
optimistisch sein.

Allerdings hab ich mir auch schon die Frage gestellt, ob das überhaupt
nötig ist. Ok wenn man den RAM sowohl vom AVR als Arbeitsspeicher als
auch vom CPLD als Grafikspeicher nutzen möchte muss man diesen Weg
gehen. Der Vorteil ist auch, dass das Beschreiben des Grafikspeichers
dann sehr schnell geht und natürlich in C sehr elegant über eine
einfache Pointeroperation erledigt werden kann ;-)

Wenn dies aber nur damit zu lösen ist, das man bei größeren Displays
einen noch größeren CPLD als einen XC95144 benötigt, dann stellt sich
natürlich schon die Frage, ob es nicht besser ist ein eigenes "nur lese"
Interface für den µC zu schreiben. Man müsste dann eben pro Pixel ein
Byte opfern, was aber bei den heutigen SRAM Größen nicht tragisch wäre.
Kritischer wird es, dass man nun pro LCD-Takt 4 Bytes lesen muss, was
die Taktrate des CPLDs wieder in die Höhe treibt.

Der AVR hätte dann eben keinen Arbeitsspeicher zur Verfügung und
bräuchte, falls dieser nötig ist, noch ein zweites SRAM. Aber zwei SRAMs
sind immer noch billiger als ein XC95256...

Naja, wenn die Klausuren in diesem Semester vorbei sind, möchte ich mir
noch einmal genauere Gedanken zu dem Thema machen...

A. N. wrote:
> Der AVR hätte dann eben keinen Arbeitsspeicher zur Verfügung und
> bräuchte, falls dieser nötig ist, noch ein zweites SRAM. Aber zwei SRAMs
> sind immer noch billiger als ein XC95256...

Dann würde ich eher einen Coolrunner CPLD oder gleich einen FPGA
verwenden. Die kosten nämlich auch nicht viel.
Verwwendest du eigentlich die XC95xxx oder die XC95xxx XL ? Letztere
sind nämlich bedeutend billiger.

Ich verwende die XL Variante... der XC95144XL ist in der Tat recht
günstig, aber der XC95256XL eben nicht (und schwer zu bekommen). Ähnlich
schwer sind aber auch Coldrunner zu bekommen und günstig sind diese
(zumindest in der geeigneten Leistungsklasse) auch nicht. Bei einem FPGA
benötigt man allerdings zusätzlich noch den System PROM und kommt somit
auch schon wieder auf gewisse Kosten. Ich glaube rs-components hat
solche (warum Reichelt die nicht gleich zusammen mit den FPGAs anbietet
ist mir auch ein Rätsel. )

Naja der große Vorteil der XC95xxxXL Reihe ist eben die 5V
Verträglichkeit an den Pins und da ein ATMega bei 16Mhz 5V benötigt, ist
das durchaus ein Argument für diese CPLDs.

Stimmt, die Coolrunner sind nicht mehr 5V tolerant. Dafür haben die
andere nette Features wie DDR oder ähnliches wordurch die Makrozellen
effektiver genutzt werden können. Da fast alle Bauteile TTL kompatibel
sind, kommen diese auch wunderbar mit den 3,3V zurecht. Wobei die alten
XC95xxx auch nur etwa 3,5V und keine 5V liefern.

Ja aber ob dem Coldrunner die 5V Pegel vom AVR schmecken ist dann wieder
eine andere Frage ;)

Wenn du allerdings eine günstige Quelle für große Coldrunner kennst,
wäre das Klasse, ich habe bis jetzt nicht viel finden können, außer die
teuren bei rs.

Ach so, ich sehe gerade: ich meine natürlich den XC95288XL und nicht
256XL ;)

Ich hatte mir zuletzt welche bei Digikey gekauft, da kostet ein XC2C256
rund 10€, der XC2C128 rund 5€, was eigentlich ganz OK ist.

Ja Wahnsinn, da hab ich noch gar nicht geguckt... Danke Dir!

chris wrote:
> bez. des LPC, ich dachte eigentlich an den 2103, da mehr RAM,
> um ev. das Display ohne externem SRAM nur für Textausgaben zu benutzen.

Der 2103 hat 32kByte, das Display braucht 36k, reicht also nicht

> Von der Geschwindigkeit her, dürfte es kein Problem sein.

Das sehe ich anderst. Der ARM dürfte ziemlich gut beschäftigt sein,
Daten aus einem externen SRAM zu lesen, und an das Display
weiterzureichen. Ich wage es fast zu behaupten, dass ein AVR das
schneller ist.

chris wrote:
> Benedikt wrote:
>>>Ram
>>Der 2103 hat 32kByte, das Display braucht 36k, reicht also nicht
> Er hat 8Kb ram, ein paar mehr als der AVR.

Stimmt, 32kB ist der Flasg. Aber da man sowio einen externen SRAM
braucht, ist es egal.

> Der lpc210(1/2/3) sind optimierter als der Rest der lpc21xx ,
> sie schaffen es auf Clock/4 = 70/4 = 17.5 M I/O ops.

Ein AVR schafft das auch. Und der hat ein Businterface, so dass man auf
rund 5,3MHz Datenrate kommt, inklusive Adressausgabe und Readimpuls.
Ich rechne mal:
- 1 Takt für die 16bit Adresse erhöhen
- 4 Takte für die 16bit Adresse
- 4 Takte für RD\ auf Low
- 4 Takte für RD\ auf High

Der ARM muss also mit 70MHz laufen, um das selbe zu leisten, wie der AVR
mit 16MHz...
Bei Pingetoggelt sind die großen µC echt langsam.

> bei kosten von 5Euro inkl. Platine und SRAM ist es mir egal.

Wo bekommt man den LPC2103 für 5€ inkl Platine ?

Verkaufst du die Platinen auch ? Weil das klingt echt nicht schlecht.
Für das Geld bekomme ich gerade mal den Controller selbst...

> Das mit dem 4 Taktclocks und davon nur eine direkte I/O operation kann
> auch von Vorteil sein, da dadurch ein Interleaving von Executionskode
> möglich wäre, und man sich somit für einfache Sachen einen weiteren
> Prozessor einsparen kann.

Heißt dass, dass während der Ausführung der IO Operation die 4 Takte
benötigt, noch 3 andere Befehle nebenbei möglich sind ? Ich kenne mich
mir ARMs nicht wirklich gut aus, die Ausführungszeiten der Befehle zu
verstehen, habe ich schon lange aufgegeben.

Benedikt K. wrote:

> Verkaufst du die Platinen auch ? Weil das klingt echt nicht schlecht.

Würde ich mich anschliessen.

will ggf. auch so ne Platine,  .. wirds die geben?

chris wrote:
> Die Platine wird es geben, wenn Benedikt mich beim Programmieren
> unterstützt, bezüglich Timing, Displayansteuerung usw. Mich da selbst
> durchzuarbeiten glaube ich wäre zuviel Zeitaufwand.

Kein Problem. Ich habe u.a. eine einfache C Routine die das Prinzipielle
LCD Timing zeigt. Außer einem Schachbrettmuster wird zwar nicht viel
angezeigt, aber das sollte zum Verstehen reichen.

> Ne kurze Frage, sollte die MCU ohne externe RAM ausgestattet werden,
> sprich nur Text,

Wäre schade. Bei 8x12 Schriftart passen 3k Zeichen auf das Display, da
würde der LPC also reichen.

> in welcher Zeit muß eine Linie (nehme an 8 bits) aufgebaut werden ?

Wie meinst du das ? Meinst du die Zeit für die Datenausgabe einer Zeile
an das LCD, oder für ein Datenpaket ans LCD ?

Das Ansteuern eines SRAMs in Software, das Zerlegen eines Bytes in 2
Nibble und das Ausgeben der Daten an das LCD wird den LPC schon stark an
die Grenzen des machbaren bringen. Vielleicht wäre ein 16bit SRAM am
sinnvollsten, denn damit würden sich die Zugriffe halbieren.

Bei mir sind es -5,9mA.

chris wrote:

> Welches Interface möchtet ihr noch drauf haben, z.B. USB, IRDA, I2C, ...

SPI wäre schön.

> oder sonstige Wünsche. Hat jemand ev. auch eine Idee, was man mit dem
> überschüssigem SRAM anfangen könnte ?

- Mehrere Pages (eine beschreiben, eine anzeigen)
- Text und Grafikmodus (wird vermutlich aus Timinggründen nicht
funktionieren)

Hi,
würde auch so eine Platine nehmen.


Wigbert

Ich nehme an, dass die Daten zum Display eigentlich interleaved
übertragen werden sollten, also ClkO-ClkU-ClkO-ClkU-.... wodurch sich
für ClkX und Data eine Signalfrequenz von 2,5-3,5MHz ergibt.

Kann man das auch nacheinander machen, also 180xClkO, dann Umschaltung
und 180xClkU? Die erforderliche Taktfrequenz von ClkX verdoppelt sich
dabei natürlich.

Wenn das nämlich auch nacheinander mit 8MHz ClkX Frequenz geht, dann
müsste sich eine Vollgrafik-Version mit einem 16MHz Mega162 (Mega16,
...) und einem 256Kx4 VRAM realisieren lassen (plus ein paar Gatter
für's ClkO/ClkU-Gating). CPU-Last für Videorefresh ist dann 12% (70Hz)
bis 18% (100Hz) - komplett in C programmiert.

PS: Interleaved geht mit VRAM natürlich auch, mit Flipflop für's Gating,
aber die Anordnung der Daten im Speicher ist dann nicht so elegant.
Wodurch die Möglichkeit verloren geht, Zeilen mit einem VRAM-Zugriff
komplett zu löschen.

Andreas Kaiser wrote:
> Ich nehme an, dass die Daten zum Display eigentlich interleaved
> übertragen werden sollten, also ClkO-ClkU-ClkO-ClkU-.... wodurch sich
> für ClkX und Data eine Signalfrequenz von 2,5-3,5MHz ergibt.

Könnte sein, allerdings ist es komplett egal, und bringt eigentlich auch
keine Vorteile, denn die Anzahl an Takten muss trotzdem vorhanden sein.

> Kann man das auch nacheinander machen, also 180xClkO, dann Umschaltung
> und 180xClkU? Die erforderliche Taktfrequenz von ClkX verdoppelt sich
> dabei natürlich.

Ja sollte egal sein.

> Wenn das nämlich auch nacheinander mit 8MHz ClkX Frequenz geht, dann
> müsste sich eine Vollgrafik-Version mit einem 16MHz Mega162 (Mega16,
> ...) und einem 256Kx4 VRAM realisieren lassen (plus ein paar Gatter
> für's ClkO/ClkU-Gating). CPU-Last für Videorefresh ist dann 12% (70Hz)
> bis 18% (100Hz) - komplett in C programmiert.

Hast du schonmal mit VRAMs gearbeitet ?
Ich habe früher einiges mit denen gemacht, nur sind die leider recht
selten und von der Ansteuerung halt etwas aufwendiger (ist halt ein
DRAM).

Eine andere Möglichkeit die ich mir überlegt hatte ist, ein Clock zu
invertieren und so die Daten an beiden Taktflanken übertragen.
Allerdings ist dann das Timing etwas kritisch, bzw. man müssten den
Controller sehr viel schneller takten, um das Timing einzuhalten.
Da ich nicht weiß welche Treiber in dem LCD verbaut sind, und es an sich
auch wenige Datenblätter gibt, gehe ich jetzt mal vom T6A39 aus. Der
T6A39 ist ein etwas älterer Spaltentreiber der vom Alter her in etwa zu
dem LCD passen könnte.
Diese ist mit 20ns Setup und 40ns Hold Zeit angegeben, was DDR sehr
schwer macht. Die maximale Taktfrequenz ist übrigends mit 4MHz
angegeben, was für dieses LCD sehr wenig ist (das wären gerade mal 55Hz
Framerate). Mehr als 8MHz habe ich aber in noch keinem Datenblatt
gesehen.

Bei diesem LCD habe ich gerade mal die Frequenz etwas hochgedreht: Bis
40MHz Pixeltakt (also 10MHz Schiebetakt) gab es keine Probleme. Mehr
schafft mein Controller nicht.

Als Entwurf kommt bei mir ungefähr sowas bei raus. Beim Gating vom
ClkO/U kann es sein, dass noch 2 Inverter nötig sind, bislang habe ich
nur das SC-Gating (IC2A) verifiziert.

Das Timing sieht auf Scope&LA jedenfalls gut aus, insoweit das ohne VRAM
und ohne Display verifiziert werden kann.

In dieser Form wird LP per Software erzeugt, was einen gewissen Jitter
durch andere Interrupts und durch VRAM-Zugriff im Hauptprogramm mit sich
bringt. Das liesse sich auch noch vermeiden, allerdings ist dann
entweder der 4. Timer auch noch weg, oder der LCD-Datentakt entspricht
dem CPU-Takt, was für meinen Geschmack ein bischen viel ist. Der
Datentakt liesse sich durch einen niedrigeren CPU-Takt etwas reduzieren,
untere Grenze bei 6-7MHz.

Andreas Kaiser wrote:
> Als Entwurf kommt bei mir ungefähr sowas bei raus. Beim Gating vom
> ClkO/U kann es sein, dass noch 2 Inverter nötig sind, bislang habe ich
> nur das SC-Gating (IC2A) verifiziert.

Es dürften jetzt immer abwechselnd 256 Takte auf ClkO/ClkU rauskommen,
wenn ich das richtig sehe.

Ich würde SE\ und SEN zusammenfassen, denn irgendwo im Datenblatt steht
glaube ich, dass SE\ ein bestimmtes Verhältnis zum SC haben soll.

Wiso verwendest du 2 Pins für SCLK ? Wie erkennst du, ob das VRAM
nachgeladen werden möchte ? Dazu wird normalerweise der QSF Pin
benötigt. Verwendest du den Split Mode ?

Benedikt K. wrote:

> schwer macht. Die maximale Taktfrequenz ist übrigends mit 4MHz
> angegeben, was für dieses LCD sehr wenig ist (das wären gerade mal 55Hz
> Framerate).

Wenn die Hälften nacheinander übertragen werden ja. Wenn interleaved
angesteuert wird, dann reichen 4Mhz bis 110Hz Framerate aus. Setup/Hold
Times sind zwar deutlich, aber bei 125ns Zyklus wohl noch machbar. Diese
Problematik ist bei SDR und DDR zudem nicht allzu verschieden, die
Datenrate von 8MHz ist ja in beiden Fällen gleich.

Benedikt K. wrote:

> Es dürften jetzt immer abwechselnd 128 Takte auf ClkO/ClkU rauskommen,
> wenn ich das richtig sehe.

> Wiso verwendest du 2 Pins für SCLK ?

SCLK wird vom Timer0 erzeugt, gibt 8MHz. Timer 1 läuft an selbigem
extern zugeführtem Takt, daher T1=OC0, und schaltet via OC1A=SEN den
LCD-Takt nach 2*180 Takten ab. Nach LP Interrupt und
Transfer/Split-Zyklus wird Timer1 wieder gestartet (T1CNT=0xFFFF).

> Ich würde SE\ und SEN zusammenfassen, denn irgendwo im Datenblatt steht
> glaube ich, dass SE\ ein bestimmtes Verhältnis zum SC haben soll.

Da ich nicht vorhabe, Daten seriell reinzutakten, kann ich SE auch auf
GND legen, denn für den seriellen Lesemodus ist das nur ein OE.

> Wie erkennst du, ob das VRAM
> nachgeladen werden möchte ? Dazu wird normalerweise der QSF Pin
> benötigt. Verwendest du den Split Mode ?

Ja, ich verwende den Split Mode. QSF signalisiert m.W. nicht ob er
nachgeladen werden möchte, jedenfalls nicht im Datasheet vom TC425258B
(vom AZ-Typ habe ich keines gefunden), sondern welche Hälfte grad aktiv
ist.

Nach LP kommt also erst ein Transfer-Zyklus mit A8row=0 und A8col=0,
dann ein Split-Zyklus mit A8row=1 (und implizit A8col=1).

Wenn also in Transfer- und Split-Zyklus Col=256-180 gesetzt wird,
schaltet QSF automatisch nach 180 Takten auf die zweite Hälfte um.

Die obere Display-Hälfte liegt mit also im linken oberen Quadranten vom
VRAM, die untere um unteren rechten Quadranten.

Netterweise kann man so auch den Flash-Modus verwenden, um ganze Zeilen
mit einem VRAM-Zugriff zu plätten.

Der Testcode für's Timing. Wie schon geschrieben, es hängt nichts dran
ausser IC2A.

Andreas Kaiser wrote:

> Ja, ich verwende den Split Mode. QSF signalisiert m.W. nicht ob er
> nachgeladen werden möchte, jedenfalls nicht im Datasheet vom TC425258B
> (vom AZ-Typ habe ich keines gefunden), sondern welche Hälfte grad aktiv
> ist.

Genau. Und mit der Flanke triggere ich einen Interrupt in dem
nachgeladen wird. Aber das dürfte hier ja egal sein, da eine Page mit
512x4bits für eine komplette Zeile ausreicht. Von daher ist der Split
Modus eigentlich garnicht notwendig.
Ich verwende die VRAMs für einen Logik Analyser/DSO um 16bit breite
Daten mit bis zu 40MHz einzulesen. Da habe ich halt einen
kontinuierlichen Datenstrom der weggeschrieben werden muss.

> Wenn also in Transfer- und Split-Zyklus Col=256-180 gesetzt wird,
> schaltet QSF automatisch nach 180 Takten auf die zweite Hälfte um.

Stimmt, das kann man da ja einprogrammieren. Intelligente Lösung.

PS: Kannst du das Datenblatt mal hochladen ? Ich finde unter der
Bezeichnung rein garnix.

Benedikt K. wrote:

> Genau. Und mit der Flanke triggere ich einen Interrupt in dem
> nachgeladen wird. Aber das dürfte hier ja egal sein, da eine Page mit
> 512x4bits für eine komplette Zeile ausreicht. Von daher ist der Split
> Modus eigentlich garnicht notwendig.

Wenn man die Daten der unteren Bildhälfte direkt rechts neben die obere
Bildhälfte legt, dann nicht. Aber dann lässt sich der Flash-Load nicht
verwenden, jedenfalls nicht selektiv für einzelne Bildzeilen.

> PS: Kannst du das Datenblatt mal hochladen ? Ich finde unter der
> Bezeichnung rein garnix.

datasheetarchive.com => TC524258B. Im Bild ist ein Tippfehler ;-).

So sieht die komplette Zeile aus.
D14 = LP
D13 = DSF
D12 = RAS
D11 = CAS
D10 = DT/OE
D9  = WB/WE
D8  = A8

D3  = Mainloop
D2  = SC
D1  = SEN
D0  = SCLK

Und so der Anfang davon.

Andreas Kaiser wrote:

> Wenn man die Daten der unteren Bildhälfte direkt rechts neben die obere
> Bildhälfte legt, dann nicht. Aber dann lässt sich der Flash-Load nicht
> verwenden, jedenfalls nicht selektiv für einzelne Bildzeilen.

Stimmt.
Die VRAM Ansteuerung am besten noch in Assembler machen, dann geht es
Geschwindigkeitsmäßig richtig ab.

Das schreit ja fast nach einen kleinen Wettbewerb:
Wer baut den besten LCD Controller für dieses LCD.
Kriterien:
- Einfachheit (Anzahl ICs, Spezialbauteile erforderlich, LCD muss
modifiziert werden)
- Geschwindigkeit
- Features (nur schreiben, Pixelsetzen, Textmodus usw.)

> datasheetarchive.com => TC524258B. Im Bild ist ein Tippfehler ;-).

Nicht nur im Bild. Im Text hattest du auch noch einen. Und da zeigt sich
direkt mal die Schwäche von google: Wenn ein Zeichen falsch ist, findet
man garnichts.

Benedikt K. wrote:

> Die VRAM Ansteuerung am besten noch in Assembler machen, dann geht es
> Geschwindigkeitsmäßig richtig ab.

Richtig effizient wird es erst, wenn man im LP-Interrupt keine Register
sichern muss. Sonst macht das kaum einen Unterschied. Und dann gibt es
potentiell Ärger mit der Registerverwendung des C Programms.

Und ob sich das lohnt? Die CPU-Last ist ja auch jetzt schon sehr gering.

Einschränkung ist, dass Interrupts nicht länger als wenige Mikrosekunden
gesperrt sein sollten, um den LP-Jitter in Grenzen zu halten. Aber das
haben alle Software-Lösungen für LP so an sich. Wenn das vermieden
werden muss, muss LP von einem Timer erzeugt werden (geht), dann dürften
Interrupts annähernd so lange gesperrt sein wie noch "Luft" in der
Zeilenübertragung ist (also ca. 25µs bei 70Hz).

Komplett nebenwirkungs- und jitterfrei geht das, wenn man als Controller
einen Parallax Propeller verwendet. Ich schätze, dass damit grad mal ein
COG für Refresh und VRAM-Zugriff verbraten wird. Nur dauert da dann der
Zugriff auf das VRAM durch das Hauptprogramm wesentlich länger.

Andreas Kaiser wrote:
> Und dann gibt es
> potentiell Ärger mit der Registerverwendung des C Programms.

Dafür kann man ja die Register sichern. Die C Interrupts sichern
standardmäßig immer das zero Register und ähnliches, auch wenn das
unnötig ist. Man kann also einiges einsparen.

Vor allem bei den DRAM Zugriffen ist bestimmt Optimierungspotential

Der VRAM müsste auch genügend Speicherplatz für mehrere Bilder und somit
für Graustufen haben, denn das LCD ist nichtmal schlecht für Graustufen.
Hier mal ein Bild mit 16 Graustufen.

2 Bit pro Pixel sollte in dieser Version kein Problem sein. Mehr geht
darin nicht, weil dann meine Trickserei mit A8 und QSF nicht mehr
funktioniert.

Im interleaved mode ist man in der Adressierung weniger beschränkt, da
geht auch mehr, rechnerisch sind 4 Bits pro Pixel drin.

chris wrote:
> Ram kommt ein 256kbit drauf

kbit oder kByte ?
Weil das Display hat 288k Pixel...

> Bitte spezifizieren, ob mit oder ohne Spannungsinverter

Die Frage ist halt, ob das ganze speziell für das LCD sein soll, oder
eher als etwas universelles ARM Board gedacht ist.

Könntest du einen Schaltplan oder ähnliches hier reinstellen, damit man
sehen kann, was alles drauf ist ?

> Bitte spezifizieren, ob mit oder ohne
> Spannungsinverter, wenn jemand noch mitbestellen will. Der genannte
> Preis war ohne Spannungsinverter.

ich mit bitte, gerade ge-pollint ;-)

Hallo Chris, Benedikt

zunächst einmal ganz herzlichen Dank, daß ihr beiden gemeinsam eine
passende Lösung entwickelt. Danke!

chris wrote:
> Bitte spezifizieren, ob mit oder ohne Spannungsinverter,
> wenn jemand noch mitbestellen will.
> Der genannte Preis war ohne Spannungsinverter.

Bitte, wenn möglich, mit Inverter. Wie dem auch sei:  Hiermit bestelle
ich auch eine Platine. Sofern Du Teilesätze anbietest (mit Ausnahme des
Displays, das liegt hier schon bei mir dumm rum), würde ich auch da
nicht nein sagen. Teil mir halt Deine Bankverbindung und den
Gesamtbetrag mit, damit ich das vorab auf Dein Konto überweisen und Dir
per PM die Lieferadresse mitteilen kann. Ganz herzlichen Dank im voraus!

schließe mich den Worten von Klaus an,
Interesse an Bauteilsatz mit Inverter inkl. Platine, ebenso bitte PNmail
mit Kto.Verbindung bitte.
LG
Vajk

>An ein paar Platinen (auch) zum Experimentieren hätte ich auch
>Interesse.
>Da wären eine Programmierschnittstelle (JTAG) und ein(ige) Stecker für
>die unbenutzten ARM-Pins ganz nützlich.
Leider werden keine Pins mehr frei sein, außer für Tastatureinlesen
usw, welche jedoch schlussendlich gemultiplext werden.
Laut derzeitigem Design kann der sekundäre Jtag zum Debuggen genutzt
werden.

Könnte anbieten, eine Entwicklungsplatine für lpc2xxx (ohne externen
Speicher) zu machen.

Für den Fall, daß sich jemand erbarmt und einen Teilesatz (ohne das
eigentliche Display) inklusive Platine anbieten sollte:

Den wahrscheinlich für das Display passenden LeiterPlattenVerbinder habe
ich bei http://www.csd-electronics.de/ gefunden:

Bezeichnung: LPV Buchse 10 polig inkl. Kabel  Lagerartikel
Best.Nr.: 016-KB10
Preis 0,69 € /Stück

Bei http://www.reichelt.de/ als 10-polige Buchse unter der
Bezeichnung PS 25/10G WS
für 1,25€

und als 2-polige Buchse unter der
Bezeichnung PS 25/2G WS
für 0,25€

Klaus R. wrote:

> Den wahrscheinlich für das Display passenden LeiterPlattenVerbinder habe
> ich bei http://www.csd-electronics.de/ gefunden:

Nein, der passt nicht. Das sind keine 2,54mm. Es müssten 2mm sein, wenn
ich mich nicht vermessen habe, und die Pins sind auch dünner und rund.

Hab mein Display jetzt auch am AVR laufen. Dank C kann man jedes Bild
einzeln sehen. Der XC9572 steht aber schon bereit.

Wusste bisher auch nicht, dass der LPC2103 ein secondary JTAG hat. Das
kenne ich eher von NPXs Betaversion, dem LPC2106.

> Platine kann ruhig Hartpapier oder Pertinax oder so was sein (ist mir
> sogar lieber wg. Bohrer), Lötstopp-Lack und Aufdruck brauchts wohl
> nicht.
wenn schon, dann bitte professionell - Lötstopplack ist ein muß bei smd,
Aufdruck muß nicht. Da sicher zweiseitig, ists sowieso schon gebohrt,
menno!

Also hier erstmal ein erster Ansatz des Layout, Display-Stecker fehlt
noch,
da ich noch herausfinden muß, was für Stecker das sind.
Implementiert wird dann RS232 (TTL/V24) oder I2C. Kann über Lötjumper
konfiguriert werden, die SW-Erkennung ist automatisch. Hünerfutter
fehlt noch. Von den drei linearen Spannungsreglern werden nur 2 bestückt
werden, da 5V Spannungversorgung vorausgesetzt wird, kann von Hand
nachgelötet werden. Weiters werden die Defaulteinstellungen I2C
Protokoll
sein, sowie keine Bestückung von Buzzer, Feets, sowie Sub-D Buchse.

Es ist jetzt ein kleineres Problem rausgekommen, mein Lieferant hat nur
mehr 6 Stück 512Kx8 SRAM´s (Preis 0.50 Euro), also weiß jemand von euch,
wo man günstige SRAMS mit mindestens 256Kx8 bekommt ?

Francesco Na wrote:
> Also hier erstmal ein erster Ansatz des Layout

Naja, da sind einige Sachen drin, die mir nicht so ganz gefallen:
Ein offenes Mosfet Gate an RS232 halte ich für etwas empfindlich.
Zumindest einen Pulldown oder besser einen Spannungsteiler würde ich
schon dran setzen (ansonsten empfängt der UART Mist, wenn der Eingang
offen ist).
Ebenso R1. Dies erfordert, dass man RTS aktiviert, was wieder
umständlich ist. Wäre es nicht besser, R1 an D2 zu hängen ? Hier liegen
immer >=5V an.
Was ist das für eine Beschaltung an VBAT ? Laut Datenblatt soll man
glaube ich hier 3,3V anlegen, wenn man diesen Pin nicht braucht.
Ob das mit dem Spannungswandler so geht, würde ich sicherheitshalber
vorher mal ausprobieren. Da zum Starten C13 die GND Verbindung des
MC34063 ist, hatte ich mit <10µF schon öfters Probleme, vor allem wenn
Vee belastet wird.

> Es ist jetzt ein kleineres Problem rausgekommen, mein Lieferant hat nur
> mehr 6 Stück 512Kx8 SRAM´s (Preis 0.50 Euro), also weiß jemand von euch,
> wo man günstige SRAMS mit mindestens 256Kx8 bekommt ?

So günstig nicht. Reichelt hat welche, aber teuerer. Wo bekommt man die
so billig, vor allem in so kleinen Mengen ?

An welche maximale Zugriffsrate für das RAM hattest du dabei gedacht?
Ein Ripple Counter wie das HC4040 braucht schon im Idealfall grob
geschätzte 250ns bis sich der Taktimpuls bis zum letzten Ausgang
rumgesprochen hat (interpoliert für 3,3V, je nach Datasheet können da
auch 500ns rauskommen).

Wie soll dabei der Datenzugriff durch den Controller erfolgen? Die Daten
müssen ins RAM ja auch irgendwie rein, der Counter ist aber vom Refresh
belegt.

Stimmt, den HC4040 hatte ich ganz übersehen. Die Eignung als LCD
Controller bezweifle ich mit der Schaltung etwas. Spricht etwas gegen
einen LPC213x/01 ? Der hat 64 Pins, so dass man den Speicher komplett
anschließen könnte.

Bin immernoch am Überlegen ob der XC9572XL reicht. IO Pins hat er
definitiv zuwenig, aber wenn man 2 8Bit Latches an die Adressleitungen
vom Ram hängt, könnte es klappen (Pins reichen dann). Die 16 FF da
drinnen ersparen sicherlich auch einige Makrozellen.

Hi,
zwischenzeitlich sind einige Displays auch bei mir angekommen.

@Benedikt K.
>Es müssten 2mm sein

richtig, ich hab mal eine Buchsenleiste RM 2,0mm raufgesteckt.
Wer also schnell arbeitsfähig sein will, vom C....

@chris
wenn ich mir eine Bemerkung zum Board erlauben dürfte:
mir würde schon ein Board mit LPC , SRam, Adresszähler reichen
Steckbar mit Platinenverbinder auf RM2,54mm, auf Mutterboard o.ä.
Vielleicht gibt es ja mal 2 Varianten.

Wigbert

Wigbert Picht wrote:

>>Es müssten 2mm sein
>
> richtig, ich hab mal eine Buchsenleiste RM 2,0mm raufgesteckt.
> Wer also schnell arbeitsfähig sein will, vom C....

Noch einfacher und billiger geht es so:
http://www.mikrocontroller.net/attachment/35622/ec...
Einfach ein Kabel anlöten.

> @chris
> wenn ich mir eine Bemerkung zum Board erlauben dürfte:
> mir würde schon ein Board mit LPC , SRam, Adresszähler reichen
> Steckbar mit Platinenverbinder auf RM2,54mm, auf Mutterboard o.ä.
> Vielleicht gibt es ja mal 2 Varianten.

Das hatte ich ihm auch schon vorgeschlagen: Einfach ein Low Cost Header
Board mit einem LPC210x oder 213x/01 auf 2,54mm mit Spannungsregler,
Resettaster, Programmierinterface (also UART) usw. Also nur das nötigste
drauf und das ganze möglich billig.

@Benedikt
>Noch einfacher und billiger geht es so:

ich weiss das Du das kannst, ich sicher auch
aber ein Schüler, Bastler mit wenig Löterfahrung...
wäre schade um das Display.

Ich dachte, beim Board daran, es speziell fürs GLCD auszulegen,
also, wie Du erwäntest, nur das Notwendigste, für die "Displayanzeige".
Es sollte für mich nicht zum Experimentierboard ausarten.

Wigbert

Jo, das mag schon sinnvoll sein. Aber es sollte diese Rolle immerhin
auch übernehmen können. Man sollte also neben der effektiven
Hauptaufgabe, dem Videorefresh, auch im Auge behalten, dass die Daten
irgendwie ins RAM rein müssen.

Mit einem einfachen Adresszähler geht das zwar auch, aber entweder sieht
das dann aus wie beim Sinclai ZX80, der jedesmal wenn er Arbeit hatte
den Bildschirm abschaltete, oder es ähnelt der Aufgabe, wie bei der IBM
650 Trommelspeicher als RAM zu verwenden (wobei sich die immerhin
schneller drehte).

Mitbastler wrote:
> Schade, inzwischen sind die Displays ausverkauft.

Dann wird´s nun nicht mehr lange dauern und die, die diesen Beitrag
nicht kennen, werden ihr Display wieder in der Bucht verhökern
(hoffentlich habe sie´s nicht vorher kaputtgebastelt). Also einfach nur
abwarten, kommt bestimmt!

Inzwischen bin ich auch zu der Erkentnis gekommen, dass der XC9572 nicht
reicht. Das Problem ist, dass einige der kombinatorischen Funktionen so
komplex sind, das sie nimmer in eine Makrozelle passen.

Bei Farnel gibt's aber für 6€ einen Altera Max mit 240LE. Damit müsste
sich ein effizientes Interface realisieren lassen.

Hallo,
habe ein Thread gestartet bez. reinem ARM Platine,
Beitrag "Stamp ARM modul"
Dies ist eine 24dip Platine, wer eventuell ein M416 design will
40 pin Version ohne leds, ohne i2c oder SPI speicher, dafür
aber alle pins herausgeholt, kann auch so eines bekommen.

mift - Pollin hat mir kein Display mitgeliefert, ausverkauft :-( ...
falls jemand eines übrig hat, oder zwei, hätte ich diese gerne damit die
Platine dann auch einen Sinn hat ...
LG Vajk

Bernhard wrote:
> sag mal, wie erzeugst du die graustufen?

In diesem Fall war es einfach: Ich habe das Display an einen S1D13506
LCD Controller angeschlossen. Da dieser nur 1024x1024 max kann, ist eben
nur die obere Displayhälfte angeschlossen (für die untere Hälfte beim
4bit Interface wären 1440x200 notwendig).

> Also schon klar indem du dunklepixel länger anzeigst als helle,
> aber wie genau?

Wie der Controller das genau macht, versuche ich auch schon seit
längerem herauszufinden. Vermutlich mit einer geschickten Verteilung der
aktiven Pixel über mehrere Frames. Wenn man das mit der simplen PWM
Logik macht, also den PWM Zähler in jedem Frame erhöht und nur dann ein
Pixel einschaltet, wenn der Pixelwert größer als der Zähler ist, dann
flimmert es ziemlich bei 70Hz und 16 Graustufen.

> also meine überlegungen, einen count speicher der die anzeige dauer für
> jedes pixel hat,
> aber dann bräuchte man ja doppelt so viel speicher...

In diesem Fall waren es sogar der 4 fache, da 4Bit pro Pixel.

Hallo Ale
> sind 10 Euronen, bei Sander etwa 18. Ich habe eine für ein 640x480 LCD
> (benutzt als 320x240) ohne Probleme :-), aber sind hoch getaktet um 80
> MHz (20 MIPS pro COG, aber mit nur eine passt ganz gut im 2k).
könntest Du Schaltung und Code zur Verfügung stellen? GGF. via PN? Was
für Displays passen dran, Screenshot/Foto?
liebe Dank
Vajk

Bei Graustufen reagieren LCDs deutlich langsamer als bei schwarz-weiß
wechseln. Vielleicht flimmert es desswegen nicht.

Bernhard wrote:
> hm, die idee ist mir auch gekommen,
> wie hast du den zähler gehandhabt?

Bei bis zu 4 Graustufen (also 2bpp) mache ich das genauso, also den
Zähler in jeder Frame um 1 erhöhen. Um Rechenleistung zu sparen,
erstelle ich manchmal aber auch 2 getrennte Bilder mit je 1bpp und
schalte zwischen beiden um. Das erste wird 1 Frame lang angezeigt, das
zweite 2 Frames.
Farbe 0 führt zu einer 0 bei beiden Bildern, Farbe 1 zu einer 1 im
ersten Bild, Farbe 3 zu einer 1 im zweiten Bild und Farbe 3 zu einer 1
bei beiden. Das ist vom Speicher her bei 2bpp genauso aufwendig.
Bei mehr Farben ist der Vergleich des Farbenwerts mit dem PWM Counter in
jedem Pixel besser.

Das einzige mal das ich wirklich viele Graustufen selbst erzeugt habe,
war ein TV->LCD Converter mit einem CPLD. Da habe ich etwas mit den
verschiedenen Tricks gespielt, um die Framerate hoch zu halten.
Die reine PWM Technik führt selbst bei 8 Graustufen zu einem stark
flackernden Bild. Von daher wird zum PWM Zähler noch die Zeilenanzahl
addiert, so dass nie größere Flächen gleichzeitig aufleuchten, sondern
dass die Flächen über meherere Frames verteilt sind. Dadurch wird das
Flackern stark vermindert. Allerdings führt dies nun zu einer
wellenförmigen Bewegung auf dem Display also auch nicht ganz OK.
Wenn man die Zeilen willkührlich verteilt ansteuert wird es etwas
besser, allerdings geht der Kontrast etwas zurück, und das Übersprechen
und andere Störerscheinungen werden stärker.
Am Ende habe ich einen Kompromiss aus Bildqualität und Framerate gewählt
und mittels Dithering 64 Graustufen erzeugt.
Richtige LCD Controller scheinen die PWM Werte über Zeilen und Spalten
zu verteilen. Zumindest sieht man bei niedrigen Framerrates eine
Gitterförmige Wellenbewegung (also senkrechte und waagrechte Wellen).

I_ H. wrote:
> Bei Graustufen reagieren LCDs deutlich langsamer als bei schwarz-weiß
> wechseln. Vielleicht flimmert es desswegen nicht.

Nein, die Reaktionszeit bleibt gleich. Dieser Eindruck entsteht eben
durch diese PWM Ansteuerung. Wenn sich Objekte Bewegen, kann es sein,
dass je nach Position und PWM Zähler unterschiedliche Helligkeiten
dargestellt werden (obwohl doe Objekte gleich hell sind), was dann zu
einer verstärkten Bewegungsunschärfe führt.

Bernhard wrote:

> das könnte man durch "tricks" kompensieren, indem man das pixel eben
> nicht erst 1/4 und dann die restlichen 3/4 aus lässt sondern z.b. erst
> 1/8 an, dann 2/8 aus, dann wieder 1/8 an usw.

In der Theorie ja, in der Praxis aber nicht.
Anstelle von 70Hz/4=17,5Hz hätte man dann 70Hz/8=8,75Hz das würde noch
mehr flackern.
Außerdem hätte man dann viel mehr Pegeländerungen an den LCD Pixeln. Das
versaut einem den Kontrast und zwar extremst.
Funktioniert also nicht.

Bernhard wrote:
>> Anstelle von 70Hz/4=17,5Hz hätte man dann 70Hz/8=8,75Hz das würde noch
> mehr flackern.
>
> nein, man hätte  70Hz/8 mal 2  = ebenfalls 17,5Hz da man zwei 1/8 high
> zeiten hat,
> sprich die 1/4 high zeit, aufteilen was auf einen gesamten 70Hz zyklus
> des LCD wieder 1/4 leuchtende pixel dauer ergibt

Das problem ist aber, die kürzeste Zeitdauer die erreichbar ist, ist
1/70Hz. Wenn du die jetzt durch 8 teilst, bist du eben bei 1/8.

> sollten die pixel allerdings träge sein, dann ok, dann wird man da
> probleme bekommen

Woran das genau liegt weiß ich nicht, aber ich hatte dies schonmal
probiert. Vermutlich liegt das daran, dass die Kennlinie des LCDs alles
andere als linear ist, und wenn der Pixel häufiger den Zustand wechselt,
dann erreicht man bei etlichen LCDs nicht unbedingt die Farbe die man
haben möchte.

Achso, so meinst du das. Das führt dann aber genau zu dem zweiten
Problem das ich beschrieben habe. Graustufen sind leider alles andere
als einfach.

Tach zusammen,

wie ist denn der derzeitige aktuelle Status zum Thema G-LCD bei Pollin?

Ich meine nun weniger die Tatsache, daß Pollin leider keins mehr hat,
als vielmehr die Überlegungen einzelner Forenmitglieder für das Display
eine passende Schaltung/Platine zu entwickeln (was ich persönlich sehr
begrüßen würde)?

Ob sich das noch lohnt?

Es scheint ja nur wenige Leute zu geben, die tatsächlich Displays
bekommen haben. Auch bei mir waren keine drin. Entweder hatte Pollin nur
eine Handvoll davon, oder jemand hat die Dinger waggonweise gekauft -
vielleicht tauchen sie dann in ein paar Wochen häppchenweise in ebay
wieder auf.

Wenn man dem Trick mit der Eingabe einer hohen Stückzahl glauben kann,
dann hatte Pollin nur rund 100 Stück davon. Also nicht wirklich viel.

Ich werde vermutlich bei der Lösung mit dem S1D13305 bleiben. Ich habe
zwar auch noch eine Schaltung mit einem AVR + etwas Logik die dank DDR
beide Displayhälften parallel läd, aber hier ist das Timing ziemlich
kritisch.

Also wenn ich mir die Grösse des Displays anschaue wäre das für ein
Panoramaempfänger o.ä. ideal.

Benedikt, mit AVR und Logik, wäre wohl, auch wenn ein grösserer
Aufwand notwendig, für mich zumindest ,einfacher zu beherrschen.

Aber von wem will mann schon Entwicklungsaufwand erwarten, wenn
die Stückzahl so gering....

Schade, aber was solls.

Wigbert

Hallo Benedikt,

Benedikt K. wrote:

> Ich werde vermutlich bei der Lösung mit dem S1D13305 bleiben.

magst Du uns dazu eventuell mal die erforderlichen Details
preisgeben/verfügbar machen? Ganz herzlichen Dank im voraus.

Klaus R. wrote:

>> Ich werde vermutlich bei der Lösung mit dem S1D13305 bleiben.
>
> magst Du uns dazu eventuell mal die erforderlichen Details
> preisgeben/verfügbar machen? Ganz herzlichen Dank im voraus.

Ich dachte das hätte ich schon geschrieben ?
Beitrag "G-LCD bei Pollin"
Beitrag "G-LCD bei Pollin"
Beitrag "G-LCD bei Pollin"

Was möchtest du denn noch wissen ?

Hallo Benedikt,

ganz herzlichen Dank für die schnelle RÜckantwort.

Benedikt K. wrote:

> ... Ich werde vermutlich bei der Lösung mit dem S1D13305 bleiben...

und aus Beitrag:
> ... Beitrag "G-LCD bei Pollin" ...

die Passage
> ... Auf die Rückseite der Platine habe ich eine Platine mit einem S1D13305
LCD Controller und 64kByte SRAM geklebt.

> Was möchtest du denn noch wissen ?

Gibt es dazu einen Schaltplan? Oder kann man bei Dir gar eine
entsprechende Platine käuflich erwerben (sah auf dem Foto so aus).
AVR-Programmieren bekomme ich dann selbst hin.

Oder habe ich eventuell doch noch etwas übersehen?

Klaus R. wrote:

> Gibt es dazu einen Schaltplan?

Habe ich angehängt, müsste so passen.
Das einzige Problem an der Schaltung ist, dass man den Controller um
rund 50% übertakten muss, damit er die Daten ausreichend schnell
liefert.

Hallo Benedikt,

ganz herzlichen Dank für den Schaltplan. Sobald ich mal wieder Zeit für
Selbstbauprojekte habe, werde ich mir dazu die passende Platine feilen
und das Display endlich in Gebrauch nehmen. Nochmals Danke für die
ganzen Details die Du und einige andere zu dem Pollin-Display
herausgefunden haben. Schade nur, daß Pollin nur so wenige von den
Dingern hatte. Na ja, man kann nicht immer gewinnen.

Hi Leute!

Was könnt ihr zum SANYO LM-FH33-22NEK sagen? Ebenfalls bei Pollin unter
Best.Nr. 120 479.

Die Auflösung ist etwas hoch, mir würden 640x480 reichen.

Ein Controller ist da wohl nicht dabei, oder? Welcher Controller könnte
das Display ansteuern? Ich möchte natürlich die ganze Auflösung nutzen
und wenigstems vie Helligkeitsstufen pro Farbkanal haben. Internen
Pixelspeicher muss der Controller auch haben.

Sind die Kontakte für den Controller rausgeführt/lötbar?

Ergänzen wir die Frage, wo gibts ein preiswertes Grafikdisplay mit
Controller oder "leicht" ansteuerbar mit ner Anzeigefläche von ca.
50mmx80mm ? Die Dinger bei Tante R sind n Tick zu teuer :-)

Hmm - VGA oder 800x600 Farbdisplays mit
Zigarettenschachtel-Zwergdisplays in einen Topf schmeissen?

Ein solches Zwergdisplay in 320x240 monochrom bietet Pollin für 8€, von
Sharp, für das einerseits Pollin selbst eine Ansteuerung auf Basis FPGA
beschreibt, aber auch Benedikt eine Lösung gefunden hat. Anschluss für
0,5mm Folienkabel. Und ein bischen Analogzirkus ist nötig für ein paar
separate Spannungen.

Ab ca. 15€ gibts solche Dinger in 128x64 oder 128x240 direkt aus China
mit oder ohne ebay, teilweise auch mit Touchscreen. Die sind dann
inklusive Controller und problemlos parallel anschliessbar, ähnlich den
HD44780 Textdisplays im 8bit Modus.

Maxim S. wrote:
> Ein Controller ist da wohl nicht dabei, oder?

Nein, braucht man extern.

> Welcher Controller könnte das Display ansteuern?

Solch einer:
Beitrag "[S] Leute die eine "Grafikkarte" für uC bauen wollen"

Bei diesem hier steht: "8-Bit Datenbus". Also hat er einen Controller?

Citizen G6481L-FF
http://www.pollin.de/shop/detail.php?pg=OA==&a=MDU...

Maxim S. wrote:
> Bei diesem hier steht: "8-Bit Datenbus". Also hat er einen Controller?

Nein. Es dürfte nur ein Dualscan Display mit 2x 4bit sein. Die Infos bei
Pollin sind oft etwas ungenau. Die 16 Graustufen stimmen eigentlich auch
nicht. Das Display selbst kann nur an und aus.

Hallo Leute,

Das GLCD ist bei Pollin unter 120 248 wieder zu finden.

Wigbert

Aber nicht lange, es sind nur noch 17Stk da...
Vor ein paar Tagen waren es noch >40.

Na ja, man gibt sowas erst bekannt wenn man seine schon hat.....

Wigbert

09.08.2008: Bestand: 0 (nach telefonischer Auskunft)
... und ich bin immer noch nicht dazu gekommen den Schaltplan von
Benedikt endlich mal zu verEaglen.

Nun, da das Schneefegen wohl ein Ende hat,
wollte ich die Ansteuerung meiner GLCD's versuchen.
@all
hat denn jemand die Displayansteuerung nachgebaut,
evtl. Platine geroutet?

@Benedikt K.
bevor ich Deine Schaltung route:
http://www.mikrocontroller.net/attachment/36494/s1...
Ich hab haufenweise S-Rams CXK58257M-10L (32Kx8)
könnte ich da 2 Stück "Huckepack" nehmen, oder wäre das zu aufwendig.
Ich hätte auch ein 64Kx16 könnte der gehen?
Du hast auf Deine Platine ein IC rechts oben (6Pins)
http://www.mikrocontroller.net/attachment/35622/ec...
benutzt Du den für die -19,5V Erzeugung?

Wigbert

Wigbert Picht-dl1atw wrote:
> bevor ich Deine Schaltung route:
> http://www.mikrocontroller.net/attachment/36494/s1...
> Ich hab haufenweise S-Rams CXK58257M-10L (32Kx8)
> könnte ich da 2 Stück "Huckepack" nehmen, oder wäre das zu aufwendig.

Es sollte funktionieren. Allerdings muss man dann die CS\ Leitungen
mittels ein paar NAND oder NOR Gatter entsprechend mit der A15 Leitung
verschalten, so dass je nach A15 das eine oder andere SRAM ausgewählt
wird.
Ich würde da einen 128kByte SRAM verwenden, den gibts bei Reichelt
ziemlich günstig.

> Ich hätte auch ein 64Kx16 könnte der gehen?

Sollte auch gehen. Die restlichen Pins würde ich dann über Pullups an 5V
legen.

> Du hast auf Deine Platine ein IC rechts oben (6Pins)
> http://www.mikrocontroller.net/attachment/35622/ec...
> benutzt Du den für die -19,5V Erzeugung?

Zur Erzeugung nicht, aber zum Schalten: Das ist ein Optomosfet, der an
YDIS hängt. Nur wenn YDIS high ist, wird die Displayspannung
durchgeschaltet.
3 Transistoren erfüllen den selben Zweck, sind halt nur mehr Bauteile zu
bestücken.

@Benedikt K.
ging das schnell,
bei Reichelt die 128Kx8 hätten 70ns, das stellt kein Problem dar?
Schönen Sonntag noch.

Wigbert

Das sollte kein Problem sein, der 13305 lässt dem Speicher fast 2 Takte
Zeit. 2 Takte sind rund 125ns. Selbst ein 100ns SRAM sollte bei 16MHz
noch gerade so funktionieren.

Picht wrote:
> Die von Benedikt mehrfach verwendeten Optomosfet's AQV257 scheinen ideal
> zu sein. Wenn ich das DBL richtig lese, ca 1mA Steuerstrom bei ca.1,14V.

Ja, die Dinger sind für Gleichspannungen und niederfrequente
Wechselspannung ein idealer Low Power Relaisersatz bei kleinen Strömen.

> Sind in etwa für 2 Euro beschaffbar.

Ja, die Teile sind leider schweineteuer. Keine Ahnung wieso. Bei Pollin
gabs die für 25cent.

> Wieso ist bei Dir der LED-Rv bei 5V nur 330 Ohm gross,

Für ein sicheres Schalter schreibt das Datenblatt mindestens 3mA vor.
Die Spezifikationen im Datenblatt sind bei 5mA angegeben. Ich habe 330
Ohm Widerstände in großen Mengen, daher ist das mein Standardtyp für
alles was mit LEDs zu tun hat.

> was macht der 47K

Den hast du aus der Schaltung vom 320x240 LCD, oder?
Da ist er dafür da, damit der ONOFF Pin vom LCD sicher auf GND liegt,
wenn der µC im Reset ist und kein Optomosfet verwendet wird (was z.B.
beim NAN YA LCD unnötig ist, da es auf dem Modul über abschaltbare ICs
verfügt).
Hier ist der Widerstand unnötig.

> Verwendest Du für den Takt nur ein 16Mhz Quarz, im DBL sind noch
> Kondensatoren eingezeichnet.

Ja, die fehlen. Sowie die ganzen anderen 100nF Cs.
Eigentlich verkraftet das IC nur 10MHz, 16MHz laufen bei mir aber noch
stabil bei 5V. Erst ab etwa 20MHz gibt es Aussetzer.

@Benedikt
Sorry, das ich hier Dein einzigster Fan bin. Ich weiss auch nicht
wo die Dinger alle geblieben sind.
aber bei Controller > 10 Euro sollte letzendlich die Hardware
keine Macken mehr haben.

>Ja, die Teile sind leider schweineteuer
Ich hab versucht bei Panasonc die Optomosfet's direkt zu kaufen, nicht
wesentlich besser und hohe Mindestabnahme.

>Den hast du aus der Schaltung vom 320x240 LCD, oder?
Die Optomos-Sch. hatte ich wirklich vom 320x240 GLCD

>Ja, die fehlen.
Dann werd ich mal die C's noch einarbeiten.

Wigbert

Hallo Wigbert,
Du bist nicht alleine. Ich habe nur leider immer noch nicht die Zeit
gefunden mich des Themas mal wieder anzunehmen, werde aber ganz bestimmt
zu den ersten gehören, die das, was auch immer Du eventuell daraus
machst gerne ausprobieren werden (habe zwar nur ein Display, aber das
reicht mir auch).

vy 73 de Klaus

@Klaus R. (ruebi)
na prima,

das Projekt entwickelt sich langsam.

Auch die Optomosfet's sind wohl geklärt. Ich liege da jetzt bei ca.
1,25 Euro/Stück.Preislich zwar nicht so gut wie Pollin mal war, aber
wesentlich besser als C. usw. Und es wäre egal, ob ich SMD oder DIP
nehme.
Es wird wohl wieder auf eine Sammelbestellung hinauslaufen.

Wigbert

Wigbert Picht-dl1atw wrote:
> ...
> Es wird wohl wieder auf eine Sammelbestellung hinauslaufen.

Da bin ich gerne dabei.

Gruß,

Klaus

Hi,

die S1D13305 sind wieder beschaffbar. Seltsamerweise nun sogar
den A(Rechteckig) und B(Quadratisch). Auch meine Optomosfets sind
für das Projekt eingetroffen.
Das wäre erstmal wieder geschafft.
Wenn das Board fertig ist, gibt es eine Linkliste.


Wigbert

@Benedikt

könnte es sein, das Dein Bild
http://www.mikrocontroller.net/attachment/35622/ec...
mit der Schaltung nicht übereinstimmt.
http://www.mikrocontroller.net/attachment/36494/s1...

ich hab da zwischen S-Ram(Reichelt) und S1D13305F00B
bei den Datenleitungen Kreuzungen drin.

Wigbert

Die Adress und Datenleitungen kannst du jeweils beliebig untereinander
tauschen, denn wenn die Daten falsch rum reingeschrieben werden, werden
sie auch genauso falsch rum wieder ausgelesen, so dass wieder das
richtige rauskommt.

@Benedikt
>Die Adress und Datenleitungen kannst du jeweils beliebig untereinander
>tauschen,

hmm, hört sich bei Dir so einfach an.

Damit ich es richtig verstehe:
Adressleitung sind doch A0-A16. Daten O0-O7.
Muss jetzt immer zB.A7 zu 07 zugeordnet bleiben?
Ich bin mir da nicht sicher.

Dank Dir aber für die Hilfe mal schon.

Wigbert

Du kannst z.B. O0 vom SRAM an VD7 vom 13305 anschließen wenn es vom
Layout besser ist, oder A0 an A2, A3 an A5 usw.
Nur A und Os darfst du nicht tauschen.

Na ja A's und O's wollte ich nicht untereinander tauschen.
Es spielt also keine Rolle, wenn ich die O's in Ruhe lasse,
welche A's von S-Ram an welchen A's des S1D13305 gehen.
Aber wenn ich die O's auch noch mit den VD's vertauschen würde
gäbe es Probleme?

hmm, ist das heute schwierig.

Wigbert

Wigbert Picht-dl1atw wrote:

> Aber wenn ich die O's auch noch mit den VD's vertauschen würde
> gäbe es Probleme?

Nein.
Die Bits werden dann durcheinander in den Speicher geschrieben, aber am
ende auch wieder durcheinander zurück gelesen, so dass es wieder passt.

Hi,
zwischenzeitlich wurde schon fleissig geroutet.
Ich habe bewusst eine einseitige Platine entwofen, um ein Nachbau
zu vereinfachen. Hat aber seinen Preis. Im Moment sind noch 7 Brücken zu
bestücken. Auch an-und abgehendes Flachbandkabel wird mit
Flachband-IC-Sockel angeschlossen.
Die SMD-IC's nicht zu eng geroutet, um ein ordentliches
Löten zu ermöglichen.
Die Platine hat jetzt eine Grösse von 70mmx50mm. Noch mal alles
überprüfen, und stelle dann die Preise demnächst hier rein.


Wigbert

Hi,

anbei mal die Schaltung. Zwischenzeitlich wurden einige Hinweise von
Benedikt, nochmals herzlichen Dank dafür, mit eingebaut.
Die neg. Kontrastspannung ist jetzt mit on Board. Ursprünglich war ich
der Meinung ein Kontrast mit Hilfe eines PWM-Signals wäre sehr Hilfreich
(Tageslichtanpassung) und habe deshalb mal 2 Varianten(PWM; Poti) hier
zur Disskussion reingestellt. Ich weiss nicht, ob bei dem Display
PWM sinnvoll ist.
Etwas Schnickschnack, genaugenommen eine LED-Anzeige der
Spannungsversorgung ist mit zugekommen.
Na ja, muss ja nicht bestückt werden.
Platinengrösse bleibt, wie bisher.

Wigbert

28 downloads: Da scheint ja wohl doch noch Interesse an einer passenden
Platine zu sein. Ich bin sicherlich dabei.

Hi,
ich hab jetzt noch den Bus beschriftet.

Das ganze Teil, also Bauteile und Board sollte für 25 Euro machbar sein.
Das ist meines Wissens auch verträglich, ich habe S1D13305 Board's für
35 Euro/ 50 Dollar schon gesehen.

Ich hab den Contrast mit PWM vorgesehen, sollte eine Ansteuerung
mit Poti erfolgen, einfach 2 Bauteile weglassen.
Ich denke mal, in einer Woche kann ich ein Prototyp-Bild reinstellen

Wigbert

Ja,
bei geringen Stückzahlen ca.< 10 würde ich Platinen vom
"Platinenbelichter" (Verzinnt gebohrt Lötlack, aber kein Lötstplack)
machen lassen.
Bei grösseren Stückzahlen würden sich die Werkzeugkosten tragen
und es könnten dann einige Platinen im Ausland gefertigt werden.
Den S1D13305 gibt es noch, schon wieder bei "Darius" , "LCD Design".

Da ich sowieso eine andere Sammelbestellung organisiere,
würde ich ein Komplettbausatz zusammenstellen, mit Kabel, Stecker usw..
Versandkosten können dann jedenfalls eingespart werden,
da alles aus einer Quelle kommt.

Nur, will ich vorher aber den Prototyp bei mir laufen sehen.

Wigbert

@Benedikt

ich hab mein Display mal schon umgebaut.

Wenn ich jetzt 5V und -19,5V Kontrast anlege, habe ich oben
und in der Mitte ein dünnen dunklen horizontalen Streifen.
Gut das Bild besteht aus oberer und unterer Hälfte, aber woher
kommen die Linie ohne Ansteuerung her.

Wigbert

@Benedikt, Wigbert  kann man auch die Display ( dann und wie ) LCD Modul
NAN YA LTBE9S159J1K und LCD-Modul NAN YA LTBE9T372G1K am Epson
anschliessen?

Wigbert Picht-dl1atw wrote:
> Gut das Bild besteht aus oberer und unterer Hälfte, aber woher
> kommen die Linie ohne Ansteuerung her.

Aus zufälligen Werten die im Zeilenschieberegister stehen. Daher ist
eine der Zeilen zufällig aktiv. Das ist normal.

Avr Nix wrote:
> @Benedikt, Wigbert  kann man auch die Display ( dann und wie ) LCD Modul
> NAN YA LTBE9S159J1K und LCD-Modul NAN YA LTBE9T372G1K am Epson
> anschliessen?

Ja, kann man. Die Belegung ist unterschiedlich, und die Initialisierung
des 13305 muss etwas angepasst werden, aber es geht.

@Benedikt

Seite17 DBL S1D13305
wäre
YD = Frame Start/links oben wieder anfangen
WF = brauchen wir nicht
LP = Zeilentakt, eine Zeile weiter
XSCL = Takt für D0-D3 in Zeile
sieht aus, als ob bei fallender Flanke gespeichert wird.
XDO..XD3 steht in der Zeile(1)....(16)
da bin ich mir nicht sicher, wenn ich D0-D3 auf Hi setze, werden da
nicht 4 Pixel schwarz in der Zeile geschrieben, und dann weiter so?

Wigbert

Wigbert Picht-dl1atw wrote:
> LP = Zeilentakt, eine Zeile weiter
Zusätzlich werden die Daten aus dem Schieberegister an das Display
ausgegeben.

> XSCL = Takt für D0-D3 in Zeile
> sieht aus, als ob bei fallender Flanke gespeichert wird.

Ja, wobei ich nicht gespeichert sondern ins Schieberegister geschoben
sagen würde.

> XDO..XD3 steht in der Zeile(1)....(16)
> da bin ich mir nicht sicher, wenn ich D0-D3 auf Hi setze, werden da
> nicht 4 Pixel schwarz in der Zeile geschrieben, und dann weiter so?

Ich verstehe jetzt nicht ganz worauf du hinaus willst. XD0-3 sind ganz
einfach die Daten die nach und nach ans Display übertragen werden. Eine
1 bedeutet dabei ein aktiver Pixel. Im Beispiel im Datenblatt werden
16x4Bits=64Bits=64Pixel pro Zeile übertragen.

Ich meinte, ob immer von Links nach rechts
D0,D1,D2,D3,D0,D1,D2,D3.... geschrieben wird. Also kein vertauschen.

Wigbert

Umgedreht:
Pixel 1,2,3,4,5,6,7,8,9,10 usw. sind D3,D2,D1,D0,D3,D2,D1,D0,D3,D2 usw.

hmm,
da steht aber im DBL XD0 to XD3 jetzt dachte ich...
Ist das immer so oder steht das auch im DBL


Wigbert

Hi,

ich hab jetzt meine Platine von "Platinenbelichter" bekommen.
Leiterzüge sind Top ausgeführt.
Was mir persönlich nicht gefällt, sind Kratzer auf der Bestückungsseite
und der fehlende Lötstopplack wird zu Schwierigkeiten beim Löten führen.
Aber als Prototyp mag sie gehen.

@Benedikt
ich wollte in LCD-Hype schon mal den Epson S1D13305 einrichten.
Sollte ja wohl gehen. Wenn ich aber 1440 x 200 Pixel einstelle, meckert
das Programm: Speicher zu klein. Gibt es da ein Trick?

Wigbert

Wigbert Picht-dl1atw wrote:

> ich wollte in LCD-Hype schon mal den Epson S1D13305 einrichten.
> Sollte ja wohl gehen. Wenn ich aber 1440 x 200 Pixel einstelle, meckert
> das Programm: Speicher zu klein. Gibt es da ein Trick?

Leider nicht. Das Programm kann nur 320x240. Man müsste einen eigenen
Treiber dafür schreiben und sehr viel Tricksen, damit es geht. Ich habe
schonmal ein 640x480 Display damit angesteuert indem ich nacheinander 4x
320x240 Screens angezeigt habe. Dies muss der Treiber allerdings
steuern.

@Benedikt

Dank Dir.
Ich wollte nur die Hardware(Platine) testen.
Nun muss ich doch fragen: Ein Testprogramm für das Display für einen
m8 hättest Du nicht zufällig in der Schublade? Die Hexdatei würde
reichen.

Wigbert

Wigbert Picht-dl1atw wrote:

> Nun muss ich doch fragen: Ein Testprogramm für das Display für einen
> m8 hättest Du nicht zufällig in der Schublade? Die Hexdatei würde
> reichen.

Fast. Für einen pinkompatiblen mega168 habe ich etwas.
Belegung:
D0-8  PORTD
WR  PORTC_5
CS  PORTB_7
A0  PORTB_6

RD liegt an 5V.

Es sollte dann "Reading Card... No Card !" auf dem LCD erscheinen.

@Benedikt

Dank Dir,
so kann ich mich schon mal auf den Code verlassen.

Wigbert

Hi,

die neg. Spannungserzeugung und das Optomos-Relay laufen schon mal.
Auch Bohrungen für Bestückung sind OK.
Links oben der MC... mit sein Zubehör für die Contrast-Spannung.
Rechts der AQV212. Bis auf das Displaykabel ist die Bestückungsseite
komplett. Da bis jetzt keine Kurzschlüsse aufgetreten sind,
kann ich die beiden IC's nun auflöten. Und dann wird es spannend...

Übrigens in der o.g. Schaltung fehlte noch der 22µF zwischen 19,5V und
GND

Wigbert

@Benedikt K. (benedikt)

Das Display hab ich angeschlossen.
Es wird bis auf eine Pixelzeile dunkel.
Lässt sich auch mit weniger als -19,5V (5,4mA) nicht heller stellen.
Aktivitäten sind auf den Ausgangsports.
Die Anschlüsse zur Sicherheit:
>Belegung:
>D0-8  PORTD
D0= PortD0
D1= PortD1
usw.
>WR  PORTC_5

>CS  PORTB_7
>A0  PORTB_6
das wäre eigentlich xtal trotzdem richtig?

>RD liegt an 5V.

was mach ich mit RES\ vom S1D13305

Wigbert

Wigbert Picht-dl1atw wrote:
> Die Anschlüsse zur Sicherheit:

>>CS  PORTB_7
>>A0  PORTB_6
> das wäre eigentlich xtal trotzdem richtig?

Ja. Takt ist interner 8MHz Oszillator.

>>RD liegt an 5V.
>
> was mach ich mit RES\ vom S1D13305

5V oder an einem RC Glied 10k gegen 5V, 100nF gegen GND als Power On
Reset.

@Benedikt K. (benedikt)

ich hab mal das Display abgezogen und Kommunikation Rein, zum Ram,
und zum Display ist da. LP(Pin37) hat keinen Takt auf den Oszi, dafür
aber
WF(Pin38) der nicht benutzt wird.
Wo kommt denn LP rein?

Wigbert

Lass mal den AVR weg, leg zumindest mal CS\ auf 5V, und zieh RES\ kurz
auf GND (falls dies nicht schon durch das oben beschriebene RC Glied
geschieht). Danach sollte der 13305 mit den Standardeinstellungen
laufen. Alle Signale (inkl. LP) sollten dann da sein.

Die Signale sind auch mit AVR da. LP ist eine ganz kleine Nadelspitze.
Ich glaub mein Problem ist der Konrast. Der müsste sich doch stellen
können, wenn ich die neg. Spannung verkleinere.

Wigbert

Mess mal die Frequenz von YD. Die sollte ganz grob bei etwa 50Hz liegen.
Falls ja, dann passt die Init vom AVR.
Das Problem dürfte dann an den Leitungen zum Display liegen (vor allem
LP und XSCL).

Ich hab bei YD ein Nadelimpuls alle 70ms.
Die Fusebit sind doch im Code mit drin?
Die Leitungen zum Display sind nur 5cm lang, nachgelötet ist auch alles,
hat auch niederohmigen Durchgang bis zum S1D...

Wigbert

Wigbert Picht-dl1atw wrote:
> Ich hab bei YD ein Nadelimpuls alle 70ms.

Klingt nach nicht initialisiertem 13305

> Die Fusebit sind doch im Code mit drin?

Nein.

Ich hab den Taktteiler im AVR rausgenommen, habe auch meine 20ms an
YD. aber immer noch dunkles Bild. Das beste wird wohl sein ein LA
mal ranzuhängen.

Wigbert

@Benedikt K. (benedikt)

die Geschichte lässt mir einfach keine Ruhe.
Ich hab dann wirklich den AVR raus und CS\ an 5V gelegt.
und dann mal meinen kleinen LA rangehangen.
Mir ist erstmal aufgefallen, das ich Res. trotz der 10k und 100n
kurz nach GND nehmen muss, das der S1D... startet.

Channel/ S1D..Pin

0 = LP
1 = XSCL
2 = YD
3 = OSC1

LP ist auf dem Oszi da, ich hab dann auch mal direkt am Controller
versucht. Bin mit dem Signal eigentlich nicht zufrieden. Welche Zeit
hätte denn LP. Stimmen denn soweit überhaupt die Zeiten.

Wigbert

Ich dachte du hättest 20ms an YD, auf der Messung sind es nämlich 37ms.

Sehe ich das richtig, dass LP dauerhaft auf high liegt?
Eigentlich sollte der fast immer auf Low liegen.

das wäre jetzt ohne AVR, also nur der S1D13305 wie dort beschrieben.

Beitrag "G-LCD bei Pollin"
(Standarteinstellung)
ich wollte erst mal wissen, ob mit dem S1D... alles in Ordnung ist.
Ja, der LA sagt high bei LP, irgendwie ist da Müll drauf.
Ich hab den MC... dann auch runtergenommen, also die Spule
kann beim Messen nicht einstreuen.

Mit AVR hatte ich dann 20ms... aber irgendwo muss ich ja anfangen zu
suchen.

Wigbert

LP muss mit einer Frequenz von 200x (bzw. 256x ohne AVR) der Frequenz
von YD kurz auf high gehen.
Ansonsten muss der low sein.

Mit LP schaue ich noch mal,
ansonten ist auch mit AVR alles da.
26ms messe ich genaugenommen an YD.

es müsste doch schon auf dem nicht umgebauten Display irgend etwas zu
sehen sein?

Wigbert

Ja. Vorausgesetzt LP arbeitet richtig.

LP wären dann Ca. 8-10 Khz. Ob Du mal sicherheitshalber
die nächsten Tage mal den Code in eine Zip legen kannst?
26ms wäre Ok?

Wigbert

also auf ein unverbasteltes Display ist auch kein Pixel zu sehen.
LP hat 0,1 Khz in etwa. Wird LP vom AVR erzeugt?

Wigbert

0,1kHz sind definitiv zu wenig. Bist du sicher dass du am richtigen Pin
misst?
Die Frequenz an LP muss ein Vielfaches von der Frequenz an YD sein,
nämlich genau mit dem Faktor Zeilenanzahl.

Ich weiss, es fehlt LP,
entweder der Code im AVR ist fehlerhaft, oder wenn LP intern im
S1D13305 erzeugt wird(alle anderen Takte sind ja da), hat der Controller
ne Macke. Ich dachte auch schon, es ist was vertauscht, XSCL hat ca 9
Khz.
Ich hab schon mehrmals geprüft, Display ist swieso ab und der MC.. ist
abgezogen. Init ist da , Takt ist da, nur der eine Pin nicht. Selbst
wenn ich D0-D3 vertauscht hätte, wären irgendwo Pixel zu sehen.

Bevor ich den S1D runterlöte, wollte ich alle anderen Fehler
ausschliessen.

Wigbert

Wenn LP auch ohne den AVR fehlt, dann hat wohl der 13305 ein Problem.
Mess mal an YSCL. Da müsste in etwa das gleiche rauskommen, nur
invertiert. Also im Ruhezustand high, die Impulse low.

alle 24,8ms ein Nadel nach Low.
Ich nehm mal alle Channel noch mal auf


Wigbert

Channel 7 wäre Pin 41,
sind aber viele Impuse drauf.

Wigbert

Bild noch

Die Frequenz von YSCL scheint um einiges höher zu sein als die von YD.
Das ist ok.
Ich tippe drauf, dass LP irgendwo einen Kurzschluss zu 5V hat. Ein
defekter Pin ist nämlich ziemlich selten (außer man schießt den internen
Transistor mit einer Überspannung kaputt)

in der Tat sind gegen 5V 40KOhm, mit ein bischen Glück sind das
Flussmittelreste.

Wigbert

40kOhm sollte der Ausgang problemlos auf Low ziehen können. Ich dachte
eher an sowas wie einen kompletten Kurzschluss.

also richtiger Kurzschluss ist nicht, wenn ich mal mit mein probieren
nicht an die -19,5V (Pin3) gekommen bin.
Könnte man nicht YSCL mit ein Negator nehmen, oder wären die
Nanosec.Verzögerung kritisch. Ich meine um die 10 Euro des S1D.. zu
retten.

Ich löte aber erstmal den Pin ab.

Wigbert

Ich habe es noch nicht ausprobiert und das Datenblatt ist an der Stelle
nicht wirklich detailliert was das Timing angeht, aber es sollte
vermutlich funktionieren.

ein Transistor mit Pullup wäre der zu langsam?

Wigbert

Ich sag jetzt einfach mal ja. Es könnte sein, dass es geht, aber mir
wäre das zu unsicher. Immerhin ist der Impuls nur wenige 100ns lang.

@Benedikt K. (benedikt)

ich hab das mal mit ein 74HCT 04 ausprobiert.
Die Pegel werden invertiert.

Von der Sache her läuft aber der S1D.. instabil.
Ich hatte schon mehrehre Pixelzeilen "Morsezeiche" drauf, was darauf
hindeutet das das Display den Eingriff überstanden hat.
Es waren glaub ich 4 Zeilen aber in Abständen.
LP hat auf den Bild wenig Takte, oder der LA nimmt nicht die
Nadelspitzen
Ich hab für den 16 Mhz Quarz 22p drauf, könnte es sein, das der schwer
anschwingt?


Ch0 = YSCL
Ch1 = HC04
Ch2-5 = D0-D3
Ch6 = YD
Ch7 = XSCL

Interessante Sache.

Wigbert

Es könnte sein, dass sich der 13305 mit dem 16MHz Quarz etwas schwer
tut. Laut Datenblatt ist er ja nur bis 10MHz Spezifiziert. Da hilft nur
ausprobieren.
Bei mir lief er bis fast 20MHz, mit 22MHz ging dann endgültig nichts
mehr.

Wird denn was sinnvolles auf dem Display angezeigt?

@Benedikt K. (benedikt)

Ich hab jetzt alles neu verdrahtet und mit mein "Flagschiff" gemessen.
Ich war da bis 10ns runter.
Init ohne AVR
Beitrag "miniLa Software"

dann den AVR dran, und siehe da es fehlt LP
Der Quarz hat eine Periode von 60ns > also ca 16 Mhz (Channel 8)
Channel 1( invers YSCL)
Channel 2 XSCL
Channel 3 YD
Channel 4-7 Do-D3

Der AVR ist angeschlossen +5V VCC ;AVCC
                          GND Pin 8; 22
und die Datenleitungen natürlich, mehr nicht

da ja alle Steuersignale vorhanden sind, ohne AVR und CS\ an 5V,
würde ich auf Init tippen, aber da der Quarz mit AVR schwingt (Bild)
bin ich mir nicht sicher

ab und zu geht es mal, dann wie gesagt die Morsezeichen,
also Dein Text in Scheiben geschnitten, drauf.

Wigbert

so etwas profanes wie vertauschte Datenleitungen können es aber nicht
sein?
Könnte ja sein, dass Benedikt von D1-D4 spricht (weil er in seinem
Programm an D1 sonst was angeschlossen hatte) und Wigbert von D0-D3.
Oder Benedikts Code kommt nicht bis zur LCD-Ausgaberoutine, weil bei
Wigbert ein nicht angeschlossener Taster (von dem Wigbert auch nix
weiss) nicht gedrückt ist. WIe sieht´s mit dem SRAM aus? Da gab´s doch
Diskussionen über dessen Datenleitungsgebrauch?

Nur so eine Idee

Die Software macht als erstes die Init des Displays, daran sollte es
eigentlich nicht liegen.
Ich hatte es auchmal, dass LP gefehlt hat, aber das lag an einem zu
großen horizontal total Bereich, aber das kann man hier ja ausschließen,
da bei mir die Software geht.
Ich habe trotzdem mal die Software angehängt. Von Interesse dürfte hier
nur die s1d13305.c sein.

Vertausche Datenleitungen zwischen AVR und 13305 halte ich für eher
unwahrscheinlich, denn grundsätzlich passt das timing ja.

Das einzige was ich mir noch vorstellen könnte, ist ein zu hoher Takt am
13305. Probier mal einen 10 oder 12MHz Quarz.

so mal zwischendurch,

ich hab jetzt an Res. des S1D 100K an +5V und eine Diode drüber,
100n nach GND.

Nun sind alle Takte aber keine Daten am Ausgang.

Also entweder sind die Ports mit den Takten, oder die Ports mit den
Daten OK.
Ich probier das heute noch mit 8 Mhz aus.

Spannende Kiste.

Wigbert

@Benedikt K. (benedikt)
ich hab jetzt mal die Datenleitung vom AVR D0-D7 gemessen, was mir
auffällt ist das D5 invertiert ist. Ich denke mal das ist richtig.

am Ausgang fehlt mir D0 und D1, wo könnte ich da zum S-Ram weitersuchen
Durchgeprüft sind alle Leitungen.

Wigbert

Hi,
der S1D.. läuft mit 16 Mhz. Genaugenommen, konnte ich den alten
nicht mehr retten.
So schön das auf den LA aussieht, habe ich immer noch Timingprobleme.
Es wird mit Benedikt's Code sowas wie ein Barcode übers Display
dargestellt.

Was ich eigentlich (noch)nicht verstehen, der Kontrast lässt sich
einstellen, noch einer Weile ist die Darstellung weg. Ich dachte
YDIS müsste auch mal auf Low gehen, hab aber immer ein High Signal
drauf.

Wigbert

YDIS geht z.B. auf Low wenn man Reset auf Low zieht, oder wenn man das
Display per Befehl abschaltet.
Die Signale sehen richtig aus, soweit ich das erkennen kann.

Der Kontrast lässt sich einstellen, mit der Spannung, verschwindet
aber langsam nach ein paar Sekunden, und die -19,5V steht.

Wigbert

Dann fehlt dem Display entweder das YD oder das LP Signal.

Kann ich die beiden Signale im Display verfolgen?
Ist das manchmal in der Nähe der neuen Drahtbrücke
am Steckkontakt des Displays liegen sie definitiv an.
Mein nicht geöffnetes Display sagt auch kein Ton.
Selbst bei Vertauschen der Datenleitung müsste was zu sehen sein.

Wigbert

Die Leitungen gehen alle über den HC245 zu den ICs. Da kann man sie
schön abgreifen.

Hi,

und so endet das, wenn man nie aufgibt.

@Benedikt Du hast ein Fehler in Deiner Zeichnung (GLCD-Anschlüsse)
drin.

Wigbert

Herzlichen Glückwunsch, Wigbert!

Ich hatte schon die ganze Zeit mit Dir mitgefiebert: Hoffentlich ist nix
kaputt gegangen! Hoffentlich!!!

Nochmals meinen Glückwunsch!

>Hoffentlich ist nixkaputt gegangen!
nichts, was ich nicht repariert bekomme

noch die Platinenseite, ein paar Sachen ändere ich noch, wie die
Spule wird versetzt und beim genauen hinschauen, kann man meine
Kreuzungen am GLCD-Stecker sehen, diese werden auf der Platine
korrigiert.

Wigbert

Hi,

bei > 10 Interessente an ein Bausatz/Platinen, ist das auch kein
Problem.
So schlimm aufzubauen, ist das auch gar nicht.

Wigbert

@Benedikt K. (benedikt)

ich hab jetzt ein Bascom-Code ausgegraben, und wollte den anpassen.

ich hätte noch ein paar Fragen zu Deiner Init:


da stehht unter SCROLL:
Screen 1 Adresse LSB 36000 (180x200)?
Screen 1 Adresse MSB

insgesamt 4 Adressen, warum?

Wobei, bei den Ram Adressen hast auch LSB, MSB

Bei Dein Code hab ich beobachtet, das das Display, Zeile für Zeile
gefüllt wird. Also nicht die 1. Obere, und dann die 1.Untere(1440
Pixel)?


Dank Dir mal schon.

Wigbert

Wigbert Picht-dl1atw wrote:

> da stehht unter SCROLL:
> Screen 1 Adresse LSB 36000 (180x200)?
> Screen 1 Adresse MSB
>
> insgesamt 4 Adressen, warum?

Der 13305 hat 4 Adressbereiche, ich verwende aber nur 2 davon: Einen für
Grafik und einen für Text.

> Bei Dein Code hab ich beobachtet, das das Display, Zeile für Zeile
> gefüllt wird. Also nicht die 1. Obere, und dann die 1.Untere(1440
> Pixel)?

Ja, das liegt daran, dass ich in der Mitte einen Sprung mache. Daher
beschreibe ich das Display komplett von oben nach unten.