mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik FBAS to digital RGB Konverter gesucht !


Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

ich suche einen FBAS- RGB(digital) konverter, ich habe TDAxx gefunden 
aber sie geben RGB analog raus ... hat jemand eine Idee ???

danke

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, das dürfte auch RGB analog sein.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber RGB digital liefert dann doch nur 7 Farben, wofür soll das gut 
sein?

Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lieber digital.... zu analog habe ich schon die TDA8362 gefunden

Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mein Prozessor empfängt digitale RGB(6bit je Farbe) deswegen ....

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Εrnst B✶ (ernst)
Datum:

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

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...]

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schade, den gibts nicht mehr.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den TDA8362 gibts auch nicht mehr.

Was für ein Prozessor ist denn das, der den RGB Eingang haben will? Kann 
der denn PAL?

Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian

das ist ein Trimedia Prozessor pnx15xx

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...]

Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 :-(

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ?

Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt

ich habe gerade das dattenblatt geschaut, der TVP5150 kann aber nicht 
888YUV ausgeben ?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.nxp.com/acrobat_download/datasheets/SAF...
der SA7113 scheint ein Nachfolgetyp zu sein, der wird noch produziert. 
Multistandard-Decoder  PAL/NTSC/SECAM und Video-ADCs 9 Bit

Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@benedikt

wieder neu abtasten (mit 8bit) ! so meinst du ?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok... danke

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: FBAS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian Micro (micro-flo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian Micro (micro-flo)
Datum:

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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir mal VBLNK und AVID an. Die kann man entsprechend 
programmieren, so dass diese nur während der Bildzeile aktiv sind.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das werde ich machen, Danke!
Hattest Du bei Deinem Projekt auch ein CPLD hinter dem TVP?
Wenn ja welcher war das?

Gruß
Andreas

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!!!
Mail ist raus.
Gruß
Andreas

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kann durchaus sein, dass Bit0 unnötig ist, aber Bit7 sollte nicht weg 
optimiert werden.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Er wird vom µC einmal kurz auf Low gezogen und bleibt danach auf high.

Autor: Andreas B. (Firma: none) (suicide0)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir läuft der AVR komplett mit 3,3V.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.