www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Display Reichelt TFT-DIS 4,3 LCD-Modul Fragen zum Timing


Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ä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)
LPM r16,Z+    ;1-3 
OUT PortX,r16 ;4  Pixel
SWAP r16      ;5
LD r17,X+     ;5-7
OUT PortX,r16 ;8  Pixel
LPM r16,Z+    ;9-11
OUT PortX,r16 ;12 Pixel
SWAP 16       ;13
MUL r17,r18   ;14-15 ;in r18 steht die Breites des Blockes drin
OUT PortX,r16 ;16 Pixel
LPM r16,Z+    ;17-19
OUT PortX,r16 ;20 Pixel
SWAP r16      ;21
ADD r0,r19    ;22   in r20,r19 steht der Grundpointer drin
ADC r1,r20    ;23
OUT PortX,r16 ;24 Pixel
LPM r16,Z+    ;25-27
OUT PortX,r16 ;28 Pixel
SWAP r16      ;29
MOVW Zh:Zl,r1:r0 ;30
NOP !!!!!!!!  ;r31
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.

Autor: TokyoDrift (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nicht jeder braucht Vollgraphik.

Mag sein, aber das Display braucht Vollgrafik :-)

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Youtube-Video "Uzebox graphic demo (intro-style)"

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TokyoDrift (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TokyoDrift (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Siehe SSD1963. Der sollte als Controller für das genannte Display 
funktionieren.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.