www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Displaysteuerung mit XC9572


Autor: Grobi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
meine Idee ist es für ein VGA display was ich noch im Keller liegen habe 
einen controller zu basteln. Display ist ein VGA6448C-8.2 (640*480 RGB)
Da im Datenblatt etwas von 120Hz Framefrequenz steht gehe ich mal davon 
aus das ein avr viel zu langsam ist die benötigte Menge an Daten zum 
Display zu schaufeln. Aber wie wäre es denn wenn man einen schnellen 
(16MHz) avr hätte der über SPI (8MHz) Kommandos an einen CPLD schickt 
z.B. XC9572-10 PLCC44 3.3V (wenns geht würde ich gerne den nehmen da der 
nich all zu teuer ist und sich auch noch in der keller-hobby-werkstatt 
verarbeiten läßt) dieser dann einen Displayspeicher (ca. 1MB cache mem 
von nem pc motherboard müsste doch reichen) verändert und dessen Inhalt 
auch kontinuierlich zum Display überträgt. Das dürfte eigentlich für ne 
einfache GUI oder sonstige Textanzeigen etc. doch völlig ausreichen. 
Will ja kein Video wiedergeben.
Leider verstehe ich das Timing (Seite 10, 11) aus dem Datenblatt nich so 
ganz und habe noch nie einen CPLD in der Hand gehabt (erfahrung mit avrs 
ist genug vorhanden).
Könnte sich das vielleicht jemand mal anschauen und mir sagen ob das 
ganze überhaupt so realisierbar ist und zur Not das Timing mal erklären 
wann welche Daten wo anliegen müssen etc. ?

Mfg Grobi

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja sowas in der Richtung nur halt direkt für mein Display.
Die Seite hat mich auch zu der Idee inspiriert :-)

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm ich frag mich grad ob das überhaupt zeitlich so funktioniert, wenn 
zum display 640*480*RGB = 921600 bytes übertragen werden müssen * 120Hz 
(Framefrequenz) = 1119744000 bytes / sek. Heißt doch dann : pro ns muss 
ich 0,11197 bytes übertragen, habe also für 1 byte 8,93ns Zeit. Da das 
Display mit upper und lower column data arbeitet die zusammen übertragen 
werden also 16Bit kann ich ja pro 10ns 2 byte übertragen oder?! Was ja 
nur für den Vorgang des Daten an das Display schreiben ausreicht, aber 
wenn jetzt noch der Speicher dazukommt der ja auch ausgelesen werden 
muss, und das SPI wodurch ja auch in den Speicher geschreiben werden 
muss, wird das ziemlich eng oder?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso zu der Idee inspiriert? Das ist doch schon fertig ...

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwas kommt mir an den 120Hz Panel-Frequenz seltsam vor ...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 120Hz Panel-Frequenzn seltsam...
Ja, üblich sind bei TFTs 60 Hz,
denn es kommt aus dem Land des sternengesprenkelten Banners... ;-)

Aber, jetzt kommts: das ist ein Dual-Scan (vermutlich DSTN-)Display.
Das hat praktisch 2 Displays (oben und unten), die parallel eingetaktet 
werden. Es kann von sich aus nur die Grundfarben und deren Mischungen. 
Für feinere Farbabstufungen müssen die einzelnen Pixel mit einem 
Zufallswert zwischen an und aus umgeschaltet werden (PWM).

Ich denke, du wirst mit einem CPLD nicht arg weit kommen. Für die 
Aufgabe würde ich schon in die Richtung eines kleine FPGAs (MachXO von 
Lattice) tendieren.

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mist, ich hatte mir schon sowas gedacht, wäre ja auch zu einfach 
gewesen. Aber is ausgeschlossen das es nich vielelicht doch nur mit 60Hz 
betrieben werden muss und die einfach 120 geschrieben haben wegen den 
sozusagen 2 displays in einem? :-)

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

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller wrote:
> Aber, jetzt kommts: das ist ein Dual-Scan (vermutlich DSTN-)Display.
> Das hat praktisch 2 Displays (oben und unten), die parallel eingetaktet
> werden.

