Reply by Detlef July 26, 20052005-07-26
Dear Yigal,

> We considered transferring data via the video port but you should be > careful for the following reasons: > 1. You will have implement a ITU-601 or BT656 signal that must be > synchronized with your data in order to connect to VP
Yes, I've got external clock. Data is clocked into the FIFO of the DSP.
> 2. Data is assumed to arrive at constant clock so you must verify that you > have data continuously stream in to the video port
Yes. But can I verify that the DSP is able to catch it ? (Best I would like a software slice .. or a hint from someone who has an application like this up and running. E.g. Is raw data mode right. What settings do I have to use.)
> 3. Zero or gaps are not created by the video port. If created, it is the > video decoder behavior(VSYNC,,,)
And can I leave the video decoder behaviour out ? ;-)
> 4. If you want to use the video port as a pipe for transferring data in > the �usual� way you will have to implement some logic in the FPGA
I thought connecting the clock and the data would be enough.
> > > We are still considering this option > > BTW: Raw video capture is a good option for this application > > Yigal > > > > > This message was sent using the Comp.DSP web interface on > www.DSPRelated.com
Reply by Detlef July 26, 20052005-07-26
Dear Randy,

Thanks for your suggestion.
I'm sure DM642 is running well with video decoders as it is designed for it.
My application is a bit different:
I've continuous dataflow externally clocked.
Video data has allways gaps between the pictures. There's a post-filling 
with zeros.
This time is used for setup (reload) the DMA.
I was wondering if someone has made an application without video in mind.
(Only then you see some drawbacks of the Video Ports).

                                            Thanks, Detlef

> This is definitely possible when the input is 8-bit BT656 mode, such as > is available from the TI TVP5150 or Phillips 7115 video decoders - I've > got one working at my current client's. In fact, the port was designed to > support this mode of operation. > > You'll have to set up EDMAs for the Y, Cr, and Cb FIFOs, as well as > setting up the video port itself, incuding master port configuration > and the capture port subset for the specific channel you're using. > > The set up isn't trivial. TI's BIOS example uses 5 buffers (Viops), > including an mrViop (most recent), and nextViop, and a > currentViop. There are in addition two free Viops. The user > application exchanges a spent frame for a new frame of data via the > FVID_exchange macro. > > Oh, and you'll have to setup the video decoder as well. TI's capture > device driver has all this mapped out via the EDC (external device > control) functions. > > See the BIOS examples for the dm642 for more info. > -- > % Randy Yates % "Midnight, on the water... > %% Fuquay-Varina, NC % I saw... the ocean's daughter." > %%% 919-577-9882 % 'Can't Get It Out Of My Head' > %%%% <yates@ieee.org> % *El Dorado*, Electric Light Orchestra > http://home.earthlink.net/~yatescr
Reply by Randy Yates July 25, 20052005-07-25
"Detlef" <Never@nowhere.com> writes:

> Dear all, > > Is there someone out there who has tried to continuously capture data > using the Videoport of a DM642 ? > (No gaps, nor zeros in dataflow, just as a continuous stream of data using > the > build in FIFO as a buffer for internal non-continous data processing) > > Is this possible ?
This is definitely possible when the input is 8-bit BT656 mode, such as is available from the TI TVP5150 or Phillips 7115 video decoders - I've got one working at my current client's. In fact, the port was designed to support this mode of operation. You'll have to set up EDMAs for the Y, Cr, and Cb FIFOs, as well as setting up the video port itself, incuding master port configuration and the capture port subset for the specific channel you're using. The set up isn't trivial. TI's BIOS example uses 5 buffers (Viops), including an mrViop (most recent), and nextViop, and a currentViop. There are in addition two free Viops. The user application exchanges a spent frame for a new frame of data via the FVID_exchange macro. Oh, and you'll have to setup the video decoder as well. TI's capture device driver has all this mapped out via the EDC (external device control) functions. See the BIOS examples for the dm642 for more info. -- % Randy Yates % "Midnight, on the water... %% Fuquay-Varina, NC % I saw... the ocean's daughter." %%% 919-577-9882 % 'Can't Get It Out Of My Head' %%%% <yates@ieee.org> % *El Dorado*, Electric Light Orchestra http://home.earthlink.net/~yatescr
Reply by yigal_fr July 25, 20052005-07-25
>Dear all, > >Is there someone out there who has tried to continuously capture data >using the Videoport of a DM642 ? >(No gaps, nor zeros in dataflow, just as a continuous stream of data
using
>the >build in FIFO as a buffer for internal non-continous data processing) > >Is this possible ? > > Regards, Detlef > > >
We considered transferring data via the video port but you should be careful for the following reasons: 1. You will have implement a ITU-601 or BT656 signal that must be synchronized with your data in order to connect to VP 2. Data is assumed to arrive at constant clock so you must verify that you have data continuously stream in to the video port 3. Zero or gaps are not created by the video port. If created, it is the video decoder behavior(VSYNC,,,) 4. If you want to use the video port as a pipe for transferring data in the &#2013266067;usual&#2013266068; way you will have to implement some logic in the FPGA We are still considering this option BTW: Raw video capture is a good option for this application Yigal This message was sent using the Comp.DSP web interface on www.DSPRelated.com
Reply by Detlef July 25, 20052005-07-25
Dear all,

Is there someone out there who has tried to continuously capture data
using the Videoport of a DM642 ?
(No gaps, nor zeros in dataflow, just as a continuous stream of data using 
the
build in FIFO as a buffer for internal non-continous data processing)

Is this possible ?

                                Regards, Detlef