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
ja sowas in der Richtung nur halt direkt für mein Display. Die Seite hat mich auch zu der Idee inspiriert :-)
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?
> 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.
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? :-)
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.
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?
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?
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).
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
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 ;-)
...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.
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.