This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM648: Video Port Capture

Hi,

I'm having trouble trying to get the Video Port on the DM648 to capture, in sync, my 1080i frames, and have some questions.  I am running in the Y/C Capture Mode.

I know one frame's data is much more than the total 2560 bytes of the Y Data fifo in the Video Port.  In fact, only one 1920 byte line will fit there.

1.  Do I set up the Video Port so that it thinks a frame capture is literally one line?  If not, what suggestions can be made to handle the 1920x1080 frame with this device?

2.  Did I understand correctly that Data my only be pulled from the VIC's fifo when the threshold Event fires, and that only the amount of data transferred cannot be greater than the Threshold value of the Event trigger on the Fifo?  In short, I cannot tell the EDMA to transfer more data than the fifo threshold setting on a single event, and expect to get data, correct?

3.  Concerning the EDMA, Is there a way I can set up a linked paramset list, and have the EDMA wait until an event fires before it switches to the next linked Param Set?  Otherwise,  I assume I have to modify destination addresses at the completion of every transfer if I want data to load contiguously in a very large memory buffer.

Thanks for any and alll help.

--James

 

  • 1. The video port is designed to be serviced by the EDMA with a series of events per frame, I would suggest setting up the FIFO and EDMA to grab one line at a time, but the video port should be configured to take in the entire frame.

    2. You describe how it is designed to work, the EDMA should only grab as much data as is expected to be available in the FIFO for each event, if you try to capture more you will likely end up with invalid data in your frame buffer. This is discussed in section 1.2 of SPRUEM1.

    3. You could link EDMA transfers to capture multiple lines, but I believe you would still ultimately need CPU intervention though an interrupt between frames so you could adjust the destination address in DDR, as linking allows you to load another PaRAM set into the channel but will not be able to handle the destination address changing continuously. For example this could be setup with an A synchronized transfer where ACNT is the amount of data to read from the FIFO (line width) and BCNT is the number of lines in a frame.

    Overall I am curious why you are not using the existing DM648 video port drivers, or at least using them as an example for how the VP and EDMA should be configured?

    EDIT: Fixed the third response and added clarification.

  • Thanks Bernie for the fast response and confirming to me that I'm not that far off-base then.

    Apparently my problem then is that I haven't yet gotten the Video Port Captured configured properly for the size of the 1080i frames.

    Send me your E-mail, and I'll gladly discuss with you privately why I do not want to use the PSP drivers although I do look at them for a reference.

    Thanks again,

    --James

    E-mail:  james.rasmussen@ambrado.com

     

  • I can send you an email to follow up on this, though we do prefer to try to keep as much conversation on the forum itself as possible so that future users can benefit from the discussion.

    As a general rule if anyone has a need to work directly with the TI applications staff you can submit a request through http://support.ti.com, which should help you to get in touch with a local engineer (including myself).

  • Bernie,

    I just put in a support ticket addressed to you.  You can E-mail me at james.rasmussen@ambrado.com.

     

    Thanks for any help,

    --James Rasmussen

     

  • I believe your email system may be blocking the messages, as I sent you an email yesterday morning, you may want to check your spam/junk email folder. I did find the one you sent in and associated it with the original service request I made yesterday.