Genau.
Das Display benötigt daher 640xRGB*480 Bits pro Frame = 115,2kByte. Bei 
120Hz sind das 13,8MByte/s. Da man die Daten aber am besten als 
8bit/Pixel speichert, werden 36,9MByte/s daraus. Das ist ziemlich viel. 
Wenn man immer 2x liest und einmal schreibt, benötigt man 55,4MHz 
Datenrate am SRAM, dafür reicht aber ein 15ns RAM.

> Ich denke, du wirst mit einem CPLD nicht arg weit kommen.

Kommt auf den CPLD an. Ein XC9572 im PLCC44 ist definitiv zu klein, 
alleine schon von den Pins her.
Mit einem XC95108 habe ich ein 320x240 LCD in einen SW Monitor mit 
Videoeingang verwandelt. Für ein 640x480 Farbdisplay würde ich aber 
mindestens einen CPLD mit >150Macrozellen verwenden. Ein FPGA ist 
natürlich die ideale Lösung, da man hier nicht so schnell an die Grenzen 
stößt.

Grobi wrote:
> mist, ich hatte mir schon sowas gedacht, wäre ja auch zu einfach
> gewesen. Aber is ausgeschlossen das es nich vielelicht doch nur mit 60Hz
> betrieben werden muss und die einfach 120 geschrieben haben wegen den
> sozusagen 2 displays in einem? :-)

Nein. Die 120Hz kommen daher, da durch die PWM die effektive Framerate 
niedriger wird, da manche Pixel nur z.B. alle 4 Pixel an sind.
Wenn du nicht viele Graustufen benötigst, kannst du bis auf 60Hz 
runtergehen.

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmm vor nem fpga grauts mir ein wenig, denke nich das man da ohne 
fertige boards auskommt und das geht bestimmt ins Geld.
hmmm hab ich mich so verrechnet? Wie kann denn ein 15ns ram ausreichen? 
wenn ich doch 2mal lesen muss (was ja min 30 ns dauert) aber die beiden 
bytes  innerhalb von ~17ns am display sein müssen?

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok jetzt kapier ich das erstmal, durch die hohe pwm frequenz kommt erst 
die farbmischung zu stande. narf, am besten ich setz es bei ebay rein 
und versuch mir eines zu schießen womit das ganze klappen könnte. Oder 
sieht da jemand noch ne möglichkeit?

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

Bewertung
0 lesenswert
nicht lesenswert
Grobi wrote:
> hmmm vor nem fpga grauts mir ein wenig, denke nich das man da ohne
> fertige boards auskommt

Ein FPGA ist auch nicht schlimmer als ein CPLD, nur größer.
Ich habe mir auch ein 150MS/s 3 Kanal Oszilloskop mit einem FPGA auf 
Lochraster aufgebaut. Sowas ist zwar nicht empfehlenswert, aber es 
funktioniert.

> hmmm hab ich mich so verrechnet? Wie kann denn ein 15ns ram ausreichen?
> wenn ich doch 2mal lesen muss (was ja min 30 ns dauert) aber die beiden
> bytes  innerhalb von ~17ns am display sein müssen?

Wie kommst du auf 17ns?
640x480x120Hz=36,864MHz -> 27ns

Bei 2 von 3 Takten zum Lesen, muss der SRAM Takt um 3/2 schneller sein, 
als der Pixeltakt, also 55,3MHz haben. Das sind 18ns.

Grobi wrote:
> am besten ich setz es bei ebay rein

Erwarte nicht, dass dieses Display die Versandkosten übersteigt. In 
letzter Zeit sind TFTs zu billig geworden, als dass sich noch jemand für 
solch ein DSTN Display interessieren würde. Außer er benötigt zufällig 
genau dieses als Ersatzteil.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> In letzter Zeit sind TFTs zu billig geworden,...
... und genau aus diesem Grund würde ich so ein TFT-Display als 
Plattform für eine neues Design und zum Lernen auswählen. Auch wenn du 
eines erwischst, das "nur" eine LVDS-Schnittstelle hat: kein Problem, 
bei FPGAs ist das Standard. Obwohl ich für den ersten Versuch ein 
paralleles Interface vorschlagen würde (daran lässt es sich einfach 
besser messen).

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok vielen Dank für die tips und Hilfen...
...aber das display kommt wieder zurück in den Schrank wo es herkam, 
werde mich nach nem güntigen einfachen kleinem tft umschauen, da gibts 
ja genug beispiele das es funktioniert.

