Hallo Leute, ich sehe bei Pollin gerade wieder ein neues LCD. Leider ohne Datenblatt.. Name:Epson ECM-A0393 Best.Nr. 120 248 Kennt jemand dieses LCD und könnte mir verraten, ob das Display einen Integrierten Controller besitzt? Gruß AS
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???
>ich sehe bei Pollin gerade wieder ein neues LCD. Leider ohne >Datenblatt.. Wenn Pollin kein Datenblatt dazu hat gilt Regel Nummer 1: Finger weg Wenn Google kein Datenblatt liefert tritt automatisch Regel Nummer 1 wieder in Kraft.
>Wenn Pollin kein Datenblatt dazu hat gilt Regel Nummer 1: > >Finger weg Volle Zustimmung! Ausnahme: bei rein akademischem Interesse am reverse engineering ohne Erwartung eines konkreten Nutzens kann man sich so ein undokumentiertes Objekt ja mal leisten... Ein Controller mit Speicher für den Bildinhalt ist definitiv nicht drauf. 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, außerdem einen 74HC245 (bidirektionaler Bustreiber, hier ist die Richtung aber festgenagelt), einen C324G (vierfach OP), einen SLA6050M (Gate Array), sowie einige SOT23-Krümel. Keine Hintergrundbeleuchtung. --- Ab hier Vermutungen --- Die Auflösung beträgt wahrscheinlich 720x400 Pixel. An der Anschlußleiste wird wohl das übliche nötig sein: - GND, Logik- und LCD-Treiberspannung - Datentakt, Zeilen- und Framesync - Enable und dieses Signal, was bei jedem Frame invertiert werden muß. - Je vier Bit Daten für die obere und untere Displayhälfte. Das paßt nicht alles in 14 Pins, also wird wohl das Gate Array einen Teil der Signale selbst erzeugen. Datumscodes auf den ICs von Mitte 1990, also hat da wohl jemand ein Ersatzteillager geräumt.
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.
Angehängte Dateien:
-
lcd_lcd.jpg
340 KB
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...
Angehängte Dateien:
-
ecm_lcd_geht.jpg
120 KB
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...
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.
Hallo Benedikt, kannst du mitteilen wie die Belegung in deinem Test war. GND +5V D0 D1 D2 D3 CLK_TOP CLK_BOTTOM VLCD (Welche Spannung hast du bei deinem Test angelgt?) Werden die vier Bit fortlaufend auf die Pixel übertragen? Wird mit positiver oder negativer Flanke übertragen oder gar gelatcht? Ich weiß, ich bin einwenig unverschämt, aber deine Arbeit ist dann für viele von nutzen. Danke stellvertretend für alle.
Zum Fotografieren: Normalerweise sollte es ganz gut gehen, wenn man schräg von der Seite beleuchtet und grade von oben ohne Blitz fotografiert. Oder blitzen und dann aber das Display schräg fotografieren. Sebastian
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 ?
Also entweder du fotografierst das bei Tageslicht oder wenn du entfesselt blitzen kannst, dann richte den Blitz an die Zimmerdecke und voilà hast du deine diffuse Beleuchtung. Ansonsten gibt es für solche Zwecke der Produktfotografie so "Lichtzelte", die man über dem Produkt aufbaut und da reinblitzt. Oder ne Softbox. Aber das führt alles zu weit fürn Hausgebrauch. Grüße, Frank
> 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. manche LCDs haben einen DISP_ON Pin, um V_LCD schalten zu können, vielleicht hat es damit ewas zu tun?
Angehängte Dateien:
-
ecm_lcd.gif
2,3 KB
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.
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. Ich fotografier eigentlich alles, was so blöd spiegelt mindestens mit einem Meter Abstand. Teilweise auch deutlich mehr. Und eben leicht schräg. Sebastian
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.
Geblitzt 1/8? Das erscheint mir mysteriös... Da brauchst du eigenltich schon fast ein Stativ. Oder wie oben schon von wem anderes geschrieben: Raus in die Sonne. Da solltest du echt genug licht haben. Oder eben ans Fenster mit Südseite. Drausen wird's wohl mit Strom schwer. Aber das ist ja eigentlich OT Sebastian
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.
Gescheite Kamera, hohe Empfindlichkeit, etwas längere Belichtungszeit, Blitz aus, Lampe aus, fertig.
Angehängte Dateien:
-
ecm_s1d13700.jpg
140 KB
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.
Angehängte Dateien:
-
ecm_mod.jpg
350 KB
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.
Kann man nicht die 4 Bits von ein andere trennen, beiden Clock signalen gleichseitig ansteurn und als en normales 8 bit Dual Scan benutzen ?
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.
Wow, das ging schnell, gratuliere! Eine kleine Ergänzung kann ich zu VLCD noch beitragen: Der Schaltplan von Benedikt stimmt fast - Bezugspunkt (für den Kerko und den 27k) ist +5V statt GND - Anschlüsse 3 und 7 sind vertauscht Dann ist 3 die negative Versorgungsspannung (geht an den Kollektor), der Transistor ist als Emitterfolger geschaltet. Zwischen Pin 3 und 7 gehört ein Poti (bzw. eigentlich ein geeigneter Temperaturfühler) zur Kontrasteinstellung (deshalb der zusätzliche zweipolige Anschluß), das bildet dann mit dem 27k einen Spannungsteiler. Wenn man nur die 7 versorgt, geht eben der ganze Strom durch die BE-Diode; da es sich um ein stromsparendes LCD handelt, wird der Transistor das schon verkraften. ;) Wozu die Doppeldiode mit den beiden 220Ohm-Widerständen gut ist, weiß ich nicht. Vielleicht VLCD zügig abbauen, wenn ausgeschaltet wird?
Ich Tippe mal, das nach der Korekturt vom Nosnibor der eigendliche VLCD der Pin3 ist und Pin7 zur z.B. über ein PWM-Signal zu Kontrasteinstellung genutzt wird.
Angehängte Dateien:
-
vlcd_schem.gif
2,5 KB
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.
Ich Denke damit wäre das geklärt. 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. Von der Bildaufbereitung muss man dann ähnlich vorgehen wie bei einem CRT-Controllern auf AVR-Basis, nur dass man vier Bit paralell ausgeben muss. Welche Dauer verwendet man hier für die Bildwiederholrate ?
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.
Danke Benedikt, technisch wäre mir nun alles klar. Ist es korrekt, dass ich annehmen darf, das alle Sync und CLK Signale mit der positieven Flanke ausgelöst werden, da du sie im Belegungsplan nicht als invertiert gekennzeichnet hast ?
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.
Somit: 1 +5V 2 GND 3 Vlcd 4 /LP (Triggen nach laden der Zeilen für die Obere und Untere Hälfte) 5 6 7 Vlcd 8 FLM (Wenn wäred /LP Trigger aktiv - Daten auf 1. Zeile für o. & u. Hälfte 9 /CLK O 10 /CLK U 11 D0 12 D1 13 D2 14 D3 So O.K.
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).
O.K. dann hat LP kein Registerverhalten, sondern ein Latchverhalten und ist somit nicht invertiert. 1 +5V 2 GND 3 Vlcd (c.a. -19,5V) 4 LP (Latchpuls nach laden der Zeilen für die Obere und Untere Hälfte) 5 6 7 Contrast (Maximal-Contrast -19,5V; Minimal ist noch offen) 8 FLM (Wenn wäred LP-Latch aktiv - Daten auf 1. Zeile für o. & u. Hälfte) 9 /CLK O 10 /CLK U 11 D0 12 D1 13 D2 14 D3 so sollte es nun stimmen. oder ?
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.
Ist schon O.K. Für den Anwender ist es ja nur wichtig, dass er das LP-Signal wie ein Latchgate behandeln muss. Das die Flanken intern auch für weiter zeitliche Abfolgen genutzt werden, ist für den Anwender weniger von Bedeutung. Interesannt wäre nur noch die mimimale Pulslänge, die wird hier aber keiner liefern können.
Wenige 100ns. Je nach Display habe ich Angaben von 50ns bis 200ns als Minimalwert. Ich verwende meist 500ns und hatte damit noch nie Probleme.
O.K. Benedikt vielen Dank. Wäre net, wenn der Ur-Ersteller (AS) dieses Posts nun auch mal etwas tuen würde und die hier gewonnenen Infos mal zusammen fassen würde. Zu einem Datenblatt light. Damit wäre allen gedient. Liebe Grüße Christof
Angehängte Dateien:
-
ecm_lcd_komplett.jpg
180 KB
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.
Angehängte Dateien:
-
ecm_s1d13305.jpg
230 KB
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.
Sag mal Benedikt, hast du eine Maschine gebaut mit der man die Zeit anhalten kann. Du "wurschtelst" hier sehr aktiv an mehreren Projekten mit und bringst eine Hardware nach der anderen auf den Tisch. Man muss doch noch einer geregelten Arbeit nach gehen, soziale Kontakte Pflegen, ach ja, da wäre auch noch essen, trinken und schlafen. Ich bastel jetzt seit 2 Jahren an meiner Rolladensteuerung und bin immer noch nicht fertig. (O.K. hab zwischen durch auch mal was anderes gemacht). Wenn ich so effizent wäre wie du, hätte die nach 14 Tagen fertig sein müssen. Verwunderte Grüße Christof
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.
Leider habe ich, vorweg gesagt, keine praktische Erfahrung mit CPLD-Programmierung. Daher kann ich die Komplexität einer solchen Aufgabe schlecht abschätzen. Deswegen die Frage (á la "kann ich ein Handy bauen") an die Kenner unter uns: Wieviele Makrozellen braucht man denn? Hat es irgendeinen Sinn, eine Einfachst-Lösung mit den kleinen, bezahlbaren CPLDs im Bereich um die 64 Makrozellen zu versuchen, oder ist da absolut nichts zu machen, weil viel zu klein? Für das Interface, wenn's denn parallel sein soll, würde ich eine Ready/Busy-basierte Lösung vorschlagen: Man könnte zwei Speicherzugriffszyklen immer abwechselnd ausführen, einen Lesezugriff, um Daten an das Display zu geben, und einen Schreibzyklus, der ein anliegendes Datenbyte an die entsprechende Adresse im externen RAM speichert. Der Schreibzyklus kann, aber muß nicht stattfinden, wenn kein "Enable-Signal" anliegt, passiert eben nichts. Wenn Enable (ein Eingang, den ich nur mal so nenne) gesetzt ist, und das CPLD gerade mit dem Lesezyklus beschäftigt ist, kann ja ein Busy-Ausgang gesetzt werden. Der Mikro muß die Daten anliegen lassen, bis Busy low ist. Danach kann das nächste Byte übertragen werden.
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.
Vielleicht kann man (als synchrone oder asynchrone Schaltung) einen Zähler entwerfen, der (als Adreßzähler beim Lesen) tatsächlich die gewünschte Zählweise 1,201,2,202... hat? Wenn das natürlich das CPLD soweit aufbläst, daß es mehr als der Epson-Controller kostet, lohnt sich natürlich die einfacher zu implementierende Lösung eher.
Hallo, ich habe noch eine grundsätzliche Frage, und zwar sind die Pins 5 und 6 physikalisch verbunden? Weil ihr sie nicht benutzt, aber möglicherweise das M Signal?! oder ein anderes daran anliegen könnte?
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.
Hallo Benedikt, das Display würde mich auch interessieren, jedoch mit der Kombination lpc2101/2/3 sowie ev. SRAM. Die Teile sind günstig, jedenfalls billiger als der SID13305 alleine. Hättest du an so einem Projekt interesse ? Chris
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.
Hallo Benedikt, 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. Von der Geschwindigkeit her, dürfte es kein Problem sein. Ich dachte eher an den ARM, da preislich und pinmäßig interessanter. Ich dachte auch, externe Schalter/Tastaturen zu unterstützen.
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.
Benedikt wrote: >>Ram >Der 2103 hat 32kByte, das Display braucht 36k, reicht also nicht Er hat 8Kb ram, ein paar mehr als der AVR. >> 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. 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. Auch wenn er exclusiv als Coprozessor arbeitet sollte und 99% seiner Resourcen draufgehen, bei kosten von 5Euro inkl. Platine und SRAM ist es mir egal.
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 ?
>Wo bekommt man den LPC2103 für 5€ inkl Platine ?
Den LPC eigentlich bei jedem Distributor naja und 'ne Platine bzw. etwas
Basismaterial kostet ja nichts.
Hallo Benedikt, ich setze die lpc210x öfters ein und habe sie in 1000er Stückzahlen. Ich bin in der Lage, für den genannten Preis eine bestückte Platine mit lpc2103, 32/128Kb Sram, rs232 Pegelwandler sowie Steckverbindung zu produzieren. 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.
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.
Hallo, ja, ich würde die Platinen zum Selbstkostenpreis abgeben, kein Problem, nur da Selbskostenpreis keine Lagerung, sprich die Platinen werden ungefähr in der Menge produziert, wie benötigt. 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. Ne kurze Frage, sollte die MCU ohne externe RAM ausgestattet werden, sprich nur Text, ev kleine Vektoren, in welcher Zeit muß eine Linie (nehme an 8 bits) aufgebaut werden ?
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.
>> 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. > Würde gerne beide Möglichkeiten haben, mit der gleichen Platine bei unterschiedlicher Bestückung. >> 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 ? > Beides
Hatte ganz vergessen, wie sieht es denn mit der negativen Spannung aus, wievile mA/uA muß geliefert werden EE + VREF
Ok, ich weiß derzeit noch nicht, wie ich die negative Spannung bereitstelle, der Rest scheint zum jetzigen Zeitpunkt nicht so schwierig. Welches Interface möchtet ihr noch drauf haben, z.B. USB, IRDA, I2C, ... oder sonstige Wünsche. Hat jemand ev. auch eine Idee, was man mit dem überschüssigem SRAM anfangen könnte ? Chris
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)
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.
Angehängte Dateien:
-
glcd1.png
17 KB
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 ;-).
Angehängte Dateien:
-
Line1.PNG
1,5 KB
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
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.
Schade das Falk hier nicht mehr so aktiv ist, er würde den Wettbewerb mal so eben locker gewinnen.
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.
Angehängte Dateien:
-
ecm_lcd_grayscale.jpg
58 KB
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.
Die Platine wird warscheinlich Donnerstag zum Platinenhersteller geschickt. Ram kommt ein 256kbit drauf, darauf lassen sich dann 2 Pages realisieren, mit 8 Farben (natürlich Monochrom). Bitte spezifizieren, ob mit oder ohne Spannungsinverter, wenn jemand noch mitbestellen will. Der genannte Preis war ohne Spannungsinverter.
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 ;-)
>Die Frage ist halt, ob das ganze speziell für das LCD sein soll, oder >eher als etwas universelles ARM Board gedacht ist. Es ist eigentlich ein Board speziell für das LCD display, wobei noch drei andere Sachen dranhängen, ein LA 8 kanäle bis 50Mhz bzw 4 bis 100Mhz sowie 1x ADC 50Mhz sowie 8x ADC, Khz Bereich, inkl. Display und RS232. >Könntest du einen Schaltplan oder ähnliches hier reinstellen, damit man >sehen kann, was alles drauf ist ? Das wird noch länger dauern, was drauf sein wird: Lpc210x (1/2/3/4/6), Sram, Latch (Display) oder Zähler (LA), 10 polige Stiftleiste für Tastatur, Quarz, RS232 Pegelwandler (transistor), Optional: Inverter, RTC Quarz, i2c EEPROM, Buzzer
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
Hi, 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. Den Preis habe ich wohl überlesen. Gaaanz weit oben war was von 5 Euro zu lesen, aber das war wohl nur Platine+ARM. Also, meine Fragen: Was kostet so eine Platine ? (wenn's "günstig" ist würde ich evtl. 5-10 Stück nehmen. Vorkasse natürlich !) Bestückt oder nicht ? (Platine + ARM würde mir erstmal genügen; RAM kann ich bei Bedarf selber einlöten) Sind "Spezial-ICs" nötig/dabei ? (Ich kann keine CPLDs programmieren, SMD nur ab ca. 0,8mm pinraster löten (mit Übung geht vielleicht auch 0,6mm)) Gruß ein anderer Klaus
>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.
Hi, @ Francesco Na: keine Pins übrig: ich habe mir gerade das Datenblatt des LPC2103 runtergeladen... ja, soviele Pins hat der gar nicht. Das sind ja kaum mehr als bei einem AVR. sekundärer JTAG... wusste gar nicht das es sowas gibt. Platine: Interesse würde bestehen, quasi als "Mini-Modul" mit Quarz, JTAG und Spannungsregler. Und 2,54mm-Pins an den Seiten für mich als Grobmotoriker. Aber evtl. wäre der LPC213x besser, der hat mehr Pins (und: den gibts nicht allzu teuer bei Reichelt) Platine kann ruhig Hartpapier oder Pertinax oder so was sein (ist mir sogar lieber wg. Bohrer), Lötstopp-Lack und Aufdruck brauchts wohl nicht. Wäre noch die Frage des Geldes, was würde so ne Platine kosten ? Oder 10 Platinen ? Gruß der gleiche andere Klaus wie gestern
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!
Angehängte Dateien:
-
lpc_ecma0393.png
50 KB
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.
Angehängte Dateien:
-
GLCD-Stecker.jpg
74 KB
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/ecm_lcd_komplett.jpg 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).
Schade, inzwischen sind die Displays ausverkauft. Wollte mir gerade 3 bestellen. Mal wieder zu spät :-(
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!
hi Ich bin zwar nur Neugiriger Mitleser aber wenn es so eim "Brett" mal geben sollte würde ich mich auch gern vordrängeln...:-)(so für zwei stück ?) hatte mir auch ein paar Displays auf gut Glück bestellt aber wahr nicht in der Lage auch nur einen Hauch von Leben aus den Teilen zu locken wollte es als Terminal zum mitlesen nutzen so ganz ohne PC. Tolle sache die Ihr da macht. Vico
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
@Benedikt "denn das LCD ist nichtmal schlecht für Graustufen. Hier mal ein Bild mit 16 Graustufen." sag mal, wie erzeugst du die graustufen? Also schon klar indem du dunklepixel länger anzeigst als helle, aber wie genau? 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...
LCD Kontroller kann man einfach mit ein Propeller machen, aber für mehr als 32 kbytes (diesen Fall) eine externe Speicher nötig ist. Bei digikey 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). Ich glaube est ist ein bessere Lösung als ein CPLD und kommt mit DIP Gehäuse. Für eine externe Speicher ein DRAM kann nicht schneller als etwa 300 ns gelesen wird aber nicht nötig in disen Fall. Wenn man mehr leistung braucht er kann bis 100 MHz überkaktet.
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
Angehängte Dateien:
-
SANY0078r.JPG
220 KB
Hier gibt (auf english) ein Thread ich habe geposted ;-) http://forums.parallax.com/forums/default.aspx?f=25&m=261658 Fotos.... here gibt eine, 640x480 display (dual scan) aber nur ein hälfte benutzt,
> 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. hm, die idee ist mir auch gekommen, wie hast du den zähler gehandhabt? bei 70 hertz und 16 stufen, musst du den zähler ja nur alle 4 hertz um eins erhöhen (bzw. verringern), ca. eig. 4,375 und dann ja, eben jedes pixel solange an lassen wie der wert des pixels größer ist als der counter wert > In diesem Fall waren es sogar der 4 fache, da 4Bit pro Pixel. naja, ok, ich hab aber nicht mit frames gerechnet, sondern einmal einen 4bit speicher, der die bildinformation enthält, und dann noch mal den gleichen, bei dem man bei jedem durchlauf den pixelwert um eins verringert, und wenn da bei einem pixel der wert 0 erreicht wird, dann wird das pixel nicht mehr angezeigt, und nach 70 druchläufen (70hertz) wird der count speicher wieder mit der bildinformation gefüttert.... die variante mit festen pixeln und dem counter vergleich ist aber wesentlich speichersparsamer
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.
> Die reine PWM Technik führt selbst bei 8 Graustufen zu einem stark
flackernden Bild.
ist ja auch klar... ein helles pixel ist dann 3/4 aus und 1/4 an z.B.
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.
das verhältnis wäre dann immernoch 1/4 zu 3/4
So hätte man ein gleichmäßigeres Anzeigen statt einem abgehackten an -
aus
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.
> 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
und wie meinst du das mit dem kontrast, sofern die reaktionszeit
(rise/fall times) des lcds kürzer sind als eine high dauer, kann da
nichts versaut werden, da du dann nicht außerhalb der lcd
spezifikationen arbeitest, sprich, dieses schnelle umschalten ist ja
nichts anderes als z.b. ein sich schnell bewegendes bild mit 1bit
sollten die pixel allerdings träge sein, dann ok, dann wird man da
probleme bekommen
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.
Benedikt K. wrote: > 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. ok, andere Zahlen: 35 Graustufen: sprich das hellste pixel (nach komplett aus) ist 1/35 also 2/70 Hertz lang. wenn ich nun diese 2/70 hertz high Zeiten so lege, dass ich 1/70 das pixel einschalte, dann 34/70 aus, dann wieder 1/70 an, und dann die restlichen 34/70 wieder aus, und das wiederholen komme ich auf 34 + 1 + 34 + 1 = 70 so, dass ist doch aber für das Menschliche Auge viel besser als, 2/70 pixel an und dann 68/70 Pixel aus. da wir dem Auge nun 2mal, zwar kürzer aber besser verteit auf die gesamte Dauer eines Zyklus einen impuls "oh, da leuchtet was" geben
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 "Re: G-LCD bei Pollin" Beitrag "Re: G-LCD bei Pollin" Beitrag "Re: 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 "Re: 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?
Angehängte Dateien:
-
s1d13305_ecm.gif
31 KB
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=MDU3OTc4OTk=&w=OTg4OTk4&ts=0
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/s1d13305_ecm.gif 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/ecm_lcd_komplett.jpg 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/s1d13305_ecm.gif > 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/ecm_lcd_komplett.jpg > 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.
Hi, meine Strategie für den Aufbau das Graphikkontrollers steht bei mir jetzt auch fest. Eine einseitige Platine wird die Bauelemente aufnehmen. flache Platinensteckverbinder werden Flachbandkabel für Zuleitung und Ableitung zum Display aufnehmen. die ganze Platine wird dann mit selbstklebenden Abstandshalter an der Displayrückseite befestigt. CSD kann den S1D13305 nicht mehr liefern, hab aber eine andere "Quelle" gefunden. Nicht klar ist, ob ich die A(rechteckiges Gehäuse) oder B(quadratisches Gehäuse) bekomme. Im Interesse der Nachbaumöglichkeit werde ich die Bauform routen, die auch weiterhin beschaffbar ist. S-Rams von Reichelt sind schon da, wobei natürlich das dort hinterlegte DBL nicht zu den gelieferten Rams passt. Halb so schlimm. 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. Ich tendiere daher als Ersatz, den AQY212 (1,2mA bei 1,25V) einzusetzen. Sind in etwa für 2 Euro beschaffbar.Vielleicht hat ja jemand eine preisgünstigere Idee. @Benedikt ich hab mal die Optomosfet-Schaltung vorbereitet. Wieso ist bei Dir der LED-Rv bei 5V nur 330 Ohm gross, was macht der 47K Verwendest Du für den Takt nur ein 16Mhz Quarz, im DBL sind noch Kondensatoren eingezeichnet. Eine ordentliche Liste der Bauteilquellen und die Boarddatei ist in Vorbereitung und sollte den Nachbau vereinfachen. Wigbert
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/ecm_lcd_komplett.jpg mit der Schaltung nicht übereinstimmt. http://www.mikrocontroller.net/attachment/36494/s1d13305_ecm.gif 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
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.