Optimizing ILI9488 SPI Display Performance with STM32G0B0VET6 – Too Slow?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-04-14 11:22 PM
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!
- Labels:
-
LCD-LTDC
-
SPI
-
STM32G0 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-04-14 11:45 PM
> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-04-14 11:54 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-04-15 3:08 AM
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-04-15 3:14 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-04-15 3:19 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-04-15 3:42 AM
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.
