www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik TFT mittels RGB Interface ansteuern


Autor: Thomas (Gast)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Thomas (Gast)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Thomas (Gast)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Thomas (Gast)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Thomas (Gast)
Datum:

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

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.