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
C. W. schrieb: > Nein - mit der Lösung wie eingangs erwähnt ergibt sich das angehängte > Bild Das ist dann aber nicht CGA, jedenfalls nicht CGA in seiner Urform. Das ist dann eine der aufgebrezelten Varianten davon, die in der einen oder anderen Hinsicht schon fast wie VGA sind. Nunja, egal. Am kompliziertesten Teil (Digital-PLL) ändert das nix.
Angehängte Dateien:
CGA steht zumindest so im Datenblatt....
C. W. schrieb: > CGA steht zumindest so im Datenblatt.... Nunja, du kannst ja auch problemlos einen Monitor nach CGA-Standard anschließen. Das war ja der Trick bei der Aufbrezelei. Die Magie geschah ausschließlich in der Grafikkarte.
C. W. schrieb: > Habe da noch etwas interessantes gefunden: > > https://www.cogitarecomputing.com/Projects/RGBI2VGA/ Ja, das grundsätzliche Prinzip ist ja eh' klar. Und: Das kannst du mit einem PiPico viel einfacher haben. Der hat nämlich PIOs, die sich ideal dazu eignen, schnell (und unabhängig von den µC-Cores) mit Bits zu jonglieren.
Moin, C. W. schrieb: > Habe da noch etwas interessantes gefunden: > > https://www.cogitarecomputing.com/Projects/RGBI2VGA/ Find ich interessant im Sinne von: Erstaunlich was man alles mit µC-Peripherie machen kann - aber nicht im Sinne von: Ja, damit moechte ich ein Display an einem Messgeraet ansteuern. Im Uebrigen kommt da ja "nur" VGA raus, und dann auch noch eigenartiges, wenn ich mir mal die Widerstandswerte am Ausgang anguck'. Also kein LVDS fuers Display direkt. Und einen extra Framebuffer wuerd' ich mir niemals freiwillig ans Bein binden. Hier passt doch die Aufloesung und die Framerate des Displays recht gut zusammen mit den Eingang. Schlimm genug, wenn man 1-2 FIFOs fuer eine Zeile braucht, um die wiederholen zu koennen, aber ein ganzes Bild? Gruss WK
Dergute W. schrieb: > Und einen extra Framebuffer wuerd' ich mir niemals freiwillig ans Bein > binden. Man wird dadurch halt sehr viel flexibler bei der Wahl des Displays/Ausgabegeräts. Und 264k RAM sind im PiPico ja eh' drin, da kann man die auch verwenden. Gibt bei Nichtverwendung schließlich kein Geld zurück... 640 200 0.5 = 64k Das ist sogar genug für echtes Double-Buffering und es bleibt immer noch eine Menge RAM über.
Es gibt fertige Projekte, die genau das tun. z.B. https://github.com/mlorenzati/pico-rgb2hdmi oder https://github.com/AlexEkb4ever/ZX_RGBI2VGA-HDMI
Ganz genau nicht - aber ein Anfang. Bei mir muss ich halt noch schauen das es 512 Pixel horizontal sind und ich ja direkt ein TFT-Modul ansteuern will. Aber zumindest ein Startpunkt.
C. W. schrieb: > Ganz genau nicht - aber ein Anfang. Bei mir muss ich halt noch schauen > das es 512 Pixel horizontal sind Das hattest du schon im TO erwähnt, hatte ich aber überlesen. Das ist natürlich kein Standardmodus von CGA. Klassischen CRT-Monitoren ist der Pixeltakt zwar weitgehend Wurscht, aber für eine digitale PLL muss es natürlich Anpassungen geben. Der erste Schritt wäre, den verwendeten Pixeltakt erst mal möglichst genau zu vermessen. Kann das Meßgerät irgendein konstantes Testbild am "CGA"-Anschluss liefern? Das wäre dafür ziemlich hilfreich. > und ich ja direkt ein TFT-Modul > ansteuern will. Das wiederum ist recht einfach, wenn du mit einem dreifachen Framebuffer arbeitest. Dann ist das Timing von Eingabe und Ausgabe weitestgehend voneinander entkoppelt. In der konkreten Anwendung dürfte aber wohl auch Double-Buffering ausreichen. Als TFT-Display kämen übrigens parallele 800x480 in Frage. Die sind recht gut verfügbar und mit einem PiPico auch ziemlich leicht anzusteuern. Wenn man das passende Datenblatt mit den Timings hat...
Wenn Ein und Ausgabe zeitlich nah beieinander liegen, würde ich versuchen ohne kompletten Framebuffer auszukommen. Eine einfache Zeilenpufferung mit Wiederholung reicht für 240 auf 480 oft völlig aus und hält den Aufwand klein. Die digitale PLL bleibt zwar Arbeit, danach wird das Design deutlich ruhiger. Weniger RAM heißt am Ende auch weniger potenzielle Fehlerquellen.
Beitrag #7993973 wurde vom Autor gelöscht.
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.