Um das Suchen für andere zu vereinfachen hier erst mal ein paar Begriffe nach denen andere suchen könnten: ELECTRONIC DATA TECH GET0430G0DM6 Reichelt hat ja zur Zeit eine Reihe von relativ günstigen digital ansteuerbaren LCD-Modulen. Weiß jemand, wie weit man die Module untertakten kann? Laufen die Module auch mit unregelmäßigen Takt, sprich kann man beispielsweise ein paar Pixel senden, und dann eine Pause einlegen?
>Weiß jemand, wie weit man die Module untertakten kann? Laufen die Module >auch mit unregelmäßigen Takt, sprich kann man beispielsweise ein paar >Pixel senden, und dann eine Pause einlegen? Die EDT-Module kann man unter- und übertakten. Beim Untertakten wird Flimmern auftreten (<20-30Hz) und ein Neubeschreiben erfolgt "zackig". Beim Übertakten wird die Schrift irgendwann unscharf. Man kann durchaus die Bilddaten als "bursts" ausgeben, zwischen denen eine Pause liegt. Hast Du eine bestimmte Anwendung im Auge, die Deine Anfrage präzisiert?
Entwickler schrieb: > Hast Du eine bestimmte Anwendung im Auge, die Deine Anfrage präzisiert? Naja, das ist noch nichts konkretes. Die Idee ist aber, dass man den Bildinhalt mit einem ATMega generieren könnte. Da könnte man beispielsweise einige Pixel berechnen und dann am Stück ausgeben. Damit könnte man sich einen richtigen Controller sparen.
Hast Du mal gerechnet? 480 x 272 = 130560. Soviel Byte Speicher braucht man für ein Bild auf 4,3" Display bei 8Bit/Pixel (256 Farben). Bei 60Hz Wiedergabe werden ca. 9MHz Taktfrequenz benötigt. Falls man nur 15Bilder/s ausgeben will, muß die mittlere Taktfrequenz etwa 2,3MHz betragen. Welcher ATmega soll das denn leisten? Um den Controller für die Anzeige zu sparen, braucht man einen 32Bit Prozessor (oder sehr schnellen 16Bit) mit zusätzlichem DMA-Controller. Alles andere ist Krampf!
Ähm, 480x272 kann man auch als 30x17 Zeichen mit 16x16 Pixel Buchstaben ansehen. Dann bist Du bei 510 Bytes plus Farbe. Nicht jeder braucht Vollgraphik. Über SPI kann man mit einem 16 MHz ATMega Pixel mit 8MHz ausgeben. Da allerdings nur ein Bit. Beschränkt man sich darauf vorgefertigte Blöcke aus dem ROM auszugeben, so kann man alle 4 Taktzyklen ein Zeichen ausgeben. Plus 8 Taktzyklen am Anfang des Blocks. Beschränkt man sich auf 4 Bit Farbtiefe so kann man die 8 Taktzyklen auch noch während der Ausgabe der Zeichen unterbringen. Grob skizziert sähe der Code dafür so aus: (die Zahlen dahinter geben die Nummer des Taktzyklusses an)
1 | LPM r16,Z+ ;1-3 |
2 | OUT PortX,r16 ;4 Pixel |
3 | SWAP r16 ;5 |
4 | LD r17,X+ ;5-7 |
5 | OUT PortX,r16 ;8 Pixel |
6 | LPM r16,Z+ ;9-11 |
7 | OUT PortX,r16 ;12 Pixel |
8 | SWAP 16 ;13 |
9 | MUL r17,r18 ;14-15 ;in r18 steht die Breites des Blockes drin |
10 | OUT PortX,r16 ;16 Pixel |
11 | LPM r16,Z+ ;17-19 |
12 | OUT PortX,r16 ;20 Pixel |
13 | SWAP r16 ;21 |
14 | ADD r0,r19 ;22 in r20,r19 steht der Grundpointer drin |
15 | ADC r1,r20 ;23 |
16 | OUT PortX,r16 ;24 Pixel |
17 | LPM r16,Z+ ;25-27 |
18 | OUT PortX,r16 ;28 Pixel |
19 | SWAP r16 ;29 |
20 | MOVW Zh:Zl,r1:r0 ;30 |
21 | NOP !!!!!!!! ;r31 |
22 | OUT PortX,r16 ;32 Pixel |
Mit dem NOP kann man beispielsweise noch ein Dummy-Byte an den SPI geben, damit der den Takt erzeugt, oder eine externe Schaltung rücksetzen. In diesem Beispiel werden 8 Pixel, jeweils im Abstand von 4 Taktzyklen ausgegeben. Sprich mit 4MHz auf einem 16 MHz Controller. Dieses Codestück würde man dann per Macro häufig hintereinander in den Flash-Speicher speichern. Der Font bräuchte, wenn man ihn komplett implementiert, 32768 Bytes.
Wenn ich mal so blöd fragen darf, wozu? Das ganze mit einem AVR anzusteuern ist einfach langsam, erlaubt wohl kaum nen Grafik Modus (animationen ja schon garnicht) und du musst das Datenblatt des Displays dafür wohl eher als "guter Rat" interpretieren. Außerdem brauchst du einen AVR mit viel Speicher und so, da ists dann auch schon nicht mehr so billig. Einfacher und besser wäre ein CPLD dafür. Da hängst du einen kleinen externen S(D)RAM ran als Grafikspeicher und schon hat sich das. Wenn du einen kleinen CPLD nutzt kannst du das bestimmt auf die größe eines DIP AVRs bringen. Naja gut, flüssige Animationen kriegst du auch damit nicht hin, weil du dafür wohl eher einen doppelten Framebuffer bräuchtest und ein schnelleres Interface als SPI, sonst kriegst du die Displaydaten da kaum schnell genug rein um 60, ja sogar 30 FPS zu schaffen. Ich habe übrigens ein ähnliches Display bei Dealextreme bestellt, auch 480x272 Pixel, allerdings 24bit Farben und habe dafür schonmal einen Treiber in VHDL geschrieben, im Simulator läufts, habe leider das Display noch nicht geliefert bekommen. Das ist jedenfalls kein Problem, ich kann mal testen ob das in einen CPLD passt (wenn nicht habe ich verdammt schlecht programmiert).
> Nicht jeder braucht Vollgraphik.
Mag sein, aber das Display braucht Vollgrafik :-)
Naja: a) Ein CPLD ist ein externer Chip der in der Regel nur in SMD-Gehäusen => nicht Hobbytauglich verfügbar ist. Dazu kommt noch der Aufwand dazu eine Entwicklungsumgebung zu bekommen. b) Wenn Du meinen obigen Beitrag gelesen hättest, so würdest Du sehen, dass man damit problemlos auch schon mit kleineren Controllern schnelle Graphiken machen kann. Beispielsweise gibts da Uzebox. http://www.youtube.com/watch?v=-lRbSeZ7c6Y
Entwickler schrieb: >> Nicht jeder braucht Vollgraphik. > > Mag sein, aber das Display braucht Vollgrafik :-) Naja, das Problem dabei ist, dass es keine Displays zwischen "nur Text" und "Vollgraphik" gibt die so wirklich gut sind und nicht übermäßig teuer.
>a) Ein CPLD ist ein externer Chip der in der Regel nur in SMD-Gehäusen >=> nicht Hobbytauglich verfügbar ist. Und für das Display brauchst du natürlich keine SMD Technik oder? Mal ehrlich, wenn man schon eine Platine macht kann man auch noch einen kleinen Chip mehr draufklatschen. >Dazu kommt noch der Aufwand dazu >eine Entwicklungsumgebung zu bekommen. Naja, nimm halt nen CoolRunner2 oder sowas, die Xilinx ISE gibts gratis, zumindest die Version, die dir locker reicht. >b) Wenn Du meinen obigen Beitrag gelesen hättest, so würdest Du sehen, >dass man damit problemlos auch schon mit kleineren Controllern schnelle >Graphiken machen kann. In deinem Post geht es um Text. Und schon dafür brauchst du schon einen riesigen AVR, mindestens 64k Flash. Die haben dann in etwa 60 Pins, wenn du das in DIP nimmst hast du schonmal einen riesen Displaycontroller. Ich sage nicht dass es mit einem AVR nicht möglich ist, ich sage nur dass es mmn. wenig sinn macht weil du kaum Luft nach oben hast. Am Schluss hast du dann ein flimmerndes Textdisplay oder so. Uzebox läuft übrigens auf einem gut 28MHz AVR.
>Naja, das Problem dabei ist, dass auch kompiziertes Spielzeug seinen Preis hat. >Ich habe übrigens ein ähnliches Display bei Dealextreme bestellt, auch >480x272 Pixel, allerdings 24bit Farben Ich staune immer, wofür Leute 24Bit Farben brauchen. Eine noch so kleine Blickwinkeländerung bringt die Farben doch schon ins Schwanken.
> Naja, nimm halt nen CoolRunner2 oder sowas, die Xilinx ISE gibts gratis, > zumindest die Version, die dir locker reicht. Xilinx ISE ist zwar vielleicht "gratis" aber das ist Software ohne Quellcode. Die ist aufwändig zu installieren. Und ich hab da keine Lust stundenlang irgendwelchen Installationsproblemen hinterher zu suchen. FPGAs und CPLDs werden dann interessant, wenn es mal wirklich freie Entwicklungssysteme dafür gibt. Und das was ich bislang im Bereich Video mit ATMegas gemacht habe war eigentlich ganz viel versprechend. Mehr braucht man in der Regel ja nicht.
Entwickler schrieb: > Ich staune immer, wofür Leute 24Bit Farben brauchen. Eine noch so kleine > Blickwinkeländerung bringt die Farben doch schon ins Schwanken. Klar, wobei ich aber eher glaube, dass es denen um das Quantisierungsrauschen geht. Will man Farbübergänge oder Photos darstellen nervt das wirklich... aber dann würde ich wahrscheinlich wirklich was schnelleres nehmen als einen ATMega.
>Klar, wobei ich aber eher glaube, dass es denen um das >Quantisierungsrauschen geht. Da rauscht eher etwas im Kopf, das Teil mit der größten Zahl muß das beste sein. Ich denke dabei immer an die Millionen von Fliegen auf dem Haufen. Für eine "normale" technische Anwendung (Schrift, Grafik, Bedienterminal) reichen meines Erachtens 8 bis 64 Farben locker aus.
Entwickler schrieb: > Da rauscht eher etwas im Kopf, das Teil mit der größten Zahl muß das > beste sein. Ich denke dabei immer an die Millionen von Fliegen auf dem > Haufen. Naja, besonders in Kombination mit MPEG-artiger Kompression merkt man schon sehr deutlich ob man 6 Bit oder 8 Bit pro Kanal hat. > Für eine "normale" technische Anwendung (Schrift, Grafik, > Bedienterminal) reichen meines Erachtens 8 bis 64 Farben locker aus. Absolut, das ist auch die Anwendung die ich potentiell machen würde.
Das Display ist ein ganz normales controllerloses Gerät mit Standard CMOS 18-Bit Schnittstelle (DCLK, HSYNC, VSYNC). Das wird "ähnlich" angesteuert, wie ein Röhrenmonitor. Also Zeile für Zeile, Punkt für Punkt. Um ein Pixel zu ändern, musst Du immer ein komplettes Bild übertragen. Wenn Du bei der Übertragung Pausen machst, verschwindet das Bild wieder. Es muss also kontinuierlich aus einem Framebuffer in das Display übertragen werden. Nur dann kannst Du mit einem AVR einzelne Pixel im Framebuffer setzen/löschen. Du brauchst also einen Controller. Oder schau Dir mal Displays mit I2C-Schnittstelle an. Die haben den Controller eingebaut. Für schnelle Animation, kann ich mir das aber nicht vorstellen.
>Ich staune immer, wofür Leute 24Bit Farben brauchen. Eine noch so kleine >Blickwinkeländerung bringt die Farben doch schon ins Schwanken. Das ding hat mich incl. Touchpanel 17€ gekostet, ist so günstig weil die in Massen für Sonys PSP produziert werden. Da nehm ich doch lieber für 17€ ein 24bit Display als für 50€ ein 8bit Display, zumal ich das ja in meinem FPGA eh umrechnen kann. Nur weil ich 24bit darstellen KANN muss ich das ja nicht auch tun. >Xilinx ISE ist zwar vielleicht "gratis" aber das ist Software ohne >Quellcode. Die ist aufwändig zu installieren. Und ich hab da keine Lust >stundenlang irgendwelchen Installationsproblemen hinterher zu suchen. Also ich weiß nicht was du hast. Die Xilinx ISE ist in etwa so kompliziert zu installieren wie Firefox. Sowohl auf Linux alsauch auf Windows. Da ists komplizierter einen GCC aufzusetzen. >Und das was ich bislang im Bereich Video mit ATMegas gemacht habe war >eigentlich ganz viel versprechend. Mehr braucht man in der Regel ja >nicht. Wenn ich mir für 50€ ein Display kaufe will ich darauf aber auch mehr darstellen als ein paar Zahlen und Buchstaben. Sonst hätte ich ja wohl ein kleineres/billigeres/einfacheres (Text-)Display gekauft.
>für 50€ ein 8bit Display Wo gibt es denn so ein Display und zu dem Preis? >Sonst hätte ich ja wohl >ein kleineres/billigeres/einfacheres (Text-)Display gekauft. Und die gibt es als TFTs mit so hohem Kontrast? Ab einer gewissen Auflösung (>128 x 64) würde ich auch dann TFT nehmen wenn ich nur schwarz-weiß brauche. Dabei ist mir der Preis egal, wenn dafür die Anzeige gut ablesbar ist.
Siehe SSD1963. Der sollte als Controller für das genannte Display funktionieren.
Schön dass man inzwischen das SRAM mit in den Controller bekommt. Aber so vom Funktionsumfang ist das Teil schon ein klein wenig arm. So wie es aussieht ist das ein reiner Framebuffer.
Christian Berger schrieb: > Schön dass man inzwischen das SRAM mit in den Controller bekommt. Aber > so vom Funktionsumfang ist das Teil schon ein klein wenig arm. So wie es > aussieht ist das ein reiner Framebuffer. Ja. Für Grafikbefehle ist dann noch ein Prozessor mit etwas Intelligenz notwendig. zB: ebay 200536473202 Da hast Du alles komplett. Ansonsten alles in FPGA gießen. Habe davon aber leider keine Ahnung. Sonst würde ich es wohl damit machen.
Das ist schon irgendwie schade. Früher gab es einfach DIP-Chips, die hardwarebeschleunigtes Linienzeichnen konnten. RAM war natürlich extern, dafür war ein Vektorfont drin. Heute könnte man in Hardware so viele schöne Sachen machen. http://www.drcrazy.de/nkc/html/gdp64.htm
Epson hat auch noch einige Displaycontroller. Die haben (teilweise?) auch einen Zeichensetzer drin. S1D13700 (den habe ich im Einsatz) ist zB für SW bzw Graustufendisplays gedacht. Der kann auch einfache Zeichen schreiben. Grafikbefehle kennt er ebenfalls nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.