hallo zusammen,
kurz zu meiner Ausgangslage / Problem:
ich habe ein Displaypanel vorliegen welches mit 18 Bit digital RGB
angesteuert wird.
Displaydaten:
Panel Model LB070WQ5-TD01
Panel Typ Si TFT-LCD
Panel Größe 7.0 inch
Auflösung 480 x 240, WQVGA
Aspect Ratio 17:9 (W:H)
Interface Digital parallel RGB
Interface Model FH12K-40S-0.5SH
Display Farbraum 262K (6-bit)
Nun möchte ich mit Hilfe eines FPGAs das vom Grafikcontroller
ausgesendete
untypische Format (480 x 240) dahingehend abändern, um auch in Europa
existierende Displays ansteuern zu können :). Das Problem ist hierbei,
das ich nicht auf den eigentlichen Grafikcontroller zugreifen kann, um
das Format direkt zu ändern, sondern nur die Signale abgreifen kann.
Weiterhin ist zu bedenken, dass der Grafikcontroller kontinuierlich
Videodaten ausgibt, d.h. ich greife auf keinen Speicher zurück .
Weiterhin sind laut Angaben folgende Frequenzen für Sync und clk
gegeben:
______________________________________________________
Display Signal Min Typ. Max Unit
7‘‘ WQVGA VSync 37.75 57.39 79.44 Hz
HSync 12.46 14.86 19.86 kHz
Pixel Clock 7.80 8.80 11.40 MHz
______________________________________________________
Zu meinen Überlegungen:
Ich lese die parallel vorliegenden Daten mit einem FPGA ein
(Programmierung in VHDL - hier schon etwas Erfahrung gesammelt)und
formatiere diese auf ein gängiges Format ( HVGA(480x320), VGA(640x480),
WVGA(800x640), etc...). Theoretisch müsste ich ja die Frequenzen von CLK
HSync, VSync, De, dementsprechend anpassen (Zähler). Die zusätzlich
erzeugten Pixel müssen dann iwie in Abhängigkeit der einzulesenden
interpoliert werden (noch kein Plan wie). Weiterhin benötige ich ja ein
gewisses Speichervolumen (SDRAM), um vorab sagen wir ein komplettes Bild
(18 Bit *480*240 = 254 kByte (min)) einzulesen.
bräuchte einen kleinen Schups in die richtige Richtung, da ich auf
diesem Gebiet noch keine all zu großen Erfahrungen gesammelt habe.
- Hat jmd damit schon Erfahrung gesammelt?
- geeigneter FPGA + Board + Software?
- realisierbar ? wenn ja in welchem Zeitrahmen +- ?
- nicht bedachte Problemfelder ?
MFG
Schaue Dir die Video Suite von ALTERA an. Da ist alles drin. Kostet aber
eine "Kleinigkeit". Oder Du schreibst einen Scaler selber -- habe ich
auch mal gemacht. Ist aber nicht ohne (vor allem wenn man qualitativ
hohe Qualität erreichen möchte).
In Deinem Fall wäre so ein Scaler viel einfacher aufgebaut, weil Du nur
Y Koordinate skalieren musst. Also ich vermute mal, man könnte komplett
ohne externen Speicher (Framebuffer) hinkommen, wenn man nur ein Paar
Zeilen zwischenspeichert und daraus die neuen Interpoliert.
Allerdings, falls Du noch zw. PAL/NTSC konvertieren müsstest, dann
bräuchtest Du schon einen Framebuffer.
Kest
Arg, falsch gelesen, Du möchstest ja auch andere Auflösungen
unterstützen (also nicht nur Y-verschieden)! Okay, wird etwas
komplizierter, aber theoretisch geht es immer noch ohne Framebuffer
(allerdings mit genügend Zeilem im Onchip-Ram)
Kest
Tronix schrieb:> - Hat jmd damit schon Erfahrung gesammelt?
Ja.
> - geeigneter FPGA + Board + Software?
Jeder halbwegs aktuelle FPGA kann das. Die Aufgabe an sich ist nicht
allzu aufwendig: ein paar Zähler und die RAM-Umschaltung. Mit Nachdenken
und Timinganalyse ist am meisten zu holen.
> - realisierbar ?
Ja.
> - wenn ja in welchem Zeitrahmen +- ?
Ohne VHDL-Kenntnisse und FPGA-Erfahrung bis zur Serienreife?
1 Jahr. Mindestens.
> - nicht bedachte Problemfelder ?
Evtl. brauchst du doppelt so viel Speicher, weil Double Buffering nötig
werden könnte...
Hallo,
das hört sich auf den ersten Blick schon mal ganz gut an. Danke!
Kann mir Jmd. ein geeignetes FPGA+Board nennen? Sollte nicht zu teuer
sein, d.h. ich brauche kein Superboard das noch 1000 Dinge mehr
erledigen kann. Brauche halt eines gewisse Perepherie für meine I/Os.
Würds auch selbst zusammen basteln, aber dafür fehlen mir die Mittel.
Diese Frage hat nichts damit zu tun, das ich zu faul zum suchen bin, die
Auswahl ist einfach zu groß :) und mir fehlt einfach dei regelmäßige
Praxis Erfahrung.
Ein Board zu empfehlen ist nicht einfach. Vielleicht reicht ja schon ein
DE0 oder DE1 von TErasic. Da sind 2 Erweiterungsstecker drauf, da
könntest Du Dein Display und die DAten vom Grafikcontroller anschließen.
Aber ein bisschen rechnen solltest Du schon vorher -- also ob SDRAM
Bandbreite ausmacht, ob man mit internen Speicherblöcken hinkommt und so
weiter und so fort
Kest
> Ein Spartan 3 mit externem SRAM wäre ok. Ich würde dir mal das> vorschlagen:> http://shop.trenz-electronic.de/catalog/product_in...
thx, auch nach weiterer Suche bin ich zu dem Entschluss gekommen, das
dieses Board vollkommen meinen Anforderungen entspricht.
Jetz hab ich nur noch eine Frage was die Software angeht.
ISE WEBpack ist ja laut Angaben kostenlos - d.h. downloaden und Lizenz
für ein Jahr beantragen. soweit gut. Aber gilt das nur für die private
Nutzung oder ist das auch für Unternehmen zulässig? Hab jetz Berichte
gelesen, die einen sagen ja, die anderen nein. Was stimmt den jetz?
MfG
Ramon F. schrieb:> ISE WEBpack ist ja laut Angaben kostenlos ...> Aber gilt das nur für die private Nutzung oder ist das auch für> Unternehmen zulässig?
Du kannst das Webpack auch im Geschäft verwenden.
Merke: Xilinx will FPGAs verkaufen, nicht vorrangig die Toolchain.
hi,
so komm eig recht gut zurecht, jetz hab ich aber noch eine kleine
Verständnisfrage zu den Timing Signalen. Hab mir jetz einen code
geschreiben der mir erst einmal meine VGA 640x480 / 60Hz Timing Signale
(Vsnc, Hsync, De) erzeugt.
Nun meine Frage. (Bild dazu im Anhang)
Gestartet wird ja mit der steigenden Flanke des Vsync Signals!. Läuft
das Hsync Signal immer mit, d.h. auch während der vertikalen blanking
Phase (TVp + TVs) oder startet dies erst zu Beginn von TVd (Valid Date),
also mit begin der aktiven Pixelzeilen?
THX
Versuche erst einmal das Bild in der neuen Auflösung zu zentrieren. Das
richtige Timing ist das Hauptproblem. Skalieren und zwischenspeichern
kannst du in einem 2. Schritt machen.
Einmal pro Zeile, würde ich mal behaupten, oder?
Zum generellen Timing VGA gibt es ja dies hier:
Projekt VGA Core in VHDL
Kannst Du eine Ganzzahl-Interpolation machen und schwarze Ränder
einführen? - dann ist die Interpolation mit einem einfachen Ganzzahlzoom
(Duplikation der Werte) + Kantenschärfung mit Diamantfilter möglich.
Wenn Du mit float interpolieren musst, weil Du "krumme" Werte hast,
brauchst Du ein CIC-Filter, bei hohen Ansprüchen noch ein FIR-Filter
dahinter, welches eine Kompensation / Anhebung im Bereich der
Nyquist-Frequenz besitzt.
Ich hätte da einen Core anzubieten, der das gesamte skalierbar- und
parametrierbar leistet, und auch mit nicht zusammenpassenden
Taktdomainen klar kommt, wenn also die Horizontalfrequenzen der beiden
Videotakte (In, Out) kein einfaches Verhältnis haben, oder die
Frameraten nicht passen.
Kostet aber nicht nur eine "Kleinigkeit". :-)
Gehört zwar eigentlich nicht hierhin, aber bei diesen ganzen
Video-Geschichten half mir ein BF561-Evalboard massiv zum Testen. Der
BF561 ist ein Dualcore-DSP mit zwei Videoports, auf dem
Video-Erweiterungsboard kann man auch digital-Video einspeisen bzw.
ausgeben (LVDS-Treiber). Damit liess sich zumindest mal NTSC auf VGA/PAL
konvertieren.
Wenn dann die Assembler-Geschichte steht, muss man sich seine
Algorithmen noch in die Hardware giessen (von den DSP-Tricks kann man
sehr gut auch für's FPGA lernen), und die Wahrscheinlichkeit ist gross,
dass man das Konzept nich mehr kippen muss. Schlussendlich muss man dann
allerdings auch die Rechnung machen, was entwicklungs versus
Material-technisch billiger kommt.
Grüsse,
- Strubi
hey danke für eure Kommis, hat mir bis jetzt echt weitergeholfen.
hab mich jetzt für das Spartan 3 Board entschieden und auch schon die
ersten Module soweit erstellt, simuliert und synthetisiert. läuft!!!!
nun bin ich dabei die einzelnen Datenbits einzulesen und zwischen
zuspeichern. Da sowohl mein Eingangs- als auch das Ausgangsformat mit
einer Widerholfrequenz von 60 Hz arbeiten, reicht es ja ein Frame
zwischen zuspeichern (640x480 x 18 Bit = 253,125 KByte Farbinfos).
Mein Board besitzt ein asynchronen 1 MByte ( 2 x 0.5 MByte) großen SRAM.
also 2 mal 256Kx16 SRAM (10ns)
IDEE: Ich arbeite mit beiden, auf dem einen schreibe ich die Daten, auf
dem anderen lese ich alle 1/60 Sekunde aus ( und umgekehrt). soweit gut!
Jetz fällt mir aber auf, das ich pro Taktzyklus 18 Bit Input habe aber
nur 16 Bit Input für den Speicher habe.
Da der SRAM asynchron ist, also unabhängig eines Takts arbeitet und 10ns
Zeit pro Transfer einer Zeile benötigt, kann ich doch innerhalb eines
Zyklus meines Eingangstaktes (8,8 MHz =^ 114ns), also innerhalb eines
Prozessdurchlaufes, den Adressbus ändern und somit die zwei fehlenden
Bits in die nächste Zeile schreiben oder ????????
Ramon F. schrieb:> Jetz fällt mir aber auf, das ich pro Taktzyklus 18 Bit Input habe aber> nur 16 Bit Input für den Speicher habe.
Wie sieht's mit einer Reduktion auf 5:6:5 aus? Würde Dir vielleicht 'ne
Menge Kopfweh ersparen...
ok das Thema mit der Reduktion war schon mal ganz gut.
Aber
kann ich während eines Taktzyklus den Chip einfach so wechseln. D.h.
Sequentielle Abarbeitung innerhalb des Prozesses?
Eig. steht soweit alles Aber jetz das große Problem:
Ich habe nicht bedacht, dass ich natürlich nicht parallel auf dem SRAM
lesen und schreiben kann.
Mit anderen Worten die Steuersignale WE und OE der beiden SRAMs hängen
jeweils an einem FPGA Pin (Was soll denn das ?) Somit kann ich nicht auf
dem einen Lesen und dem anderen schreiben. Oder überseh ich hier evtl.
was. Ein Denkanstoss wär echt hilfreich.
Thx
Tja wenn die Datenbusse der beiden SRAMS zu einem 32Bit Datenbus
zusammengefügt sind dann kann man das so machen. Du müßtest also noch
zwei extra pins vom FPGA nehmen und von beiden SRAMs die OEs und WE
trennen und zu den extra FPGA PINs führen. ABER ich glaube wenn die OEs
und WEs zusammen sind dann ist der Adressbus der beiden SRAMS auch
parallel geschaltet.
ja das hab ich wohl zu Begin nicht bedacht.
Ok das mit dem Speicher kann ich jetz nicht ändern, also muss ich mich
selbst verarschen.
D.h. ich versuchs erst einmal mit 30 Frames/sec. hinzubekommen, indem
ich eines schreibe, dann lese usw.
Jetz fällt mir aber noch etwas auf bei dem ich mir nicht so ganz sicher
bin. Meine Eingansdaten will/muss ich mit 8,8 MHz auf den SRAM
schreiben.
Auslesen muss ich aber mit 25Mhz. (Das Timing ist hier nicht das Problem
aufGrund unterschiedlicher Ausflösung)
Ich brauch also 2 Prozesse (8,8Mhz externer Takt und 25MHz von 50 MHz
Systemtakt runtergeteilt). Theoretisch muss ich nun aber abwechselnd
(alle 16,6 ms) den Ausgang "Adress (17 downto 0)" mit dem jeweiligen
Takt hochzählen. Und genau hier liegt das Problem. Kann ich einen
Ausgang mit mehreren Prozessen überhaupt beschreiben bzw. gibts da
irgendein Trick.?????????????????????????????????????????????????
MfG
Hallo Hallo,
da bin ich mal wieder mit einem weiteren kleinen Stolperstein.
Die Programmierung ist soweit abgeschlossen. nun will ich das ganze
natürlich auch testen.
also noch mal kurz refresh:
OUTPUT FPGA: - 18 BIT RGB
- VSync
- HSync
- DE
Alles soweit auf 640x480 @ 60Hz abgestimmt.
Testen will ich das mit meinem Monitor über DVI (TMDS).
Nur leider hab ich das dumme Gefühl, das mir niemand einen simplen
TTL - DVI Adapter verkaufen möchte. Irgendwie sind diese Dinger nicht
aufzutreiben ?????? TTL to LVDS dagegen gibts wie Sand am Meer.
Ich habe zum Bsp. einen passenden DVI TX IC von TexIns gefunden
(TFP410), der ohne HDCP läuft (brauch ich nicht).
http://www.ti.com/lit/ds/symlink/tfp410-ep.pdf
Weiterhin brauch ich auch keinen DDC. Kann ich denn einfach so weg
lassen? Geb ja ein vordefiniertes stand. Format aus, was der Monitor
defenitiv kennt. (Laut Datenblatt funkt das auch so, indem ich I^2C
deaktiviere).
Entsprechende Layoutplatine gibts auch fürn Euro. Problem is hierbei das
Löten des Chips (0,5mm Abstand), no way!!
Also zu meinem Gesamtproblem: Wie bekomm ich meine Daten am schnellsten
auf meinen Monitor. Kennt jmd. evtl. ein passendes Modul? (Bitte bedenkt
das das hier mein Hobby ist, bevor ich mir anhören darf wie unpraktisch
das doch ist ohne DDC etc.. Erst wenn das mal läuft gehts weiter :) )
Danke
Ramon F. schrieb:> TTL to LVDS dagegen gibts wie Sand am Meer.
Was nun? TTL zu LVDS (das kann jades aktuelle FPGA) oder TTL zu DVI?
Ramon F. schrieb:> Kann ich denn einfach so weg> lassen?
Ja. Damit kannst Du nur die Kennung und die Eckdaten vom Monitor
auslesen. Nett, aber nicht zwingend notwendig.
Duke
Ne ne suche einen TTL to DVI Adapter (ohne HDCP, ohne DDC, ganz simple)
ums am Monitor zu testen !!
der TPF410 von TexIns kann das ja, nur bevor ich jetz 50 - 60 Euro pro
Material (Chip + Platine) und Bestückung bezahle gibts da doch bestimmt
einfachere und billigere Lösungen oder ??
MfG
Ramon F. schrieb:> der TPF410 von TexIns kann das ja, nur bevor ich jetz 50 - 60 Euro pro> Material (Chip + Platine) und Bestückung bezahle gibts da doch bestimmt> einfachere und billigere Lösungen oder ??
Ich denke viel günstiger wirst Du nicht kommen.
Du kannst Dir auch mal den Schaltplan vom Xilinx SP605 anschauen
(xtp067.pdf). Dort wird ein Chrontel CH7301C verwendet.
Duke
hey vielen dank Duke aber ich würde doch gern auf eine fertige Lsg
zurückgreifen und evtl ein paar EUR mehr ausgeben, da ich mich nicht so
gut damit auskenne, zumal ich das ganze erst einmal nur simple testen
möche, bevor ich das ganze komplett alles hardwaretechnisch umsetzen
werde.
die Boards die ich gefuunden habe können halt noch 1000 sachen mehr!
gibts denn kein kleines TTL to DVI/Tx Extension Board ?????????
MfG
Dieses Board (mehr als 2 Lagen zu kaufen bei mouser.com) verwendet den
TFP410.
Vielleicht kannst du den LVDS entfernen und die Signale direkt
einspiesen
oder du verwendest einen TTL-LVDS umsetzer
oder dein FPGA erzeugt LVDS direkt.
http://www.congatec.com/de/produkte/zubehoer/dView/conga-ldvi.html
Hallo zusammen,
Ich habe mich nun auf LVDS festgelegt. Und nun prompt kommt das nächste
Problem wobei ich euere Hilfe/Erfahrung gebrauchen könnte.
Ich möchte dem DC DC Wandler LT1932 gerne zur Ansteuerung meines
LED-Backlights verwenden !
Ich besitze folgendes Display : NEC NL6448BC20-21D , 6,5''
Daten zum Backlight siehe Abbildung!!!!
Also laut Angaben brauch ich ja 60mA (10mA pro String). Da dieser nur
max. 40mA kann, möchte ich 2 davon verwenden, jeweils mit 30mA (einer
jeweils für 3 Strings)
so jetz brauch ich ja 26,82V LED Voltage.
Ich verstehe nicht so ganz wie ich meine Ausgangsspannung (Pin 1,SW)
regeln kann. Den Strom regel ich ja über den Widerstand R_set = 750Ohm
(Pin 4) (entspricht dann 30mA) aber wie regel ich nun die
Ausgangsspannung?
Das Ganze möchte ich mit Hilfe meines FPFGA-Boards realisieren, d.h. ich
habe für Vin 3,3 bzw. 5V zur verfügung
Könnt Ihr mir da evtl weiterhelfen?
MFG
Bei solchen Fragen (habe ich nicht durchgelesen) würde ich im
Elektronik-Forum posten und nicht hier bei FPGA. Da sind auf jeden Fall
"kompetentere" Leute unterwegs.
Grüße
Kest
Ramon F. schrieb:> aber wie regel ich nun die> Ausgangsspannung?
Na die stellt der Regler soweit er kann passend ein... Du kannst ja
nicht Spannung UND Strom gleichzeitig vorgeben...
Hallo zusammen,
soweit läuft alles dementsprechend. Nun möchte ich ein bestimmtes
Startbild darstellen.
Kennt von euch jmd ein passendes Programm (freeware), welches mir ein
Bild in einer Art Pixel matrix ausgibt (Farbtiefe wählbar wär ganz
nett).
Selbst umrechnen würde etwas dauern :)
MfG
Schau dir mal Gimp an.
Der kann ein paar lustige export Formate wie z. B. C Code & Header
Datei. Nützlich für ähnliche Tests und Basteleien mit uCs. Weiss grad
nicht auswendig was für dich grad passend wäre, aber ein Blick in die
Gimp export Formate ist es sicher wert.
hi
Zu der DVI Adapter Geschichte möchte ich nur noch etwas Senf dazugeben:
einige Fpgas können auch direkt mit Tmds umgehen also kann man DVI und
HDMI ein und Ausgänge ohne externe Signalwandler handhaben, wenn man
entsprechend beschaltete und konfigurierte ios verwendet. LVDS ist
andererseits die bevorzugte Schnittstelle wen es darum geht größere
panels anzb Laptop anzusteuern (siehe auch Display Port)
Hallo zusammen,
also ich wende mich ein letzes mal an euch da ich es seit geschlagenen 2
wochen nicht hinbekomme das System einwandfrei zu laufen zu bekommen.
Noch mal kurz die zusammenfassung:
Ich habe ein Spartan 3 Board von Digilent.
Am Eingang habe ich Videoaten im Format WQVGA (480x240) vorliegen. CLK:
8,8Mhz, 18 Bit RGB + DE
Ausgabe erfolgt über das VGA_Format (640x480@60Hz) an ein RGB Display.
Mein in VHDL erstelltes Timing-Modul funktioniert soweit auch
einwandfrei!
Da ich die Daten vorerst nicht scalen möchte habe ich diese
(480x240)mittig in (640x480) platziert und den äußeren Rand schwarz
gelassen.
Nun habe ich ein VHDL_Modul geschrieben (siehe Data_Converter.vhd),
welches mir die Daten eines Einzelbildes einliest und jeden Pixel in
einer SRAM Adresse ablegt. (Datenreduzierung um 2 Bit da die Adresse nur
platz für 16 Bit besitzt)
Darauffolgend möchte ich das Bild dauerhaft ausgeben bzw. jede sec.
einmal aktualisieren.
Nun zu meinem problem: Getestet habe ich das ganze indem ich mir eine
Art "Picturesimulator" in VHDL geschrieben habe (inkl. DE und Takt), der
dauerhaft Daten sendet. Mit diesem Simulator funktioniert mein
Data_Converter Modul einwandfrei. Die Datensätze werden genau wie
vorgegeben auf dem Display angezeigt.
Wenn ich mein FPGA mit den externen Daten (Clk, De, RGB) speise, kommt
teils teils nur schwachsinn bei rum. Problem ist, er erkennt die daten,
ordent sie aber falsch auf dem Display an. z.B. sind mal die ersten 4
Zeilen und zeile 89-120 richtig, dafür ist der rest total verschoben.
etc etc. schwer zu erklären. Ich bin zu dem entschluss gekommen (nach
1000den von tests) das es eig nur an der VHDL programmierung liegen
kann. Er erkennt den Bildanfang, den Clk sowie De und auch die RGB Daten
sind korrekt, nur halt falsch angeordnet. Teilweise liest/ schreibt er
den Speicher erst gar nicht kommplett mit 240x480 = 115200 Adressen voll
sondern zeigt wiederholt einige Daten im unteren Bildaufbau wieder an.
Habe 2 Versionen im Anhang.
Video_converter.vhd ist mein ursprüngliches Modul.
In Video_converter2.vhd habe ich versucht mein Lese/Schreibprozess zu
vereinigen, was zur Folge hatte das noch weniger zusammenhängende Daten
sichtbar waren. Weiss leider echt nicht mehr weiter!
ich weiss es ist jetz evtl etwas aufwändiger sich damit zu befassen.
Also wenn jmd. von euch zeit und lust hat wäre ich euch sehr dankbar.
Ich bin leider endgültig mit meinem Latein am Ende
MfG
@Ramon F. (tronixx):
Ich sage gleich: ich habe keine Lösung für Dein Problem.
Dein Code ist nicht "sauber". Zunächst mal die Formatierung -- es ist
schwer was zu lesen. Daraus ist die Funktionalität nicht ersichtlich,
zumindest mir nicht. Wieso die Grütze rauskommt kann gut daran liegen,
dass die Clock-Trennung unsauber ist. Woher weißt Du, dass clk_8_8MHz
und clk_50MHz synchron sind? In der clk_8_8MHz-Domäne generierst Du
"zustand_Data_in", den Du dann in der clk_50MHz-Domäne abfragst...
Mhh...
Da läuft Einiges schief und ich würde Dir raten alles "from scratch" zu
machen, mit sinnvollen Signal-Bezeichnungen, FIFOs für Daten (zur
Domain-trennung) und und und. Klar, es ist ein Schock erstmal, wenn man
alles simuliert hat und es funktioniert und dann lädt man alles runter
und es "funzt" nicht mehr ;-) Aber so ist es halt...
Grüße
Kest
Hallo Kest
ich weiss ich bin noch sehr am anfang der FPGA Welt. Aber eins musst du
mir erklären?
> In der clk_8_8MHz-Domäne generierst Du "zustand_Data_in", den Du dann in > der clk_50MHz-Domäne abfragst
Wo genau liegt hier das Problem? Was ist an sowas unsauber?
MfG
> Wo genau liegt hier das Problem? Was ist an sowas unsauber?
Kannst du in einem solchen Fall GARANTIEREN, daß die Setup und Hold
timings eingehalten werden ?
