Optimizing ILI9488 SPI Display Performance with STM32G0B0VET6 – Too Slow?

[Aldrin]

Hi everyone,

I'm working on a project using the STM32G0B0VET6 microcontroller, and I have an ILI9488 TFT display (320x480) connected via SPI. There is no external display controller – the STM32 is driving the display directly.

Problem
The display works and renders correctly using custom drivers, but the refresh/update speed is very slow, especially when trying to render large bitmaps or full-screen updates. This is a major bottleneck in my application.

What I've Tried

• Using SPI1 at the highest possible baud rate (around 24–27 MHz).
• Optimizing HAL_SPI_Transmit() and buffering with DMA.
• Rendering images with a tile-based approach to avoid RAM overflow (since STM32G0B0 has only 144KB RAM).
• Converting and sending RGB565 bitmaps using a fast push function.
• Even tried lower-resolution images scaled up – no significant improvement.

Questions

• Is it realistically possible to achieve smooth full-screen updates with this MCU driving the ILI9488 directly over SPI?
• Am I wasting time trying to optimize this on an STM32G0 series chip without external display control?
• Has anyone had success with speeding up ILI9488 performance on low-power STM32s?
• Any tips on improving SPI display throughput or managing full-screen rendering more efficiently would be appreciated.

Thanks in advance!

[Ozone]

> I'm working on a project using the STM32G0B0VET6 microcontroller, and I have an ILI9488 TFT display (320x480) connected via SPI.

> .. using SPI1 at the highest possible baud rate (24-27 MHz)

That gives you 320 * 480 * 2 bytes to transfer, i.e. 307.200 bytes, or 2.457.600 bits total.
Even at 27 MBit/s, a full screen update requires almost a second - at best.

I would think your choice of MCU, display, and rendering/throughput requirements don't go well together.
One has to give.

[RobK1]

Do you have the source code for the drivers you are using?

I have an application with an ILI9163V and the driver I found for that controller did not correctly use the windowing/auto-increment function of the controller. After correcting that, I had a ~20x improvement in update speed. 

[alfsch]

Hi,

what is " too slow" ?

(as @Ozone wrote ) you can expect only as a max. possible speed, what the SPI interface can write at the limit of the ILI chip : full screen write , cls , would be about 2.457.600 bits , at 24Mbit -> 100 ms , is absolute maximum you can reach - just from possilble speed of ILIxxx SPI interface.

Whats your speed now, for a "cls" , full screen fill ?

[Aldrin]

https://github.com/RobertoBenjami/stm32_graphics_display_drivers/blob/master/Drivers/lcd/ili9488/ili9488.c

[Aldrin]

Too slow in the sense, even while using trying to print an image it take about more than 3 sec to fill the whole screen.

cls happens in less than a sec but still can be observed.

[Ozone]

You didn't mention the use case.

So, if these time requirements are not acceptable to the user, you could either use a smaller display, or choose a configuration which drives the display with a parallel interface.

With some knowledge of the MCU and the interfacing method, you can estimate the data throughput (required vs. delivered) accurately enough to check for your requirements.