Displaysteuerung mit XC9572

> 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.

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.

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.

> 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).

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.

> 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 ;-)

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.