Grobi

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

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller wrote:
>  Auch wenn du
> eines erwischst, das "nur" eine LVDS-Schnittstelle hat: kein Problem,
> bei FPGAs ist das Standard.

Die TFTs die LVDS haben, sind meist 1024x768. Die haben dann 65MHz 
Pixeltakt was einer LVDS Datenrate von 3x 450MBit/s ergibt. Ein Spartan 
3 ist irgendwo bis 300MBit/s spezifiziert. Mit anderen Worten: Um einen 
externen LVDS Encoder kommt man nicht herum.

> Obwohl ich für den ersten Versuch ein
> paralleles Interface vorschlagen würde (daran lässt es sich einfach
> besser messen).

Ich würde generell erstmal mit einem kleinen TFT anfangen (320x240 bis 
max 640x480.) Die 65MHz Datenrate für ein 1024x768 TFT muss man erstmal 
irgendwo hernehmen. Ein (DDR) SDRAM ist bei sowas dann schon alleine von 
der Größe her empfehlenswert.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die TFTs die LVDS haben, sind meist 1024x768.
Bei 800x600 gehts los, dort ist der Schnittpunkt zwischen LVDS und 
parallelem Interface. 640x480 sind zwar auch schon mit LVDS erhältlich, 
aber sehr rar gesät.

> Ein Spartan 3 ist irgendwo bis 300MBit/s spezifiziert.
> Mit anderen Worten: Um einen externen LVDS Encoder kommt man nicht herum.
Diese 800x600 können mit einem Pixel-Takt von 40MHz 
(-->LVDS-Takt=280MHz) gerade noch so in einem Spartan 3 implementiert 
werden. Aber dann sind wir schon weit weg vom CPLD ;-)

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...hmpf ich will die sache irgendwie noch nich aufgeben...
was wäre denn wenn man das ganze etwas aufteilt, ein cpld macht nur die 
display steuerung also daten annehmen und ans display schicken, da 
müsste der speed reichen (data setup time min 10ns, data hold time min 
10ns, clock pulse width min 15ns laut datenbl. S.11) das kann der 9572 
schaffen und genug ios hätte der dann auch. Der 2te cpld kümmert sich um 
den speicher (2 rams die adressen parallel geschaltet so das mit einem 
read 2 bytes eingelesen werden) und stellt die Daten für den 1. cpld 
bereit und sagt ihm das er die daten schicken kann. Wenn ich das soweit 
richtig verstanden habe kommen die farben doch zustande indem im 1.frame 
nur den rot anteil gesendet wird für jeden pixel, im 2. Frame der Grün 
anteil, im 3. Frame der Blau anteil, dann im 4. wieder rot, 5.Frame 
grün, usw. oder???

doof is auch das R*ichelt z.B. den 9572 nicht als 5ns variante auf lager 
hat.
Eb*y gibt leider momentan nich so viel her was displays mit 640x480 mit 
parallel interface betrifft und P*llin hat nix vergleichbares da ausser 
genauso einem Teil was ich vor mir liegen habe, höchstens noch s/w 
320*240 aber da is sogar vhdl code dabei um nen passenden controller zu 
modellieren.

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

Bewertung
0 lesenswert
nicht lesenswert
Grobi wrote:
> was wäre denn wenn man das ganze etwas aufteilt, ein cpld macht nur die
> display steuerung also daten annehmen und ans display schicken, da
> müsste der speed reichen (data setup time min 10ns, data hold time min
> 10ns, clock pulse width min 15ns laut datenbl. S.11)

