DM642 continous dataflow on Videoport

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 

>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 �usual� 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

"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

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 

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