LTDC maximum display resolution documentation inconsistency?

[luke23]

Posted on January 10, 2018 at 02:34

Hi

AN4861 (

http://www.st.com/content/ccc/resource/technical/document/application_note/group0/25/ca/f9/b4/ae/fc/4e/1e/DM00287603/files/DM00287603.pdf/jcr:content/translations/en.DM00287603.pdf

) page 25 states that the LTDC display peripheral can support total width up to 4096 pixels.

However, STM32F439 Reference (

http://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf

) page 481 says 'Supports up to XGA (1024x768) resolution.'

Same for STM32F756 (

http://www.st.com/content/ccc/resource/technical/document/reference_manual/c5/cf/ef/52/c0/f1/4b/fa/DM00124865.pdf/files/DM00124865.pdf/jcr:content/translations/en.DM00124865.pdf

) page 505 - 'Supports up to XGA (1024x768) resolution.'.

Further, in the STM32F439 reference (above) page 494, in the description for the LTDC_AWCR register, it shows there are more bits available than the maximum values shown;

 - AAW 0x400(1024H) - 12 bits available should support up to 4096, and

 - AAH 0x300(768V) - 11 bits available should support up to 2048.

What's the story - are these parts actually limited?  Is there a nice reference showing actual capabilities of all LTDC MCU's?  Which should be taken as truth?

[Jan Waclawek]

Posted on January 10, 2018 at 06:53

The issue is the available data bandwidth thus attainable refresh rate. Displays wouldn't tolerate too low refresh rates, similarly to extensive blanking intervals, this too would lead to out-of-spec thus unpredictible results.

Mind, data for refresh have to be transferred through the internal bus matrix, all the time, fighting with other bus masters (processor, DMA). Aggravating the issue more, you'd need external memory, presumably SDRAM, which adds latencies and bandwith issues of its own and on the FMC interface, too.

Try to play with the F429 Disco or similar to get a feeling what can you expect. Use two display planes and maximum source data width to see the effect.

Try ro perform some back of the enelope calculations in this regard.

There are several 'display drop/tearing' threads here, invariably leading to insufficient bandwidth.

Do you still want to spare the cost of controllers? One of the upsides is that you may spare on mcu package, unless you want to have some large data source (NAND FLASH).

JW

[PaulCox]

Thank for this answer. It seems to imply that you are comfortable with attaining normal refresh rates for display of 1024x7689 or below, and that resolutions above that up to the 2k+ pixels allowed by the register sizes may or may not work as the interface bandwidth will limit the overall refresh rates and that displays may or may function in such modes. Can you confirm that understanding? Also, the DSI display I need to drive is 1080x1200 @24bit (1275x1210 total) and the datasheet calls out 90Hz. It lists the controller as RM69071 but can't find a datasheet to see if a lower refresh can be tolerated. Any reason you can think of that would argue it's not even worth trying? This application only needs to show pictures so ony a very low final refresh rate is necessary, I just don't want any flicker of course. Any tricks exist for creating a 90Hz refresh rate from a say 10 Hz coming from the STM32? Would that require an big FPGA? Thanks for any tips!

[Tesla DeLorean]

I don't even think the DSI implementation will sustain the prescribed rate. The STM32 only implements two of the four lanes, so perhaps 1Gbps. I think I was able to drive 1024x768-16bpp-57Hz

I would look at the counter bit widths being the first limit, and the second the sustainable bandwidth of the LTDC and data buses/memories.

You might need to query Raydium directly for a data sheet for the lcd controller

You'd likely need to create your own frame buffering and DSI interfacing implementation, a pretty non-trivial task given the data rates involved.

[waclawek.jan]

Displays which don't have integrated framebuffer in their controller, require peranent refresh at the prescribed rate, no matter whether the picture is static or changing.

For bandwidth issues etc. read AN4861.

JW