What would be the best CPU platform for the LittlevGL?

Hi everyone,

I am making a plan to develop an MCU bord, on which the LittlevGL suppose to run over FreeRTOS. The board will support over 7" to 10.1" TFT LCD with a touch screen.
I consider which CPU I employ for the project; STM, Microchip, NXP, TI, or Allwinner, etc.

Which CPU do you think the best (off the top of your head)? In terms of the price-performance ratio and the development tool friendly.


In terms of price-performance - you should consider ESP32.

1 Like

I see only 1 issue with ESP32. It has only SPI port to drive a display and a 7"-10" TFT could have quite large resolution (800x480?) So e.g. to send 800x480x32 bit even with a 80MHz SPI would take 150 ms for every frame.

It’s not entirely correct, ESP32 can also drive 8-bit parallel bus.

1 Like

Thanks, I didn’t know about it!

Ive tried the parallel spi and yes it works. i just have to choose the non parallel one cause i needed more pins and i only have the 2.4” version. And the pins are really designed to fit an uno.
I am thinking another possible project for this one.

A board should be designed for this lcd. I can contribute a pcb layout for such a board. :slight_smile:

1 Like

I’m using an Atmel (sorry, Microchip) SAMA5D27 with 5" and 7" resistive touch LCDs, 800x480 24 bit RGB interface. Performance is NOT an issue :slight_smile: The number of other peripherals on this <$10 processor means it’s a total winner for my project!

1 Like

ESP32 is working great for me. I’m using a 3.5" touch TFT (320*480 - SPI) and the refresh rate is only noticeably slow when refreshing the whole screen…
I’ll be posting a demo video here soon…

1 Like

Thanks for the information! Microchip (Atmel?) SAMA5D27 looks to be becoming a dark-horse.
The ESP32 is also attractive for small LCDs, but I worry it doesn’t have dedicated LCD interface pins for larger LCDs.

Found this:

1 Like

I would like to use LittlevGL in my new project, but I am not sure if my uC has enough capabilities.
I want use STM32F030CCT6(48Mhz, 256Kb flash, 32kB Ram).
anyone tried to run LittlevGL on mcu like this - I mean max 48mhz freq.
my LCD(4inch 480×800 Pixels ) has 16-bit parallel interface and SPI touch driver.
What fps can I expect on this mcu? I need create some settings menu, (few buttons, calendar and maybe keyboard), in main screen I need only refresh some numbers and LED icon.
I will be grateful for the advice.

Such a large displays are usually driven by 200 MHz MCUs from STM32F7 family. It should work with an F0 too but your UI needs to be very simple without animations, opacity or other complex things.

Just a quick calculation: let’s say you have a 10 MHz parallel port. Sending 800x480 = 384,000 pixel with 10MHz takes 38ms. And it’s just sending the rendered image, not counting the rendering time.

If you had more RAM you could configure lvgl in double buffered mode in which while the data is being sent to the display from buffer, lvgl can render to an other buffer. But optimally a buffers should be 1/10 screen sized (or 1/20 at worst case). But even an 1/20 screen sized buffer needs 37.5 k RAM. With a really small buffer (e.g. 1/100 , 10 kB) even the rendering will be very slow.

So I’d suggest choosing a faster MCU for such a large display.

1 Like

I can’t choose stm32F7 because is to expensive( I have limited price for one piece in end production).
Are you sure 1/20 need 37.5k RAM? Not 18.75k?
I wonder about that mcu STM32F446RET6(180Mhz, 512Kb FLash, 128Kb RAM). If I calculated well I will be able to create two 1/10 size buffers. Will it run smoothly?

800*480/20 = 18.75k but you have 2 bytes per pixel so 18.75 * 2 = 37.5k.

It sounds much better. The FPS depends on the complexity of the UI. Having some buttons and text surely not a problem. But e.g. scrolling screen-sized lists might be slow. A half screen list should be acceptable. Note that I’m telling it from my experience, and not measured it. To tell more exact speed estimations it’d required to see some screenshots from the UI and make some test on a similar dev board.