cancel
Showing results for 
Search instead for 
Did you mean: 

Optimizing ILI9488 SPI Display Performance with STM32G0B0VET6 – Too Slow?

Aldrin
Associate II

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!

6 REPLIES 6
Ozone
Principal

> 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
Associate III

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
Associate II

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 ?

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
Principal

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.