QSPI SRAM as framebuffer and Parallel or MIPI DSI?

[ShadyOptics]

Hi,

I have some questions regarding the implementation of an LCD with the STM32F479ii.

The display we want to use, has a 800x480 resolution at 60Hz and can have either 16 or 24 bit color depth.

A framebuffer for a display like that is of course not going to fit inside the 384kb of internal sram, so we will need external ram.

I have read the application note on the LTDC (AN4861) and it does mention that the F479ii supports mapped QSPI sram, but nowhere does it mention using QSPI sram for the framebuffer.

Of course QSPI will be slower than a parallel interface to the external ram, but QSPI certainly has a preference over the much simpler hardware design, even when comparing it to a 16 bit interface.

So question 1: Is QSPI sram fast enough to be used for the framebuffer, considering that it would be used for nothing but the framebuffer (everything else runs in internal sram)?

Then there is the interface to communicate with the display. The F4 supports both 24 bit parallel as well as MIPI DSI. I can't really find any real (dis)advantage for either one.

Most come down to hardware design, lots of pins vs only 6 pins, but at the cost of a much higher throughput and thus harder to debug and more hardware design constraints.

Question 2: Are there any major (dis)advantages to using MIPI DSI over a parallel interface that I'm missing?

Thanks in advance!

[Tesla DeLorean]

I don't think the F479 supports QSPI RAM.

Personally I think the bandwidth would be significantly constraining, basically halved by need to render, and update the frame-buffer.

You could perhaps serve static images from QSPI NOR Flash, perhaps you should try that, see if the rips, or has contention issues.

The DSI allows for a smaller more routable cable, the design and screen placement in your final design might dictate the interfacing you choose.

A cable with 26+ conductors banging rail-to-rail at 25 MHz with all sorts of modulation might a significantly more complex radiator.

Absent sufficient resources on the MCU, one would typically consider a display interfaced via FMC or SPI, which had it's own controller and frame-buffering resources.

[Tesla DeLorean]

"I don't think the F479 supports QSPI RAM"

Let me rephrase that..

It's not going to support it in a way that rational developers would need/want it too to achieve goals of acting as a random access memory, within the MCU address space, with read, write and DMA operation.

[ShadyOptics]

If you look at page 11 of AN4861, it says:

"There are volatile Quad-SPI SRAM (static random-access memory) available from Microchip, ON Semiconductor and others. Available non-volatile Quad-SPI Flash memories. NOR, NAND"

So that made me think that it does support it. However, I can't find anyone that does use it, let alone for a framebuffer so I'm not hopeful.

Your point about parallel vs DSI is certainly a fair one and probably something that will push me more toward DSI.

[Tesla DeLorean]

I think the app note covers a lot of territory, not seeing that quote in V3

https://www.st.com/resource/en/application_note/dm00287603-lcdtft-display-controller-ltdc-on-stm32-mcus-stmicroelectronics.pdf

One of the F479 pages says "The Dual-mode Quad-SPI running at 90 MHz enables cost-effective NOR Flash and supports memory-mapped mode.", and I'm pretty sure it is an early instantiation of the QSPI peripheral, and only recall it having a singular template for the memory-mapping mode, which is what the LTDC is going to need to fetch against.

https://www.st.com/en/microcontrollers-microprocessors/stm32f469-479.html