Hallo *, mal ne kurze Frage an die FPGA Spezialisten: Ich habe hier ein Meßgerät mit einem Röhrenmonitor. Zusätzlich steht ein CGA-Ausgang zur Vefügung. Die Auflösung Beträgt 512x240 RGBI. Es gibt eine Bastellösung um ein VGA-Display mit LVDS-Eingang zu benutzen die zwei Baugruppen verwendet: Einmal einen CGA->VGA Konverter und dann einen Konverter VGA nach LVDS für das TFT-Modul. Wäre das nicht eine Aufgabe die man in einem einzelnen FPGA erledigen könnte? So grob würde ich mir das so vorstellen: Videodaten mit einem aus den Syncsignalen erzeugten Pixelclock ins BRAM einlesen und mit der für das Display passenden Frequenz auslesen und über einen LVDS Transmitter zum Display schicken. Die Zeilen müssten halt jeweils 2x ausgegeben werde (240->480) und rechts und links dürften schwarze Ränder sein (2x64 Spalten). Gibt es aktuell passende Hardware mit entsprechenden Tools auf dem Markt die für diese Aufgabe passen würde und für eine relativ schmalen Taler zu haben ist. Die Toolchain unter Linux wäre nice.
Moin, Prinzipiell seh' ich nicht, dass da was voellig Unmoegliches gemacht werden sollte, aber's wird wohl nicht so ganz supersimpel sein. Alleine sowas: C. W. schrieb: > mit einem aus den Syncsignalen erzeugten Pixelclock koennte tricky werden. Ueblicherweise sind PLLs in FPGAs nicht unbedingt dafuer geeignet, direkt H-Syncse zu vervielfachen. Also muesste man sich da was nettes ueberlegen... Dann ist noch die Frage, was fuer Timing dein namen- und datenblattloses TFT kann/erwartet, insbesondere, wie weit runter man mit der CLK gehen kann. Und was man ggf. fuer Faxen machen muss, um ggf. auch irgendwelche krummen Interpolationsverhaeltnisse nicht zu fies aussehen zu lassen. Fuer fertige Boards seh' ich eher schwarz. Zumindest irgendein Zusatzboard mit den entsprechenden Buchsen/Steckern/Pegelwandlern(auch wenns nur Spannungsteiler fuer die CGA Signale sind) wirds wohl eher nicht von der Stange geben. Gruss WK
Die Sache mit der Pixelclock würde ich wahrscheinlich "analog" lösen. Das dafür ein I/O-Board notwendig wird ist klar. Auf dem Board wären dann die Pegelwandlung für das RGBI-Signal, die PLL für die Pixelclock und der LVDS Transmitter für das Display (G065VN01). Können das TFT-Modul und der Eingang nicht asynchron laufen?
C. W. schrieb: > Können das > TFT-Modul und der Eingang nicht asynchron laufen? Bestimmt. Musst halt vielleicht mal ein Bild wegwerfen oder einfügen.
Moin, C. W. schrieb: > Auf dem Board wären > dann die Pegelwandlung für das RGBI-Signal, die PLL für die Pixelclock > und der LVDS Transmitter für das Display (G065VN01). Naja, so ausm Bauch raus denk ich, RGBI-Pegelwandler koennten da tatsaechlich noch simple Spannungsteiler sein. Ueber die PLL muesst man noch etwas nachdenken, aber das koennte schon auch noch in einem FPGA gehen, nur halt nicht so ganz simpel. LVDS-Ausgaenge koennen auch viele FPGAs ootb, ohne extra Pegelwandler. Das waere eh' auch kein Spass, denn so wie ich das sehe, ist dann die LVDS-Clk ja 25.2 MHz, d.h. die Bits auf den 3 Lanes purzeln dann mit 176.4MHz aus dem FPGA. Da wuerde ich extra Pegelwander moeglichst vermeiden und lieber moeglichst "kurz angebunden" auf den Steckverbinder gehen. > Können das > TFT-Modul und der Eingang nicht asynchron laufen? Wuerde ich auf jeden Fall vermeiden. Sieht ja vom Timing her auch nicht so ganz wahnsinnig anders aus. Gruss WK
Moin, Gustl B. schrieb: > Bestimmt. Musst halt vielleicht mal ein Bild wegwerfen oder einfügen. Sieht kacke aus und braucht viel RAM. Gruss WK
FPGA Takt einige Vielfache über dem Pixeltakt, dann kannst z.B bei FPGA Takt mit 7.6345x vom Pixeltakt jeweils für 7/8 Takte Pixelsignal samplen und dann 7.6345 zum Taktzähler addieren und solange Pixelsignal samplen bis Taktzähler >= Taktzähler+7.6345, dann Pixel entweder 0 oder 1, je nach dem, ob derweil mehr 1 oder 0 im Pixelsignal waren. Und statt VGA würde ich direkt Parallel-RGB gehen, da sparst den ganze VGA=>Parallel-RGB Krams, der in den heutigen Monitoren für gewöhnlich drinne ist.
C. W. schrieb: > Wäre das nicht eine Aufgabe die man in einem einzelnen FPGA erledigen > könnte? Oder einfach mit einem PiPico. Da ist alles drinne, was man braucht, notfalls sogar genug RAM für einen vollständigen Framebuffer. Nunja, LVDS-Ausgabe ist zwar möglich, aber ein wenig tricky, aber das könnte man leicht dadurch umgehen, indem man halt ein Display mit paralleler Ansteuerung benutzt. Noch sind genug davon im Umlauf. Das einzig Spannende, was dann noch zur Lösung verbleibt, ist eine digitale PLL für die Eingabe-Seite. Übrigens: Die Ausgabe von deinem ungenannten Messgerät, die ist doch Schwarzweiß(*) oder? (*) "weiß" könnte theoretisch auch irgendeine andere der 16 möglichen Farben sein, also z.B. hellgrün.
Angehängte Dateien:
Ob S. schrieb: > Die Ausgabe von deinem ungenannten Messgerät, die ist doch > Schwarzweiß(*) oder? Nein - mit der Lösung wie eingangs erwähnt ergibt sich das angehängte Bild
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.