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.

AM335x LCD maximum resolution and frame rate

Hello Champs,

Can you please confirm AM335x LCD maximum frame rate for resolutions 640X480 and 1280X768?

PIxel clock is 125MHz isn't it?

So, for 640 X 480 , the value is 125000000/640/480/1.3 = 313 frames per second

For WXGA 1280X768, fps = 97 fps

Is this calculation method correct?

What is the practical Pixel clock that is achievable? And how to get the values? Kindly confirm.

Best Regards

Feroz

  • Feroz

    Your basic calculation method is correct but you also need to factor in other timing parameters such as horizontal and vertical front/back porch which will reduce you frame rate.

    The LCD panel will also have a maximum pixel clock rate which will most likely be the limiting factor.

    Another consideration is the memory bandwidth requirements of such high frame rates.

    The data manual details the LCD timing with a fastest Pixel clock period of 7.9ns.

      Paul

  • Hi Paul,

    Thank you for the inputs.

    I have taken a factor of 1.3 if you noticed for the porches. Will this factor not suffice?

    We will take care of the LCD panel clock choosing he right LCD.

    What do you think will be the Memory bandwidth needed for say 1280*768 @ 60fps -- 59M pels/s = 943 Mbps. If they use a DDR3-606, then the value will be 59/606 = 9.7% of total capacity (cosnidering 16 bit mode and 2 pixels per DDR3 clock). Is that correct?

    Kindly confirm. 

  • Sorry, didn't notice the 1.3 factor - should be good.

    So,  for 1280*768@60fpd you have ~59M pixels/s. Running the LCD in RGB565 (16-bit) would require a bandwith of  ~118MB/s.

      Paul

     

  • Hi All,

    Why then in the Data sheet it is mentioed that WXGA is max resolution? Multiple places incl block diagram.

    And in Chapter 5.5, again it is said it can support 2048X2048!!!

    Please confirm.

    Best Regardss

    Feroz

  • Where Section 5.5 of the data sheet discusses as maximum resolution of 2048 x 2048 pixels, it also states the maximum frame rate is determined by the image size in combination with the pixel clock rate.

     

    Regards,

    Paul

  • Hi Paul,

    Why then do we mention WXGA (1280X768) )so many times in the data hseet. this is confusing adn should be replaced by 2KX2k. Please confirm.

    Best Regards

    Feroz

  • Hi Paul,

    Could you please help to clarify something about resolution that are possibly supported?

    - Looking at the TRM - spruh731i it seems that the pixel-per-line configuration need to be a multiple of 16.So ppllsb/pplmsb bit fields need to be programmed accordingly so that it is multiple of 16.

    Max resolution seems to be 1366 x 768 (chap 13.1.2 page 1596 of TRM) . However 1366 is not multiple of 16 so you need to either pick 1360 or 1376.

    - Then how to make sure the picture will fit accordingly on a native 1366 x 768 screen? On what parameters do you need to play?
    I am not sure you can play with the H/V Sync Width, H/V Back Porch, H/V Front Porch since those values are coming from the screen timings. Also the number of PCLK is linked with the screen native resolution so I don't think you can play with this value neither.

    Can 1366 x 768 screen be natively supported by the LCDC and then how?

    Thanks and best regards,

    Anthony

  • Anthony,

    The LCDC is in fact limited by the requirement that the number of pixels per line needs to be a multiple of 16. As a result, 1366x768 is not a directly supported resolution. However, I have seen others in the past configure the LCDC to be 1376 pixels per line and adjust their window geometry in linux to only write to the 1366x768 portion of a 1376x768 frame buffer, essentially ignoring the extra pixels in each line. This is something that would need to be tested though, some LCD panels don't respond well to the extra pixels while others just ignore it.

    The conflicting statement you're referring to in the TRM has been brought up recently and is misleading so it will be removed in the next TRM update.

    -Tyler