Hallo zusammen!
Und zwar hab ich mal eine Frage bzgl. des RGB Interfaces(18Bit) eines
TFT. Hab ich das so richtig verstanden, dass der TFT in einem gewissen
Takt über das RGB Interface Pixel für Pixel mit dem dazugehörigen
Farbwert aktualisiert werden muss. Also muss, wenn ich zB. die Uhrzeit
ausgeben will, für jede Zahl ein Bitmap o.ä. im Speicher abgespeichert
werden und dieses dann an der jeweilgen Stelle eingefügt werden muss.
Ich habe nur bei diesen TFT'S eine Grafik bzw. Textunterstützung
gefunden:
http://www.lcd-module.de/produkte/ediptft.html
Das Display sollte nämlich um die 3" haben, Auflösung 320x240 und Touch.
Wäre es theoretisch möglich, das mit einem ATMega128 zu betreiben, wenn
das Diplay Minutenweise neu geladen werden soll. Oder reicht das nicht
aus und ein ARM ist dafür nötig?
Danke schon mal für Hilfe->wäre echt Klasse.
Gruß Thomas
Thomas wrote:
> Hab ich das so richtig verstanden, dass der TFT in einem gewissen> Takt über das RGB Interface Pixel für Pixel mit dem dazugehörigen> Farbwert aktualisiert werden muss. Also muss, wenn ich zB. die Uhrzeit> ausgeben will, für jede Zahl ein Bitmap o.ä. im Speicher abgespeichert> werden und dieses dann an der jeweilgen Stelle eingefügt werden muss.
Ja.
> Wäre es theoretisch möglich, das mit einem ATMega128 zu betreiben, wenn> das Diplay Minutenweise neu geladen werden soll. Oder reicht das nicht> aus und ein ARM ist dafür nötig?
Du musst das komplette Bild rund 50x pro Sekunde an das Display senden.
Der AVR wird also sehr beschäftigt sein. Ohne eingebauten
Displaycontroller wird sich da auch ein ARM schwer tun.
Oder du kaufst dir eben dieses intelligente Display, das macht das
selbst.
Ich dachte mir immer, dass das Display das Bild selbst immer wieder
aufbaut mit dem Controller.
Das Display, dass ich mir angesehen habe hat diesen Controller: S6E63D6
Wie heißen diese ARM's welche den Displaycontroller schon haben? sind
das diese: AT91SAM7X256
Danke für die Info!
Thomas wrote:
> Ich dachte mir immer, dass das Display das Bild selbst immer wieder> aufbaut mit dem Controller.
Wenn es einen Controller hat dann schon. Aber RGB Interface heißt: Kein
Controller (bzw. wenn es einen Controller hat, dann stellt sich dieser
in diesem Modus dumm).
Die mit Controller haben einen üblicherweise als Microcontroller
Interface bezeichneten Anschluss.
> Das Display, dass ich mir angesehen habe hat diesen Controller: S6E63D6
Dann ist das aber kein normales TFT sondern ein OLED.
Ja genau, das wäre ein OLED gewesen. Dachte nur, dass das von der
Ansteuerung keinen Unterschied macht:
Datenblatt: http://www.farnell.com/datasheets/44143.pdf
Auf Seite 16 ist es halt mit RGB Interface gestanden und ich dachte,
dass die 18Datenleitung, Sync usw für das RGB typisch sind?
Thomas wrote:
> Ja genau, das wäre ein OLED gewesen. Dachte nur, dass das von der> Ansteuerung keinen Unterschied macht:
Die Ansteuerung ist an sich die gleiche. Nur die Init ist bei diesem
Display etwas komplizierter (bzw. bei einfachen TFTs ohne Controller ist
garkeine Init notwendig).
> Auf Seite 16 ist es halt mit RGB Interface gestanden und ich dachte,> dass die 18Datenleitung, Sync usw für das RGB typisch sind?
Ja, in diesem RGB Modus wird der interne Controller abgeschaltet.
Dies ist z.B. sinnvoll wenn der µC über einen eingebauten Display
Controller verfügt.
Ansonsten würde ich einen der oberen beiden Modi auf Seite 16 verwenden,
die kann man direkt an jeden µC anschließen und braucht nur 1x das Bild
zu laden, dann zeigt der Controller das selbständig an.
ok das ist gut zu wissen; wusste ich bisher gar nicht. Dachte, dass nur
über das RGB die Daten selbst geladen werden können. Muss ich dann halt
über SPI die Daten schicken, die er dann anzeigt? Also auch Pixel für
Pixel? Muss ich diese 18 Datenleitungen dann gar nicht zum µC führen;
dachte über SPI kann man nicht alles ansteuern...
Wenn ich das Display so Minutenweise aktualisiern muss, reicht dann auch
der ATMega128? Wahrscheinlich mit großem externen Speicher noch für
Bitmaps etc?
Danke für die Hilfe!!
Thomas wrote:
> Muss ich dann halt> über SPI die Daten schicken, die er dann anzeigt? Also auch Pixel für> Pixel? Muss ich diese 18 Datenleitungen dann gar nicht zum µC führen;> dachte über SPI kann man nicht alles ansteuern...
Dieser Controller kann 3 Modi:
- RGB
- 8/16/18bit µC Interface
- SPI
Bei RGB bekommt das Display kontinuierlich seine Daten im TFT üblichen
Format (RGB, Hsync, VSync mit einem konstanten Pixeltakt). Zusätzlich
ist SPI notwendig um die entsprechenden Spannungs und Timingparameter
einmalig einzustellen.
8/16/18bit und SPI sind quasi das gleiche, nur einmal parallel und das
andere mal seriell. Dann ist der interne Displaycontroller aktiv, der
das Display selbständig ansteuert. Man kann den internen Grafikspeicher
dann Pixelweise beschreiben und so nach und nach ein Bild aufbauen.
> Wenn ich das Display so Minutenweise aktualisiern muss, reicht dann auch> der ATMega128? Wahrscheinlich mit großem externen Speicher noch für> Bitmaps etc?
Ja, sollte ausreichen. Man sollte dabei nur bedenken, dass ein Vollbild
320x240x2 Bytes, also 150kByte hat. Selbst wenn der µC nur ein Byte nach
dem anderen über SPI schreiben würde, bräuchte er dann für ein Vollbild
rund 0,2s. In der Praxis werden es eher >1s sein, da die Bilddaten ja
erst noch irgendwie erstellt werden müssen (also Text in Bilddaten
umgewandelt usw.).
Dann wäre die einfachste Lösung sicher über das µC Interface oder? SPI
wäre dann ja nochmals langsamer...
Würde dann ein externer Speicher sicher nicht schaden oder(welche
Größenordnung)? es wird eh kein Hintergrundbild geben(weiß); nur einige
kleine Symbole; dann muss ich wahrscheinlich auch Buchstaben und Zahlen
einzelen abspeichern, wenn ich Uhrzeit oder einen Text ausgeben will
oder?
Kann man dann auch gezielt, einzelne Pixel aktualisieren und nicht immer
alles neu?
Danke für die vielen Infos!!
