Forum: Mikrocontroller und Digitale Elektronik Entwicklung eines Grafikcontrollers für Rasterdisplays


von Mike (Gast)


Lesenswert?

Hallo liebe Gemeinde,

ich habe vor einiger Zeit einen Spielcomputer mit einer 24x16 Led-Matrix 
gebaut und beschäftige mich gerade mit der Ansteuerung von 
LCD-Matrixdisplays. Die von mir verwendeten Algorithmen funktionieren 
zwar, ich empfinde sie jedoch als sehr primitiv.

Dabei beschäftigt mich seit längerem die Frage, wie sich ein Controller 
für Rasterdisplays bauen/programmieren ließe, dem über spezifische 
Steueranweisungen die Bilddarstellung und -berechnung übertragen werden 
könnte. Das Ziel wäre z.B., dass zwei AVRs über USART miteinander 
verbunden würden. Der Master übernimmt die Mensch-Maschine-Interaktion 
und der Slave die vollständige Berechnung des Bildgeschehens. ALternativ 
könnte aber auch ein Controller entstehen, der über eine Schnittstelle 
von einem beliebigen Steuergerät angesprochen wird. Z.B. über RS232 oder 
USB.

Dabei müsste sich der Display-Kontroller sowohl um den Refresh des 
Bildes, als auch um die Berechnung des Bildinhaltes kümmern. Aufgaben 
wie Pixel, Linien, Kreise aber auch Sprites und Bilder müssten ihm 
übergeben werden und dieser sollte sie dann auf einem beliebigen 
Bildraster ausgeben können.

Ich bin leider in dieser Theorie noch nicht wirklich drin, würde mich 
aber gerne in dieses Thema vertiefen. Da die gezielte 
Informationbeschaffung im Internet bislang (abgesehen von 
Beitrag "LCD Controller für 640x480 LCD mit mega8515", wobei ich leider ASM nicht 
verstehe) nicht wirklich erfolgreich war, würde ich dieses Problem gerne 
zur Diskussion stellen.

Wie müsste ein Displaycontroller prinzipiell funktionieren: 
Bildspeicher, Bildberechnungsfunktionen, fixe Bildelemente und Sprites, 
etc. Wie könnte ein Ansteuerungsinterface für die Kommunikation zwischen 
dem Grafikcontroller und einem Master sinnvoll gestaltet werden, wie 
könnte man es standardisieren? Welche Funktionen zur Bilddarstellung 
sind unbedingt relevant? Welcher Displayprototyp könnte für eine erste 
Controllerentwicklung verwendet werden?

Mit geht es um ein grundsätzliches Verständnis der Aufgabe und der 
Problemlösung und ich würde das Problem gerne in C angehen. Die 
zusätzliche Elektronik, falls notwendig, würde ich gerne ausschließlich 
über Standardbauteile realisieren wollen.

Mit Gruß

Mike

von Helmut L. (helmi1)


Lesenswert?

Nimm ein FPGA.

von Karl H. (kbuchegg)


Lesenswert?

Mike schrieb:
> Wie könnte ein Ansteuerungsinterface für die Kommunikation zwischen
> dem Grafikcontroller und einem Master sinnvoll gestaltet werden, wie
> könnte man es standardisieren? Welche Funktionen zur Bilddarstellung
> sind unbedingt relevant?


Du könntest dein Studium zb damit beginnen, dir Handbücher der 
Grafik-Terminals aus den 80er und 90er Jahren anzusehen, wie die genau 
dasselbe Problem damals gelöst haben.

http://bitsavers.org/pdf/tektronix/410x/070-4893-00_4107_4109_PgmrRef_Nov83.pdf

Für Basisalgorithmen (Bresenham, Window/Viewport Trafo, etc) sind zb die 
Klassiker wie Foley/Van Dam gut zu gebrauchen.

von Mike (Gast)


Lesenswert?

Hallo Helmut,

