Hallo Zusammen, ich suche einen FBAS- RGB(digital) konverter, ich habe TDAxx gefunden aber sie geben RGB analog raus ... hat jemand eine Idee ??? danke
darf es auch was fertiges sein? In der letzten Angebotsliste von Neuhold ist mir ein 'video zu VGA Konverter' aufgefallen, kostet da 33€. http://www.neuhold-elektronik.at/werbung/we_108.pdf
aber RGB digital liefert dann doch nur 7 Farben, wofür soll das gut sein?
mein Prozessor empfängt digitale RGB(6bit je Farbe) deswegen ....
FBAS wrote: > mein Prozessor empfängt digitale RGB(6bit je Farbe) deswegen .... Fernsehfrequenzen? Oder eher VGA oder sowas vom Computer. Du brauchst halt einen Video ADC dazu, wenn den Prozessor nur VGA oder sowas kann, dann noch einen CPLD/FPGA mit Speicher für die Formatkonvertierung...
Hallo Christian, um FBAS zu RGB habe ich ein IC gefunden: TDA8362, sendet aber analog RGB und mein Prozessor nimmt digital RGB auf ! gibt's nicht so einen Baustein, der FBAS aufnimmt und digital RGB ausgibt ?
Frag doch mal beim "anfänger" aus diesem Thread Beitrag "µProzessor mit RGB I/O gesucht ?" nach, der scheint ein ähnliches Problem zu haben...
dann müßte hinter den RGB analog noch ein 3fach AD-Wandler: TDA8707. Wird das ein Ambilight? http://www.nxp.com/#/pip/pip=[pip=TDA8707_3]|pp=[v=d,t=pip,i=TDA8707_3,fi=,ps=0][0]
Den TDA8362 gibts auch nicht mehr. Was für ein Prozessor ist denn das, der den RGB Eingang haben will? Kann der denn PAL?
von NXP gibts Video-Decoder mit AD-Wandler auf einem Chip, SAA71xx zum Beispiel ( nicht mehr in Produktion) SAA7111: http://www.nxp.com/#/pip/pip=[pip=SAA7111_3]|pp=[v=d,t=pip,i=SAA7111_3,fi=,ps=0][0]
@Christian das ist schade wenn das nicht mehr in Produktion! ich habe hier die kombination gefunden um FBAS zu digital RGB: FBAS ---> TDA8362 --->analog RGB --->TDA8707---> digital RGB---> µProzessor aber TDA8362 ist nicht mehr in Produktion :-(
TVP5150 Der macht FBAS -> digitales YUV, aber das kann man ja leicht in RGB umrechnen.
@Benedikt ja, durch eine bestimmte Matrix wird das berechnet... danke... schon mal ein schritt :-) gibt's so ein Produkt für DVI---->RGB bzw. YUV ?
@Benedikt ich habe gerade das dattenblatt geschaut, der TVP5150 kann aber nicht 888YUV ausgeben ?
http://www.nxp.com/acrobat_download/datasheets/SAF7113H_3.pdf der SA7113 scheint ein Nachfolgetyp zu sein, der wird noch produziert. Multistandard-Decoder PAL/NTSC/SECAM und Video-ADCs 9 Bit
@benedikt wieder neu abtasten (mit 8bit) ! so meinst du ?
Der TVP5150, oder der SA7113 oder viele andere ICs geben alle YUV aus, und zwar meist in folgender Form: Y, U, Y, V, Y, U, Y, V usw. Die digitalen Werte lässt du durch einen CPLD laufen, der die Y, U, V Werte speichert, und jeden zweiten Takt aus den vorhandenen Werten RGB berechnet.
DVI zu digital RGB (24 Bit incl. H-Sync und V-Sync) gibts bei Texas: TFP201A usw. Hab ich schon gebaut, klappt gut an einem normalen Display. Willst du nun DVI oder FBAS? Sieht ja keiner mehr durch. Was willst du denn überhaupt machen?
@christian ich brauche beide, einmal fbas --> Converter zu rgb---> µP---> LCD(400x240)@ 8,3Mhz@5/6/5 Bit einmal DVI --->Converter zu rgb----->µP---> LCD (800x480)@33Mhz@8/8/8 Bit zwei verschiedene Projekte aber prinzepiell sind sie ähnlich
@christian ist die schaltung (dvi to rgb) nicht kompliziert, kann ich - wenn möglich- einen Blick auf die schaltung werfen... ich habe nicht viel Erfahrung in diesem Bereich danke im Voraus
Nö, da war nichzt viel dabei, nur der DVI-Receiver Chip und ein Spannungsregler. Mit wenig Erfahrung wird sowas schwierig...bei den Frequenzen benötigst du impedanzkontrollierte Leiterplatten. Ohne war bei mir bei 800x600 schon Schluss mit lustig.
Also laut Datenblatt geben die Chips ITU-R BT 656 über ITU-R BT 601 aus. Wenn ich das richtig verstanden habe, sind diese Formate mit Zeilensprung, also interlaced, bzw. die geben einfach aus, was man reingibt. Wenn also das Gerät kein Progressive Scan kann, kommts hinten auch nicht raus. Ein LCD kann aber mit dem Zeilensprung nichts anfangen und zeigt Müll an. Gibt es da auch einen Trick? Benedikt K. wrote: > Der TVP5150, oder der SA7113 oder viele andere ICs geben alle YUV aus, > und zwar meist in folgender Form: > Y, U, Y, V, Y, U, Y, V usw. > Die digitalen Werte lässt du durch einen CPLD laufen, der die Y, U, V > Werte speichert, und jeden zweiten Takt aus den vorhandenen Werten RGB > berechnet.
Florian Micro wrote: > Also laut Datenblatt geben die Chips ITU-R BT 656 über ITU-R BT 601 aus. > Wenn ich das richtig verstanden habe, sind diese Formate mit > Zeilensprung, also interlaced, bzw. die geben einfach aus, was man > reingibt. > Wenn also das Gerät kein Progressive Scan kann, kommts hinten auch nicht > raus. > Ein LCD kann aber mit dem Zeilensprung nichts anfangen und zeigt Müll > an. > Gibt es da auch einen Trick? Natürlich: Zwischenspeichern und Vollbilder ausgeben. Macht jeder Scan-Doubler so.
Nö, wo soll der das denn hinspeichern ohne Speicher? Rechne doch einmal aus, wieviel Speicher du für ein komplettes Bild in deiner gewünschten Auflösung und Farbtiefe benötigst.
Nein. Mit einem FPGA geht es, wenn man etwas pfuscht: Der hat immerhin genügend Speicher onboard um eine Zeile (768*2Bytes=1,5kByte) zwischenzuspeichern und 2x hintereinander auszugeben. Damit kann man dann immerhin aus dem Interlaced Signal ein normales Videosignal mit 31,25kHz Horizontalfrequenz und 50Hz Vertikalfrequenz machen, was immerhin einige Monitore darstellen können. Einige fangen dagegen erst bei 56Hz Vertikalfrequenz an. Soll das ganze Bild zwischengespeichert werden, dann sind etwa 864kByte an Speicher notwendig.
Hallo, da ich derzeit auch mit YUV4:2:2 in 8bit rumbasteln möchte,würde ich euch gern eine Frage stellen. @Benedikt und andere CPLD/FPGA-wissende... Du schreibst die Signale kommen dort Y U Y V Y U Y V heraus. Habe ich es richtig verstanden, dass mit jedem Clocktakt 8 Bit Y kommen mit dem nächsten Takt 8 Bit U und so weiter? Des weiteren schlägst Du einen CPLD vor. Wie rechnet mit in einem CPLD mit Kommastellen? Wenn ich richtig infmoiert bin funktioniert die Umrechung in etwas so: R = Y + 1.403V G = Y - 0.344U - 0.714V B = Y + 1.770U kann man in einem CPLD Tabellen mit vorgerechneten Werten arbeiten oder wie ist so etwas realisierbar? Gruß Andras
Andreas Bro wrote: > Du schreibst die Signale kommen dort Y U Y V Y U Y V heraus. > Habe ich es richtig verstanden, dass mit jedem Clocktakt > 8 Bit Y kommen mit dem nächsten Takt 8 Bit U und so weiter? Ja. > Des weiteren schlägst Du einen CPLD vor. Ein FPGA wäre besser, ist aber entsprechend aufwendiger. > Wie rechnet mit in einem CPLD mit Kommastellen? Garnicht, dazu sind die viel zu klein. > Wenn ich richtig infmoiert bin funktioniert die Umrechung in etwas so: > R = Y + 1.403V > G = Y - 0.344U - 0.714V > B = Y + 1.770U Wo hast du die Werte her? Ich bin von denen hier ausgegangen, die sehen leicht anders aus und lassen sich besser vereinfachen: http://de.wikipedia.org/wiki/YUV R <= Y + V * 1,14 B <= Y + U * 2,03 G <= 1,7 * Y - 0,509 * B - 0,245 * R Die habe ich umgeformt: G <= 0,946 * Y - 1,03 * U - 0,28 * V Und großzügig gerundet: R <= Y + V B <= Y + 2 * U G <= Y - U - V / 4 Das kann man nur durch reine Additionen berechnen.
Vielen Dank ertsmal für die Info. die Werte hatte ich von hier: http://farbe.wisotop.de/Farbmodelle-RGB-CMYK-HSS-HSL.shtml Aber Deine Werte inkl. der Rundung machen die Sache deutlich einfacher.
Interessant. Es scheint mehrere unterschiedliche Umrechnungsformeln zu geben. Ich habe gerade nochmal nachgeschaut, meine Werte passen nicht ganz zu denen von Wikipedia. Vermutlich habe ich meine aus einem Buch abgeschrieben. Der Unterschied dürfte vermutlich daher kommen, dass Y und V oft unterschiedlich gewichtet werden (hat glaube ich irgendwas mit der Übertragung der Bildinformationen Farbsignale im PAL Signal zu tun). Aber egal welche Werte man verwendet, wenn man es genauer haben möchte als meine sehr vereinfachte Lösung, dann wird das ganze auf Festkomma hinauslaufen. Also z.B. anstelle *1,5 wird man einfach *3 /2 rechnen. Auf einem FPGA könnte man dazu den Multiplizierer verwenden, auf einem CPLD könnte man einfach 2*Wert + Wert rechnen und dann alles um eine Stelle nach rechts schieben.
soooo genau muss es nicht werden, soll ein Ambilight auf Basis TVP5150AM1 - Xilinx CPLD und MEGA88 werden. Jetzt habe da noch eine Frage zu den CPLDs. Ich mache gerade meine ersten "Gehversuche" counter und son Schnickschnack habe ich bereits in der IDE in VHDL geschrieben. Es kann also langsam an die Hardware gehen. Wenn der TVP5150AM1 via i2c in den 8bit YUY4:2:2 ohne Syncs (bzw. separate Syncs) gesetzt wird wären die 27mhz vom TVP meine CLK für den CPLD (oder muss ich extern höher clocken für meine Umrechnung)? müsste ich jetzt nicht 4 Werte abwarten um RGB ausgeben zu können? ich benötige doch Y U und V für die eine RGB-Umrechnung oder habe ich einen Denkfehler? Wenn ich jetzt nur jeden 4. RGB-Wert auf den Mega88 rausclocken würde, dann hätte ich doch auch eine akzeptable Frequenz um das mit 20Mhz Mega88 abzuarbeiten?!
Andreas B. wrote: > wären die 27mhz vom TVP meine CLK für den CPLD Ja, das ist die einfachste Lösung. Da bekommt man genau 1 Byte pro Takt. > müsste ich jetzt nicht 4 Werte abwarten um RGB ausgeben zu können? Ja. > ich benötige doch Y U und V für die eine RGB-Umrechnung oder habe ich > einen Denkfehler? Nein, stimmt schon. Ich merke mir die letzen Y und V Werte und verwende diese für die Berechnungen. Ich bekomme damit alle 2 Takte dann einen RGB Wert (ich benötige aber auch die volle Auflösung, da ich das Signal in ein VGA Signal mit 720x576 Pixel umwandle). Wenn man nicht die volle Auflösung benötigt, kann man auch ein paar Bytes verwerfen. > Wenn ich jetzt nur jeden 4. RGB-Wert auf den Mega88 rausclocken würde, > dann hätte ich doch auch eine akzeptable Frequenz um das mit 20Mhz > Mega88 abzuarbeiten?! Jeder 4. Wert sind immer noch 3,4MHz, das könnte etwas eng werden. Wenn es nur um Ambilight geht, würde ich direkt im CPLD aus einem größeren Bereich einer Zeile den Mittelwert bilden und diesen an den AVR übergeben. So bekommt der AVR dann z.B. nur 4-8 Werte pro Zeile. Diese summiert er dann wiederum über mehrere Zeilen auf und erzeugt im Speicher so ein Minibild mit z.B. 4x4 - 8x8 Pixel. Zumindest würde ich das so machen.
Das mit dem Zwischenwert im CPLD zu erledigen ist eine klasse Idee (machmal sieht man den Wald vor lauter Bäumen nicht). Danke Gruß Andreas
Ich verstehe allerdings nicht wie Du alle 2 Takte ein RGB berechnest!? rising_edge(clk) -> lesen des TVP 1. Takt = 8 bit Y 2. Takt = 8 bit U 3. Takt = 8 bit Y 4. Takt = 8 bit V ich habe doch also erst nach 4 clockcycles alle Werte die ich benötige oder wo denke ich quer?
Andreas B. wrote: > ich habe doch also erst nach 4 clockcycles alle Werte die ich benötige > oder > wo denke ich quer? Ja, aber nach 4 Takten kennst du U und V, und dann kommt jeden 2. Takt ein neuer Y Wert. Der erste Pixel ist dann halt Mist, da Y und V falsch sind, aber das ist egal.
OK, das ist tricky! ich mag solche Lösungen :-) Es stellen sich mir wieder ein paar neue Fragen. Wäre super wenn Du mich da mal an die Hand nehmen könntest. Welche Pins ganau hast Du von dem TVP5150AM1 benutzt oder besser welche kann man ignorieren. ich denke ich benötige: HSYNC VSYNC/PALI SDA SCL RESETB PCLK/SCLK YOUT1-8 Im Datenblatt steht, dass man INTERQ/GPCL AVID HSYNC und VSYNC unverdrahtet lassen kann. Muss ich PDN und FID beschalten? Wie hast Du die Kondensatoren am Quarz dimensioniert? Zum CPLD hätte ich auch noch eine Frage. Ich möchte den CPLD nebenbei als eine Art I2C Level-Shifter benutzen (wegen der 5V tolleranz des CPLDs): TVP5150AM1 <-> SDL/SDA <-> CPLD <-> AVR Was muss ich in VHDL anstellen um das zu realisieren? Der Code für den Wandler ist fast fertig aber hier stockt es. entitiy bla.... port ( tvp_sdl: inout std_logic; tvp_sda: inout std_logic; avr_sdl: inout std_logic; avr_sda: inout std_logic); architecture bla... tvp_sdl ??? avr_sdl; tvp_sda ??? avr_sda; Des Weiteren habe ich vor das in einem XC9536XL abzubilden. Wie gesagt der Code ist fast fertig und läßt sich SYNTHESIZEn und FITen. Gibt es aus Deiner sicht einen Grund den ich nicht sehen kann warum das mit diesem CPLD nicht funktionieren wird? Gruß Andreas
Andreas B. wrote: > Im Datenblatt steht, dass man INTERQ/GPCL AVID HSYNC und VSYNC > unverdrahtet lassen kann. Ja, das sind Ausgänge. VBLNK und HSYNC beinhalten mehr oder weniger die gleichen Infos, VBLANK ist nur breiter. Für AVID und HSYNC gilt ähnliches. Ich habe AVID und VBLNK verwendet, da man den Bereich in dem diese aktiv sind schön per Software einstellen kann. Das erspart etwas Logik im CPLD um den aktiven Bildbereich auszuwählen. > Muss ich PDN und FID beschalten? PDN (Power Down) sollte man auf High legen wenn man es nicht braucht, FID gibt an welches Halbbild übertragen wird -> Hier uninteressant. > Wie hast Du die Kondensatoren am Quarz dimensioniert? Ich habe mir da keine großen Gedanken gemacht und einfach 2x 22pF verwendet. > Zum CPLD hätte ich auch noch eine Frage. > Ich möchte den CPLD nebenbei als eine Art I2C Level-Shifter benutzen > (wegen der 5V tolleranz des CPLDs): > TVP5150AM1 <-> SDL/SDA <-> CPLD <-> AVR > Was muss ich in VHDL anstellen um das zu realisieren? Gute Frage. Ich sehe da etliche Probleme, da der Bus bidirektional ist. Ich habe die Pullups an 3,3V angeschlossen, das erkennt der AVR als high. Das ist am wenigsten Aufwand.
Danke erstmal für die Info! Das mit dem Pullup habe ich nicht verstanden. (AVR 5V) ------------ (TVP5150AM1 3.3V) Wenn der TVP auf high schaltet ist ja alles gut. Der AVR erkennt die 3.3V als High-Pegel und geht nicht kaputt. wenn der AVR pin high ist, liegen 5V am TVP an, was die Spezifikation laut DB überschreitet. Was genau machst Du da wie mit einem Widerstand? Danke Gruß Andreas
Andreas B. wrote: > wenn der AVR pin high ist, liegen 5V am TVP an, was die Spezifikation > laut DB überschreitet. Der Pin geht nie auf high, da I²C Open Collector ist.
O.K. das ist jetzt wahrscheinlich ganz banal aber ich verstehe das trotzdem nicht so richtig. Der I2C BUS liegt via pullup auf 3.3V (beide Leitungen sprich SDA und SDL). Die kommunuzierenden Teilnehmer ziehen den Bus zur Kommunikation auf LOW-Pegel (ist das so weit richtig?) Wenn der Ausgang des AVR nich Low ist, dann ist er doch High? oder schaltet und man einen Transistor davor, der den Bus gegen Masse schaltet und benutzt dann AVR-Seitig 2 Pins Pro I2C-Leitung? oder bin ich einfach nur zu stuppig das zu kapieren? ;-) Danke noch mal Gruß Andreas
sorry, ich brauche eine neue Brille! Hab gerade im DB des Mega88 entdeckt, dass dieser Hardware I2C anbietet. Alles weitere werde ich sicher im DB finden. Sorry für die dämliche Frage Gruß Andreas
Hallo, bin wieder ein ganzes Stück weiter. Leider musste ich feststellen, dass der CX9536XL viel zu klein ist (schade war schön günstig). Habe noch eine Frage zum TVP: hast Du eine Idee wie ich bei RAW YUV4:2:2 feststellen kann, wann das letzte Pixel einer Zeile gesendet wurde, sprich die Zeile beendet ist (evtl. pixel zählen)? Oder gibt es irgendein Signal? Danke Gruß Andreas
Schau dir mal VBLNK und AVID an. Die kann man entsprechend programmieren, so dass diese nur während der Bildzeile aktiv sind.
das werde ich machen, Danke! Hattest Du bei Deinem Projekt auch ein CPLD hinter dem TVP? Wenn ja welcher war das? Gruß Andreas
Ich muss jetzt noch mal was fragen da ich via google einfach nichts finden kann :( zu der Berechung RGB hier einmal mein Codeschnipsel nach Benedikts Formel: -- R = Y+V R_VALUE<=Y_VALUE+V_VALUE; -- B = 2*U+Y B_VALUE<=U_VALUE+U_VALUE+Y_VALUE; -- G = Y-U-V/4 TEMP(7 downto 6)<="00"; TEMP(5 downto 0)<=V_VALUE(5 downto 0); G_VALUE<=Y_VALUE-U_VALUE-TEMP; Da könnten jetzt doch 16Bit-Werte bei R,G oder B rauskommen oder? Ignoriert man da einfach die oberen 8 Bits oder kommt das gar nicht vor, weil die Y,U und V-Werte entsprechend klein sind? Ich möchte das so gern verstehen :-)
Andreas B. wrote:
> Da könnten jetzt doch 16Bit-Werte bei R,G oder B rauskommen oder?
Nein. Wenn du 2 8bit Werte addierst, kommen maximal 9bit raus. Beim
Subtrahieren gilt ähnliches.
Da maximal 3x addiert wird, reichen 10bit aus.
Da U und V aber Vorzeichen behaftete Zahlen sind, benötigt man auch noch
ein Vorzeichen, also 11bit. Dieses Vorzeichen muss man bei der
Erweiterung auf die 11bit Zahl beachten (sign extension, falls man das
ganze nicht als integer rechnet). Am Ende können auch Werte <0
rauskommen, die muss mann dann auf 0 begrenzen, ebenso bei >255.
Hi, hatte ich hier nicht mal irgendwo gelesen: "...kleiner CPLD ran und schon hast Du Dein RGB..." ;-) Das wird offensichtlich viel komplizierter als es zunächst einmal für mich aussah :-( Hast Du evtl einen Tipp bezüglich Lektüre was diese Thematik angeht. Ich habe da jetzt schon so viel Zeit investiert, dass es kein Zurück mehr gibt ;-) evtl. hast Du ja vielleicht auch einen Codeschnipsel, den Du preisgeben würdest (das würde das ganze für mich transparenter machen). Versteh mich bitte nicht falsch, ich möchte mich da schon irgendwie allein durchbeissen, wäre aber für jeden Anstoss in die richtige Richtung echt dankbar. Wenn mir das Projekt irgendwann gelingt, werde ich es dokumentieren und der community zur Verfügung stellen. Auf jeden Fall ein dickes Danke für Deine Hilfe. wenn aus dem TVP 8 bit U und V mit vorzeichen raukommen sind es also Wertetechnisch tatsächlich nur 7Bit + 1Bit vorzeichen?! Wo kann man so etwas nachlesen? Gruß Andreas
Andreas B. wrote: > evtl. hast Du ja vielleicht auch einen Codeschnipsel, den Du preisgeben > würdest (das würde das ganze für mich transparenter machen). Gib mir mal deine Emailadresse oder schick mir eine Nachricht, dann schick ich dir den Code.
Hallo noch einmal, sag mal ist es normal, dass die ISE mir bit 0 und 7 vom YUV_Eingang wegoptimiert? Das kann doch nicht richtig sein oder (da fehlen dann doch die Vorzeichen)? P.S: habe mein RGB out auf 6 Bits geschrumpft. Gruß Andreas
Es kann durchaus sein, dass Bit0 unnötig ist, aber Bit7 sollte nicht weg optimiert werden.
Hallo ,ich habe noch kleine Frage... was genau hast Du mit ResetB vom TVP gemacht? Auf Hi, Lo oder wie im DB beschrieben angesteuert? Danke Gruß Andreas
Er wird vom µC einmal kurz auf Low gezogen und bleibt danach auf high.
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.