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.

DM642 video port 8-bit raw display mode

Hi, 

I am trying to use the VP2 on a DM642 using the normal video port driver in 8-bit raw display mode to output 8-bit data and nothing else (i.e. no blanking data etc,) but the port just doesn't seem to go at all in this mode (seems like no DMA is going on and just the default value is output all the time). It works if I set it to BT656 8-bit mode but then the blanking data and EAV, SAV etc come out and I don't want any of that! 

Is there a known problem with 8-bit raw display mode? Or if not, can anyone an example of a VPORTDIS_params structure that should work? 

Cheers, Phil

 

  • I think that the DM642 Video Port DSP BIOS driver only supports BT656. The Video Port itself does support both BT656 and RAW display. It is likely that you will have to modify the drivers for your purpose.

    1) To help debug further you will need to look at the driver src code and at the EDMA and FIFO relathionship as well as the VP registers.
    Section 4.11 for the init sequence and section 4.9.2 for the overall timings. Make sure that the CTL signals needed (like HSYNC) have been setup correctly (for example to be input or output).

    2) Regarding FIFO and EDMA:
    Here are 2 examples of a video capture (but it should translate to display as well):
    The way the EDMA is setup is linked with the input image LINE size, FIFO size and EDMA architecture.

    - For example for capturing a PAL FIELD (720 pixels x 242 lines)  you would have the EDMA to handle a complete line at a time (ie 720 pixels). Additionnaly to use the complete EDMA 64bit bus you would transfer a number of elements that is a multiple to a double word so that the EDMA transfers are really optimized.
    The setup would be the Y:
        FIFO threshold: 90 double words (ie 720 bytes)
        EDMA element size: 32bit
        EDMA Element Count: 180 (ie 2 x 90 double words)
        EDMA FRAME COUNT: 242
    Every time the threshold is reached a complete line is copied from FIFO to the destination buffer. Since a 2D EDMA transfer is used the destination buffer size is 242 x 720 bytes. The EDMA will generate an interrupt when the buffer is filled (ie the complete FIELD is acquired).

    - for a RAW capture with a 1/4 VGA (I guess it is 320 x 240):
    To transfer a full line from FIFO to memory you would have:
        FIFO threshold: 40 double words (ie 320 8bit pixels or 320 Bytes)
        EDMA element size: 32bit
        EDMA Element Count: 80 (ie 2 x 40 double words)
        EDMA FRAME COUNT: 240
      
    Since the FIFO has a much bigger capacity you could consider acquiring multiple lines in the FIFO by choosing an other threshold (provided that you keep some FIFO space to prevent a FIFO overflow with new incoming data).

    3) The following documents should help as well:
     VP user's guide - SPRU629F
     C64x EDMA architecture - SPRA994
     C64x EDMA performances - SPRAA02
     C6000 EDMA IO scheduling - SPRAA00
     EDMA user's guide - SPRU234
     VP driver v2.0 src code
     DM642 Video Port Mini-Driver - SPRA918A

    Anthony

     

  • Thanks Anthony,

    I was just wondering if there are any updates to the video port driver. The version I've got is from when I first got the EVMDM642 board way back in 2004 and I am still using CCS 3.1 !! 

    This driver works ok in BT656 display mode so I can just split the data I want to send into Y, Cr and Cb buffers and set the timings to use the HBLNK or HSYNC output as a data valid signal.

    However, it would be easier to use raw mode, which, looking at vportdis.c, does seem to be supported, except that it doesn't seem to work properly, it just disappears into hyperspace on the third FVID_exchange(). So if there's an updated driver somewhere that does work in raw mode that would be great, otherwise I'll just carry on using BT656,

    Cheers, Phil

     

  • Ok, so the problem was that my own code was writing past the end of one of the frame buffers and overwriting some data structures. Hmm.

    Oh well, so I can now confirm that the video port driver does support 8-bit raw display mode! 

    Cheers, Phil

     

     

  • Sorry for responding to such an old post, but I'm having a problem realizing almost exactly what AnBer has described as possible; specifically, the following:

    AnBer said:
    - For example for capturing a PAL FIELD (720 pixels x 242 lines)  you would have the EDMA to handle a complete line at a time (ie 720 pixels). Additionnaly to use the complete EDMA 64bit bus you would transfer a number of elements that is a multiple to a double word so that the EDMA transfers are really optimized.
    The setup would be the Y:
        FIFO threshold: 90 double words (ie 720 bytes)
        EDMA element size: 32bit
        EDMA Element Count: 180 (ie 2 x 90 double words)
        EDMA FRAME COUNT: 242
    Every time the threshold is reached a complete line is copied from FIFO to the destination buffer. Since a 2D EDMA transfer is used the destination buffer size is 242 x 720 bytes. The EDMA will generate an interrupt when the buffer is filled (ie the complete FIELD is acquired).

    Specifically, I cannot get the EDMA to generate an interrupt when "the complete FIELD is acquired".  I have tried setting the FS bit in the parameter table, but that doesn't work; I seem to get almost as many interrupts as there are rows!  In other words, I believe I want to use "block synchronization", but I don't know how to achieve that!

    (This is part of another post I made prior to reading this thread - see  http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/t/231888.aspx)

    Thanks!