Ich glaube du bringst da jetzt was durcheinander:
Diese Zeiten haben nichts mit der Geschwindigkeit des Speichers, und 
recht wenig mit der des CPLDs zu tun.
Diese Zeiten einzuhalten geschieht eigentlich automatisch:
Die Datenrate auf einer der 8bit Leitungen zum Display beträgt z.B. 640 
x RGB / 8 x 240 x 100Hz = 5,76MHz = 1/174ns.

Die Daten werden immer bei der fallenden Flanke übernommen, d.h. du 
gibts die Daten bei der steigenden Flanke aus. Dann hast du 87ns setup 
und 87ns hold time. Dazu kommt noch etwas Laufzeit im CPLD, aber die ist 
vernachlässigbar. Somit sind die Anforderungen erfüllt.

> Wenn ich das soweit
> richtig verstanden habe kommen die farben doch zustande indem im 1.frame
> nur den rot anteil gesendet wird für jeden pixel, im 2. Frame der Grün
> anteil, im 3. Frame der Blau anteil, dann im 4. wieder rot, 5.Frame
> grün, usw. oder???

Nein.
Schau dir mal auf Seite 10 den das TIMING CHART an.
Das erste Byte behinhaltet:
R0
G0
B0
R1
G1
B1
R2
G2

Das zweite Byte beinhaltet:
B2
R3
G3
B3
R4
G4
B4
R5

Das dritte Byte beinhaltet:
G5
B5
R6
G6
B6
R7
G7
B7

usw.

Ich habe das ganze intern so gelöst, dass ich den Speicher als ganz 
normales RGB Bild mit 8bpp aufgebaut habe. Dieser Teil läuft intern mit 
dem Pixeltakt.
Bis zu dieser Stelle ist der Code identisch für ein TFT und ein passives 
LCD. Mit dem Pixeltakt läuft auch die PWM/Dither Stufe für die 
Graustufen die in jedem Takt 1bit R/G/B Pixel rauswirft. Diese Daten 
werden dann zu den Bytes für das Display zusammengefasst. Sobald ein 
Byte voll ist, wird dieses ausgegeben. Das führt dazu, dass der Takt zum 
Display etwas ungleichmäßig ist, da mal 2 und mal 3 RGB Bytes in ein 
Byte passen. Aber dieses Verhalten hat jeder LCD Controller, es ist 
daher auch nicht störend.

> doof is auch das R*ichelt z.B. den 9572 nicht als 5ns variante auf lager
> hat.

Der ist auch unnötig. Das Display benötigt eine Datenrate von <10MHz, da 
reicht selbst der langsamste CPLD aus.
Jedes noch so komplexe Logikgebilde kann man beschleunigen indem man 
eine Piplinestruktur einbaut, also Register einfügt und so die Laufzeit 
auf zwei Takte verteilt. Dann kommt das Ergebnis zwar erst einen Takt 
später an, aber die Taktfrequenz kann höher gewählt werden.
Aber wie gesagt: Mit einem 9572 kommst du nicht sehr weit. Das Problem 
ist aber nicht die Geschwindigkeit, sondern die Makrozellen. Ein XC95144 
würde ich als Untergrenze ansetzen.

> Eb*y gibt leider momentan nich so viel her was displays mit 640x480 mit
> parallel interface betrifft

Bei Ebay findet man vor allem Laptop und PC TFTs und die fangen 
mittlerweile bei 1024x768 an. Alles andere ist teuer und selten.

Autor: Grobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ohhh das erklärt so einiges! Vielen Dank!!! Ich hatte immer gedacht das 
pro pixel 3 byte übertragen werden aber das sind ja nur 3 bit! Do'h! 
und man benutzt praktisch aber ein byte pro farbe wobei das bitmuster 
halt angibt ob das bit überhaupt gesetzt werden soll um Farbabstufungen 
darstellen zu können bzw. je kleiner ich den speicher pro bit halte 
desto weniger farben hab ich zur auswahl. Ok ja dann is das ja doch nich 
so ein riesen problem und falls ich mich nem größeren cpld anfreunden 
kann wirds auch funktionieren. Super! Nochmals vielen Dank!!!

Grobi

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.