FBAS to digital RGB Konverter gesucht !

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...

Frag doch mal beim "anfänger" aus diesem Thread 
Beitrag "µProzessor mit RGB I/O gesucht ?" nach, der scheint ein 
ähnliches Problem zu haben...

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]

TVP5150
Der macht FBAS -> digitales YUV, aber das kann man ja leicht in RGB 
umrechnen.

Er macht halt nur 4:2:2, aber das reicht doch: Ein kleiner CPLD 
dahinter, und du hast dein RGB.

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

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?

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.

Jetzt bin ich mit CPLDs nicht so bewandert.
Schafft der das ohne extra Speicher?

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.

Danke!!!
Mail ist raus.
Gruß
Andreas

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.

Danke!
hast Du den direkt an den MC angeschlossen oder via CPLD gepuffert 
(wegen der 5V am AVR)?

Bei mir läuft der AVR komplett mit 3,3V.