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
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.
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 :).
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.
> 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
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.