mikrocontroller.net

Forum: FPGA, VHDL & Co. TFT Anschluss mit FPGA / CPLD / AVR


Autor: Christian K. (christian_k)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Hobby/Geschäftsbastler,

Ich habe ein kleines Verständnisproblem. Ich habe von einem Kollegen ein 
TFT-Display geschenkt bekommen. Das Datenblatt dazu findet ihr im 
Anhang.
Jetzt habe ich zwei große Fragen:

1. Im Datenblatt auf Seite 16 bzw. 8-6/6 findet ihr die 
Anschlussbelegung der Anschlussbuchse (typische LIF/ZIF Version). Da ist 
von 6 Bits für jede Farbe die Rede, ich kenne aber nur die drei 
Bit-Variante MSB -> 2. Bit -> LSB
Nun die Frage: Muss ich hier eine andere Ansteuerungsart verwenden bzw. 
eine andere Ansteuerungsschaltung, da hier ja 6 Bits für jede Farbe 
verwendet werden ?

2. Es wird überall im Zusammenhang mit (TFT)Displays sehr oft von FPGA's 
/ CPLD's als Videoansteuerung gesprochen. Ich habe einmal gaaanz grob 
:-) ein Bild hingekritzelt, Anhang 2, wie ich mir die Darstellung auf 
dem TFT denke.(ja, ohne Farbe, nur s/w, oder sonst irgendwelchen 
Spielereien.)
Würde Ich das auch mit einem AVR hinkriegen ? z.B Atmega32 ?
Oder muss ich doch zu einem FPGA/CPLD greifen ? Wenn ja, dann wäre die 
Sache gestorben, denn die Welt der FPGA/CPLD will mir nich so richtig in 
Kopf. Verstanden hab ich die Materie einigermaßen: Man programmiert 
einen IC mit Logikgattern und FlipFlops und dem Zeugs in VHDL oder ABEL 
oder Verilog, daraus werden dann die integrieten Schaltkreise im 
FPGA/CPLD gebildet. Aber wie in Gottes Namen kann ich dann so eine 
Ansteuerung für ein Display machen, da müsste ich doch dann gleich ne 
halbe Grafik-CPU programmieren, oder ? :-S

Wenn irgendjemand n Denkansatz für mich hätte, wäre ich euch sehr 
dankbar.

bis die Tage,

euer christian_k

edit: Wenn ich im falschen Forum hiermit bin, Bitte an die Moderatoren, 
mich in die richtige Ecke verschieben. Danke !

Autor: dave (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Da ist von 6 Bits für jede Farbe die Rede, ich kenne aber nur die drei
>Bit-Variante MSB -> 2. Bit -> LSB

MSB -> 4. Bit -> 3. Bit -> 2. Bit - >1. Bit -> LSB ?

>(ja, ohne Farbe, nur s/w, oder sonst irgendwelchen Spielereien.)

Na, dann haste auch nur 1 Bit. Einfacher geht es nicht, hm? :-)

>Würde Ich das auch mit einem AVR hinkriegen ? z.B Atmega32 ?

Ja, 320x240 ist vom Timing vermutlich noch machbar.
Du hast halt nicht genug Speicher für eine komplette Bildseite und must 
deine Inhalte dann zur Laufzeit mit 'Tricks' erzeugen, aber ich behaupte 
mal, das ist nicht so wild solange deine Ansprüche in einem 
realistischen Rahmen bleiben. ;-)

>Aber wie in Gottes Namen kann ich dann so eine
>Ansteuerung für ein Display machen, da müsste ich doch dann gleich ne
>halbe Grafik-CPU programmieren, oder

Nö, wieso? Ein paar Zähler für die sync-Geschichte und evtl. 
Adresszähler für Framebuffer falls gewünscht, halb so wild.
Jedenfalls wenn du nicht gleich irgendwelche linedraw Funktionen usw. 
hardwareseitig implementieren willst.

Autor: Christian K. (christian_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dave schrieb:
> MSB -> 4. Bit -> 3. Bit -> 2. Bit - >1. Bit -> LSB ?

wie müsste ich das in diesem Fall dann ansteuern ? Mich verwirren die 
zusätzlichen Bits ein wenig...

> Na, dann haste auch nur 1 Bit. Einfacher geht es nicht, hm? :-)

OK, das hört sich ja schon mal sehr gut an. Wie realisiere ich dann mit 
dem Atmega 32 die Ansteuerung ? Hast du mir evtl. ein paar 
Schaltplan-vorlagen oder Anregungen ? Sorry für die vielen Fragen, hab 
noch nicht mit graphischen TFT( digitaler RGB) gearbeitet, nur mal hie 
und da gelesen..


> Ja, 320x240 ist vom Timing vermutlich noch machbar.
> Du hast halt nicht genug Speicher für eine komplette Bildseite und must
> deine Inhalte dann zur Laufzeit mit 'Tricks' erzeugen, aber ich behaupte
> mal, das ist nicht so wild solange deine Ansprüche in einem
> realistischen Rahmen bleiben. ;-)
>

Hm... an welche Trickkiste denkst du ? Ich hätte jetzt an einen externen 
Speicher per I2c oder SPI Bus gedacht, oder ist der zu langsam ?


