www.mikrocontroller.net

Forum: Codesammlung Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen

Autor: Benedikt K. (benedikt)
Datum: 24.04.2008 15:15
Dateianhang: lcd_con_320x240.zip (276 KB, 213 Downloads)

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.
Autor: Benedikt K. (benedikt)
Datum: 24.04.2008 15:15
Dateianhang: 320240_lcd_4bpp_sch.jpg (131,4 KB, 482 Downloads)
preview image for 320240_lcd_4bpp_sch.jpg

So könnte das ganze aussehen, wenn es aufgebaut ist und läuft.
Autor: Thorsten (Gast)
Datum: 24.04.2008 15:21

Sehr beeindruckend. Danke fürs posten.

Gruß
Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum: 24.04.2008 15:59

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
Autor: White Noise (whitenoise)
Datum: 24.04.2008 22:48

@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
Autor: Wigbert Picht (Firma -DL1ATW) (wigbert)
Datum: 24.04.2008 22:50

Wirklich beeindruckend Benedikt,

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

Wigbert
Autor: Benedikt K. (benedikt)
Datum: 24.04.2008 23:14

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.
Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum: 25.04.2008 07:40

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.
Autor: Läubi Mail@laeubi.de (laeubi) Benutzerseite
Datum: 25.04.2008 08:07

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.
Autor: Thomas Pototschnig (pototschnig)
Datum: 25.04.2008 08:20

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

Mfg
Thomas Pototschnig
Autor: Benedikt K. (benedikt)
Datum: 25.04.2008 08:54

Pollin: 120460 (mechanisch und elektrisch identisch zu 120471).
Autor: Wigbert Picht (Firma -DL1ATW) (wigbert)
Datum: 25.04.2008 09:26

Hallo Benedikt,

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

Wigbert
Autor: Benedikt K. (benedikt)
Datum: 25.04.2008 10:33

Nein, nur die Software.
Autor: Kay B. (newbie)
Datum: 25.04.2008 18:25

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
Autor: Benedikt K. (benedikt)
Datum: 25.04.2008 18:42

Ja, genau so. Die Zeilen und Spaltenzählung beginnt aber C typisch bei
0.
Autor: Sven (Gast)
Datum: 25.04.2008 18:50

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
Autor: Benedikt K. (benedikt)
Datum: 25.04.2008 19:11

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.
Autor: Sven (Gast)
Datum: 25.04.2008 19:22

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
Autor: Stefan Ernst (sternst)
Datum: 25.04.2008 19:58

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?
Autor: Benedikt K. (benedikt)
Datum: 25.04.2008 21:07

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.
Autor: Stefan Ernst (sternst)
Datum: 25.04.2008 21:46

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!
Autor: Benedikt K. (benedikt)
Datum: 10.05.2008 09:22
Dateianhang: lcd_con_320x240.zip (272 KB, 44 Downloads)

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

Antwort schreiben

Die Angabe einer Email-Adresse ist freiwillig. Wenn Sie automatisch per Email über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Suchfunktion und Betreffsuche benutzen - vielleicht gibt es schon einen ähnlichen Beitrag
  • Aussagekräftigen Betreff wählen
  • Im Betreff angeben um welchen Controllertyp es geht (AVR, PIC, ...)
  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
  • JPEG-Dateien (.jpg) nur für Fotos verwenden, Schaltpläne, Screenshots usw. als PNG oder GIF anhängen

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [pre]vorformatierter Text (z.B. Code in anderen Sprachen)[/pre]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel






webmaster@mikrocontroller.netImpressumWerbung auf Mikrocontroller.net