• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 694 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Can OMAP L138 LCD controller display video from VPIF?

Anonymous
Anonymous

Hi,


I would like to ask about the ability of OMAP L138's LCD display.

               

                         

As SPRUGJ9B TMS320C674x_OMAP-L1x Processor Video Port Interface (VPIF) User's Guide show, there are two input and two output channels within VPIF. The question is on how they are integrated with LCD controller?


I am comparing two devices: DM6437 and OMAP L138. DM6437 has a powerful VPSS which consists of VPFE and VPBE, and these two forms a front-back ends pair that is closely integrated, so there is no problem for VPFE's video stream to get displayed through VPBE, and they could be well synchronized.


For OMAP L138, according to SPRUGJ9B it supports BT.656 stream input video, but could this video get displayed on a backend LCD through LCDC output?


Further, normally LCD requires frame rate of over 75Hz, however standard NTSC video consists of only 30 frames or 60 interlaced fields per second. There is no integer multiplication relationship between 75 and 30/60, so how does the synchronization works if LCD can be made to display BT.656 stream?




Zheng


  • 0
    TI__Genius 14405 points

    Zheng,

    VPIF only displays embedded YUV422 data. Does the LCD that you are considering support this data format (most LCD takes in RGB data with external sync)?

    If data format is not an issue, then we are OK. You can increase the pixel clock to have VPIF display 75fps.

    regards,

    Paul

  • Anonymous
    0 Anonymous in reply to Paul.Yin

    Paul,

     

    It's great to see you again.

     

    Part of why I asked this question was that I didn't read OMAP L138 documents careful enough.

     

     

    First,

    as the above compilation of screenshots shows, pins of two transmit channels of VPIF combined (VP_DOUT[0:7] ∪ VP_DOUT[8:15]) are multiplexed with LCD_D[0:15], so when LCD modules are needed, LCD controller can be used to interface to them without requiring VPIF's transmitter channel.

     

    In addition to RGB signal pins, there are also the required Vsync, Hsync, Enable, Pixel clock on in LCD controller module.

     

    So in terms of pins, everything required is provided.

     

     

    Second,

    as the 2nd compilation of screenshots shows, 16 BPP(bit per pixel) format, or alternatively called "parallel RGB", is supported for TFT LCD, so the required data format support is also provided.

     

    It could then be concluded that parallel RGB TFT LCDs are supported by L138, not via VPIF, but via LCD controller.

     

    What is the difference between {VPIF, LCDC} and {VPFE, VPBE} on DM6437? I think basically VPIF is something like a naïve version of VPSS without VPSS's many sophisticated functions like {H3A, Histogram; OSD, cursor window}, and with only one output format (YUV4:2:2) as you have suggested. If we also took LCDC into consideration, then LCDC enhance the output capability of VPIF by adding LCD support.

     

    I think the above questions are resolved. What left is the principal problem of synchronization: How does the user, or chip, synchronize between a 30fps input stream and a 75 frame/s output stream? Could you provide more insight into this?

     

     

    Zheng

     

  • 0 in reply to Anonymous
    TI__Genius 14405 points

    Zheng,

    Regarding your "synchronization" problem, basically what you need is to generate 5 output frames from 2 input frames. This is a similar, but simpler version of going from 24fps to 30fps (film -> SDTV).

    The technique from 24fps to 30fps is called pull down, see http://www.zerocut.com/tech/pulldown.html

    instead of doing (4->5), you need to do (2->5).

    regards,

    Paul

  • Anonymous
    0 Anonymous in reply to Paul.Yin

    Paul,

    Thanks, I will study this carefully.

    Zheng