> Nö, wieso? Ein paar Zähler für die sync-Geschichte und evtl.
> Adresszähler für Framebuffer falls gewünscht, halb so wild.
> Jedenfalls wenn du nicht gleich irgendwelche linedraw Funktionen usw.
> hardwareseitig implementieren willst.

OK, ich kapituliere. Das sind schon bömische Dörfer von wegen Zähler und 
Adressgeschichten, sorry :-)

Autor: dave (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie realisiere ich dann mit dem Atmega 32 die Ansteuerung ?

Alle Farbbits zusammen an einen Portpin.
Dazu musst du noch gemäß dem Diagramm auf s.12 die Signale wie Hsync, 
DTMG, DCLK erzeugen usw.
Dazu brauchts auch keinen Schaltplan, das ist ein software-Problem was 
zu lösen ist.

>nur mal hie und da gelesen..
Am Besten mal sehr gründlich das Datenblatt lesen und verstehen, wie der 
ganze Kram ablaufen soll.

>Hm... an welche Trickkiste denkst du ? Ich hätte jetzt an einen externen
>Speicher per I2c oder SPI Bus gedacht, oder ist der zu langsam ?

320x240x1Bit bei z.B. 60 Bildern/s würde eine Datenrate von 4,6Mbit/s 
nur zur Ausgabe des Bildes erfordern. Ich glaube nicht, dass das mit 
einem AVR so gut klappt. (Zwischendurch müssen ja auch noch Daten rein.) 
Dann schon eher ein paralleles SRAM.

Wenn du nicht unbedingt jeden Pixel einzeln verändern können musst, geht 
es auch ohne externen Framebuffer.
Du kannst dir im AVR z.B. einen Zeichensatz aus 8x8 Pixel blöcken 
erstellen und dann damit arbeiten.
Es gibt div. AVR VGA-Terminal Projekte, schau dir die mal an und lass 
dich inspirieren. :-)

>Das sind schon bömische Dörfer von wegen Zähler

Schau dir einfach mal die timing charts auf Seite 12 an und überlege 
dir, wie man zyklisch solche Signalformen erzeugen könnte. Vielleicht 
kommt dir dann eine Idee.

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

ich habe zufälligerweise vor kurzem so etwas entwickelt und dann auf der 
embedded display conference einen Vortrag drüber gehalten. Daher kann 
ich dir aus Erfahrung sagen, dass das Ganze nicht besonders aufwändig 
ist, allerdings schon ein FPGA-Design erfordert. In meinem Fall habe ich 
den Display Controller, der die Daten- und Timing-Signale für das 
Display erzeugt, im FPGA realisiert, und dem FPGA einen externen 
Speicher für die Bilddaten spendiert. Das führt zur Frage, wie die 
Bilddaten in den Speicher kommen. Dazu habe ich einen NIOS-Prozessor in 
das FPGA gesetzt, der vom Hauptrechner die Daten via SPI annimmt und in 
den externen Speicher schreibt. Alles in allem überschaubar und trotzdem 
sollte man für so etwas einige Erfahrung im FPGA-Design haben.

Unsere Firma veröffentlich solche Designs zum Teil. Schau doch mal nach 
bei embedded-platform.com -> download -> ADON02, so heißt das Board. Du 
müsstest Dich zwar registrieren, aber wir nerven unsere User nicht mit 
Mails etc.

Grüße,
Harald

Autor: Steffen H. (avrsteffen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab sowas auch schonmal mit einem Xmega128A1 probiert. Allerdings im 
5-5-5 er Format. Also jeweils 5 Bit je Farbe. Eventfunktionen benutzt, 
Xmega übertaktet und trotzdem war das Resultat ernüchternd. Das ist eine 
verdammt hohe Datenmenge die da kontinuierlich ins TFT geschaufelt 
werden muss. Ich hatte da einen 16Mb SDRAM dran hängen. Allerdings 
können die Xmegas bloß 4Bit´s lesen in einem Zyklus. Das bremste die 
ganze Sache so ungemein aus.

Hier mal der Link dahin
Beitrag "Re: Xmega Programmierung in ASM"

Grüße
Steffen

Autor: Christian K. (christian_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Leute,

tut mit leid, aber ich war krank mit 40°C Fieber. Musste also alles ein 
bischen warten.

@dave
> Dazu brauchts auch keinen Schaltplan, das ist ein software-Problem was
> zu lösen ist.

ähm... ok, wie kann ich die Timer dazu missbrauchen ? So dass diese im 
passenden Verhältnis sind ?


> Dann schon eher ein paralleles SRAM.

Welchen Atmega kannst du mir empfehlen, der nen passenden Anschluss für 
nen parallelen SRAM hat ?


> Wenn du nicht unbedingt jeden Pixel einzeln verändern können musst, geht
> es auch ohne externen Framebuffer.
> Du kannst dir im AVR z.B. einen Zeichensatz aus 8x8 Pixel blöcken
> erstellen und dann damit arbeiten.

Hast du ne Bascom-Lösung oder Ansatz ?

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]
  • [vhdl]VHDL-Code[/vhdl]
  • [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.