Da ich immer wieder auf einen grafikfähigen LCD Controller für
controllerlose 320x240 Displays angesprochen werde, habe ich meinen
alten auf der 640x480 Version
(Beitrag "LCD Controller für 640x480 LCD mit mega8515") basierten Controller
etwas aufgepeppt und mit neuen Features versehen:

- Einfache Schaltung aus nur wenigen Standardbauteilen
- Grafikmodus mit 4 Graustufen
- Textmodus mit 8x12 Zeichensatz, der Text in Grafik umwandelt
- Funktionen für Pixel, Linien, Rechtecke, Bilder usw
- Ansteuerung über UART (Standard: 19200 Baud), daher ideal als Display
in einer µC Schaltung verwendbar. Die Grafikfunktionen entlasten dabei
den anderen µC.
- Die LCD Routinen sind in Assembler geschrieben (für beste Ausnutzung
der Rechenleistung), Ansteuerung und Kommunikation dagegen in C, daher
leicht ist das ganze leicht erweiterbar.

So könnte das ganze aussehen, wenn es aufgebaut ist und läuft.

Sehr beeindruckend. Danke fürs posten.

Gruß

Ich hatte schon die ganze zeit vor deinen großen Controller auf die
displays umzumünzen, bin aber noch nicht dazu gekommen, naja jetzt hast
du das ja gemacht, prima :D

@Benedikt,

ich konnte in deiner Schnittstellenbeschreibung die Schnittstelle zum
Kreise zeichnen nicht finden.

Eine Frage dabei zur Umsetzung, bietet sie nur gefüllte Kreise, wie im
Bild, oder ist es möglich die Randdicke zu Variieren?

Gruß,
Dennis

Wirklich beeindruckend Benedikt,

toll das Farbenspiel mit dem "schwarzen" (ist es doch wohl) Display.

Wigbert

Dennis S. wrote:
> ich konnte in deiner Schnittstellenbeschreibung die Schnittstelle zum
> Kreise zeichnen nicht finden.

Gibt es auch nicht. Ich hatte zwar erst dran gedacht, aber dann doch
sein lassen, da Kreis im Vergleich zu Rechtecken doch eher selten
vorkommen. Bei der nächsten Version ist das aber drin.

Wo wir schon dabei sind: Kennt jemand eine Füllfunktion die auch auf dem
AVR einigermaßen schnell läuft ? Floodfill scheitert schon alleine am
Stack.

in inrgend einer lib wurde das so gelöst:
man errechnet zwei auf gleicher höhe liegende Kreiskoordinaten und
zeichnet von der einen koordinate zur anderen eine linie, das macht man
für alle punkte, fertig ist der gefüllte kreis.

Oder du machst es so: vom mittelpunkt ausgehen gehst du in y richtung
nach oben bis du auf ein gleichfarbiges Pixel (rand) triffst, das gleich
einmal nach unten.
Dann erhöhsat du x um eine und wiederholst das solange bis du in x
richtung auf ein gleichfarbiges pixel triffst.
dann nochmal vom mittelpunkt aus nach links und fertig
Problem ist nru wenn andere objekte "im Weg" sind wird nicht der ganze
kreis gefüllt. Man könnte natürlich auch einfach die koordinaten des
Kreisrandes speichern oder das beim zeichnen miterledigen volgendermaßen
vieleicht:
Ich geh jezt mal davon aus das du immer Viertelkreise zeichnest.

mx = mittelpunkt X
my = mittelpunkt Y

x=mx
oldx = x-1
y=my+radius
while(x < mx+radius) {
 
 drawPixel(x,y) //rand zeichnen
 if (x != oldx) { //x != alter postion, sonst haben wir schon gemalt!
  oldy = y //y sichern
  while( y > my ) { //sind wir schon am mittelpunkt?
     y--; //nach unten gehen
     drawPixel(x,y) //pixel zeichnen
  }
  y=oldy //y wieder herstellen
 }
 oldx = x //altes x speichern um "doppelmalen" zu verhindern falls
          //sich x in dieser iteration nicht ändert
 x = newXKoord(x) //neue X berechnen
 y = newYKoord(y) //neue Y berechnen
}

Jezt natürlich ungetestet aber das könnte so gehen, es werden halt immer
streifen vom Rand runter bis zum mittelpunkt gezeichnet.
Muß man jezt halt nocheinmal spiegeln für die 4 Quadranten.

Was ist das für ein controller-loses Display?

Mfg
Thomas Pototschnig

Pollin: 120460 (mechanisch und elektrisch identisch zu 120471).

Hallo Benedikt,

>Bei der nächsten Version ist das aber drin.
Wirst Du die Hardware verändern?

Wigbert

Nein, nur die Software.

hallo Benedikt,

respekt

vielleicht eine blöde frage aber,
um eine text zb.in Zeile 1 zu schreiben
ist es richtig 17,x1,y1 x=position y=zeile

mfg kay

Ja, genau so. Die Zeilen und Spaltenzählung beginnt aber C typisch bei
0.

Mir ist jetzt noch nicht ganz klar welcher RAM
verwendet wird. Alle anderen Bausteine sind ja bezeichnet ;-).

Gibt es da einen Standard Reichelt Typ ?

Gruß Sven

Als SRAM findet irgendein schneller 32k x 8 SRAM mit 10-35ns Verwendung.
Sowas hat Reichelt nicht.
Daher kann man in der lcd.c den RAM Zugriff ausbremsen. Dann kann man
auch langsamere mit bis zu 90ns verwenden. Das wäre dann z.B. 62256-80
von Reichelt.

Ok, danke. Dann würde dieser hier passen :

http://de.farnell.com/1271827/halbleiter/product.u...

Bestnr: 1271827

Danke schon mal für die Arbeit und die Veröffentlichung.
Überlege das ganze in SMD zu realisieren und zu veröffentlichen.


Gruß Sven

Ich hätte da mal eine Frage aus reinem Interesse:
Warum die etwas unorthodoxe Einblendung des externen Speichers in den
Adressraum des AVR (A0 vom externen Interface wird nicht verwendet)?
Hat das Vorteile beim Auslesen des RAM für den LCD-Datenstrom?

Sven wrote:
> Ok, danke. Dann würde dieser hier passen :

Ja, der sollte funktionieren.

Stefan Ernst wrote:
> Ich hätte da mal eine Frage aus reinem Interesse:
> Warum die etwas unorthodoxe Einblendung des externen Speichers in den
> Adressraum des AVR (A0 vom externen Interface wird nicht verwendet)?
> Hat das Vorteile beim Auslesen des RAM für den LCD-Datenstrom?

Ja. Damit das ganze schneller geht, teile ich den 16bit Adresspointer in
256 Zeilen und 256 Spalten auf, genau passend für das LCD.
Ich lese für das LCD 80 Bytes aus. Da das LCD nur 4bit hat, reicht ein
Speicherbyte für 2 Datenpakete zum LCD, daher der Multiplexer und daher
ist A0 nicht beschaltet.

Benedikt K. wrote:

> Ich lese für das LCD 80 Bytes aus. Da das LCD nur 4bit hat, reicht ein
> Speicherbyte für 2 Datenpakete zum LCD, daher der Multiplexer und daher
> ist A0 nicht beschaltet.

Ah, ich hatte übersehen, dass der Multiplexer am Ausgang durch das
RD-Signal getoggelt wird. ;-)
Danke!

Kleines Update:
Jetzt mit Routinen um einen (gefüllten) Kreis zu zeichnen.