Forum: Projekte & Code Grafik-LCD Controller mit AVR und VRAM

Programm dazu, nur monochrom. Nicht 100% getestet. Ein
Kommunikationsprotokoll über UART fehlt.

Ach ja: In der gezeigten Schaltung sind gegenüber der realisierten 
Version und somit dem Code die Ports A und C und 2 Pins an Port D 
vertauscht (=> config.h).

Deshalb hier die implementierte 8-Bit Version. Für 320x240 wird aber nur 
eines der VRAMs benötigt.

Für die Spannungserzeugung vom LCD => Benedikt.

Oder so, wenn sowieso schon 12V zur Verfügung stehen, beispielsweise 
weil der Inverter die braucht. Denn dann vereinfacht sich der Schaltung 
etwas.

PS: Die 100nF Kerkos für VCC muss man sich dazudenken. Bei Schaltungen 
für Lochraster lasse ich die im Plan der Einfachheit halber meist weg.

Hi Andreas,

auf die schnelle hab ich bei Segor nur VRams mit 60-70ns gefunden.
Oder hast Du mehr Info.

Wigbert

64Kx4:  ArtikelNr 41264-ZIP120, steht aber MB81461 drauf.
256Kx4: ArtikelNr 524258AZ-10.

Für letztere war nur ein japanisches Pinout und ein Datasheet vom 
TC524258B aufzutreiben, aber das dürfte sich nicht signifikant 
unterscheiden.

Die ZIP-Gehäuse sind netterweise ziemlich lochraster- 
prototypenfreundlich, denn die Pins lassen sich problemlos so 
zurechtbiegen, dass sie in Präzisionssockelleisten passen. Und 
platzsparend sind sie zudem auch.

@Andreas Kaiser

hab die Dinger bei Segor gefunden, Preis ist erst mal OK.
Dank Dir.

Wigbert

Man kann das Gatter-IC auch einsparen, indem der Shift/LCD-Takt per 
Software erzeugt wird. Dann allerdings, um Zeit zu sparen, vorzugsweise 
mit maximalem Takt (8-10MHz), was zwar weit über dem offiziellen Takt 
des Displays liegt, aber trotzdem problemlos funktioniert.

Bei der Erzeugung der Displayspannung ist hier der Anschluss eines 
separaten Kontrastpotis vorgesehen. Ein Poti im Wandler ist dafür u.U. 
nicht sonderlich praktisch, denn das sollte sehr dicht am Wandler 
sitzen.

Als Controller ist so ziemlich jeder AVR ab 40 Pins und 16KB ROM 
einsetzbar, also auch ATmega16/32 - insbesondere auch der ATmega162 mit 
seinen 3 zusätzlichen Portpins.

Anzahl und Grösse der ins Programm integrierbaren Fonts ist natürlich 
von der ROM-Kapazität begrenzt. Mit grossem 48x32-Font sind 64KB 
erforderlich, für die 3 kleinen Fonts (8x6,10x8,12x8) reichen 16KB aus.

Dafür aktualisierte Programmversion.
Pinbelegung in config.h anpassen!

@Andreas Kaiser ,

mir sind ein paar VRams IBM025161LG5D-6H (256Kx16 5V < 60ns) vor die 
Füsse gefallen. Würden die auch gehen? Die wären nun mal da.
Dank Dir mal schon.

Wigbert

Keine Ahnung. Hast du Daten gefunden? Ich nicht.

Wäre natürlich optimal für SVGA und kleinere TFTs, dann aber ist der 
Pincount wegen schon ein Mega128 nötig.

hab das DBL da her:

http://www.datasheetarchive.com/I-5.htm

hab noch nie was mit V-Rams gemacht, deshalb meine Frage.

Wigbert

Spricht nichts dagegen, die sehen im Prinzip genauso aus wie die schon 
erwähnten Typen, nur breiter. Zwar sind ein paar Pinbezeichnungen 
anders, aber die üblichen Modi sind alle dabei und gleich gesteuert wie 
bei den 64Kx4 und 256Kx4.

Ist zwar EDO statt FPM, aber das ist egal.

Da Byte-Enables vorhanden sind, könnten die sogar mit pinsparendem 
8bit-Bus seitens des Controllers arbeiten. Wenn man die 16bit Breite für 
SVGA/TFT braucht.

Wenn du die gesamte Kapazität brauchst, also auch A8, dann musst du halt 
den Code etwas umstricken, denn in dem hier gezeigten Code sind nur 8 
Adressbits drin und das macht den Zyklus etwas einfacher und schneller.

und die <60ns , wie klein auch immer..
wären schnell genug?

Wigbert

Keine Panik. Die von mir verwendeten Genossen sind -120er. ;-)

Bei diesen hier kannst du die einen oder anderen Brems-NOPs rauswerfen, 
beispielsweise die im Refresh.

Dank Dir erst mal,

wird aus Zeitgründen mit dem Nachbau eine Weile dauern,
aber irgendwie wollen die Dinger auch eingebaut werden.

Wigbert

Jetzt mal ne Frage beim Benedikt GLCD Schaltung sollte der Speicher 15ns 
sein also recht schnell, wieso schafft dann deiner der nur 120 ns hat 
den Bildaufbau? ich glaube da habe ich was nicht verstanden :(

Bei Benedikt wird der Speicher als externes SRAM vom AVR selbst 
angesteuert, daher gilt das Zeitverhalten eines externen SRAMs aus dem 
AVR Datasheet. Ich weiss aber nicht, ob man da wirklich 15ns benötigt, 
oder ob er einfach nur so ein Ding rumliegen hatte.

Bei mir wird das VRAM fast (SC per Timer) bis ganz (SC per Software) vom 
AVR zu Fuss gesteuert, d.h. mit Pingewackel in Software. Was kein 
Problem ist, weil man pro Zeile nur einen einzigen VRAM Transfer-Zyklus 
(plus Refresh) benötigt, den Rest macht das VRAM per SC ja selber.

Lies dir mal durch was ein VRAM ist, dann wird's evtl. klarer.

Andreas Kaiser wrote:
> Bei Benedikt wird der Speicher als externes SRAM vom AVR selbst
> angesteuert, daher gilt das Zeitverhalten eines externen SRAMs aus dem
> AVR Datasheet. Ich weiss aber nicht, ob man da wirklich 15ns benötigt,
> oder ob er einfach nur so ein Ding rumliegen hatte.

Das Datenblatt schreibt eigentlich ein noch strengeres Timing vor. Es 
gehen aber bis etwa 35ns, darüber gibt es Problem. Dies liegt daran, 
dass bei 16MHz ein Takt nur 62,5ns lang sind und in dieser Zeit die 
Daten auch noch eingelesen werden müssen.

Kann man dem AVR-Zyklus keine Waitstates angedeihen lassen? Oder wird 
dann das Timing zu knapp?

Das kann man, allerdings wird das Timing dann von 3 Takten auf 4 Takte 
pro Zugriff verlängert. Das reicht noch, aber man spürt es schon 
deutlich.