ich würde gerne zunächst eine bekannte und verbreitete Plattform wie 
z.B. den Atmega32 verwenden, um nicht noch mehr Baustellen zu schaffen 
:).

von Helmut L. (helmi1)


Lesenswert?

Das ganze Rastertiming wurde frueher alles in Hardware geloest. Zu 
Anfaengen der PC Aera war das meisten der 6845 CRT Controller. Mitte der 
80er kam dann der ACRTC auf den Markt der auch schon linien und kreise 
ziehen konnte.

Du must aufpassen mache Display nehmen es einem uebel wenn man sie 
falsch ansteuert.

Ich wuerde fuer sowas heute ein FPGA nehmen. Da brauch ich mir keine 
Sorgen drum zu machen das die Rechenzeit nicht reicht und man staendig 
auf jeden Befehl schielen muss ob es dann noch geht.

von MaWin (Gast)


Lesenswert?

> 24x16

Für so winzige Displays reicht die Rechenleistung eines normalen uC 
locker aus.

Man braucht keinen Controller, man braucht nur eine Ansteuerelektronik 
die die nötigen Signalpegel für Multiplex erzeugt.

Das haben Japaner schon vor 30 Jaren gelöst, heute baut das jeder 
Chinese.

http://www.holtek.com/chinese/docum/Display_Driver/16L23.htm

von Mike (Gast)


Lesenswert?

Hallo MaWin,

dass ein Display mit 16x24 Punkten keine Herausforderung fuer einen uC 
sein sollte, das ist mir klar. Mir ist bei der Entwicklung nur 
aufgefallen, dass ich z.B. geometrische Objekte als Bitmuster gezeichnet 
habe, anstatt dieses als einen Funktionsaufruf zu gestalten. Daher das 
Interesse an der Gestaltung eines "aktiven" Controllers, der sowas 
uebernimmt. Generell sollte dieses dann auch fuer n x m Matrizen 
verallgemeinert werden.


Die Frage ist nur: Was braucht man, wie geht man es an, worauf muss man 
achten.

Mit Gruss

Mike

von Frank K. (fchk)


Lesenswert?

Mike schrieb:

> Wie müsste ein Displaycontroller prinzipiell funktionieren:
> Bildspeicher, Bildberechnungsfunktionen, fixe Bildelemente und Sprites,
> etc. Wie könnte ein Ansteuerungsinterface für die Kommunikation zwischen
> dem Grafikcontroller und einem Master sinnvoll gestaltet werden, wie
> könnte man es standardisieren? Welche Funktionen zur Bilddarstellung
> sind unbedingt relevant? Welcher Displayprototyp könnte für eine erste
> Controllerentwicklung verwendet werden?

Erster Schritt: das passende Werkzeug nehmen!

Diesen Prozessor empfehle ich Dir. Den solltest Du noch löten können. 
Bis QVGA reicht der interne Speicher, darüber musst Du externes RAM 
anschließen.
Den Chip gibts sogar bei Reíchelt.

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en547869

Entwicklungsumgebung (IDE), Compiler, und Applikationsbibliotheken (auch 
für Grafik) gibts bei microchip.com zum Download, als Programmer reicht 
ein PicKit2 oder PicKit3 für etwa 50-60€ (oder ein 100% Clone davon, die 
gibts günstiger).

Schau Dir die Dokumentation zum Grafikcontroller und die 
Applikationsbibliotheken an, da kannst Du einiges lernen.

Die wichtigste Funktion einer Hardwarebeschleunigung ist das BitBlit, 
sprich das Kopieren von rechteckigen Bereichen unter Berücksichtigung 
von Transparenz und bei 1 Bit Farbtiefe auch von logischen Verknüpfungen 
(and, or, xor,...). Das braucht man auch für die Textdarstellung.

Alles andere ist nicht so wichtig.

fchk

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
Noch kein Account? Hier anmelden.