Speed on GEVINO TFT

Get started
1

I am the manufacturer of this display, GEVINO TFT, arduino compatible, with integrated PLC functions.
I cannot post the linK due the forum restriction.

I would like to put lvgl but I am afraid it is too slow.

My display has a lot of pixels and the communication is SPI 12Mhz
The controller has a very high speed in creating primitives, characters and picture, from DMA flash chip .
However, the writing of the single pixel is slow.

1024x600 = 0.6 Mpixel
For each pixel need to send 6 byte = 3.6 Mbyte on SPI
At 12Mhz of SPI is 3.3Hz = 300mS

Can you suggest me whether to try, would it be profitable or it will be too slow anyway?

• CPU ATSAMD21G18 - Arduino ZERO M0 compatible.
• 48 Mhz, 32-bit ARM® Cortex®-M0+ processor.
• Flash 256KB, RAM 32K

2

Hi,
I’m afraid that the SPI clock is the bottleneck, or that’s the first thing I would suspect if, specially with such display dimensions.

Let’s see what others say.

3

Why do you need to send 6 bytes per pixel? Normally it’s only 2 byte/pixel with RGB565 color format or 3 bytes with RGB888 format.

However, even if you could speed up the SPI somehow the 48 MHz MCU is still very slow for such a large display. LVGL wants to render in MCU’s RAM (or external SRAM) first and send the rendered image to the display. So LVGL can use only the GPU of the MCU but not the graphics engine in the external display controller. It’s because the external display controller renders in its memory, where the LVGL and the MCU have no direct access.

Have look at this summary about the drawing mechanism of LVGL: https://docs.lvgl.io/latest/en/html/overview/drawing.html

4 
void RA8876::drawPixel(int x, int y, uint16_t color)
{
  //Serial.println("drawPixel");
  //Serial.println(readStatus());

  SPI.beginTransaction(m_spiSettings);

  writeReg(RA8876_REG_CURH0, x & 0xFF);
  writeReg(RA8876_REG_CURH1, x >> 8);

  writeReg(RA8876_REG_CURV0, y & 0xFF);
  writeReg(RA8876_REG_CURV1, y >> 8);

  writeReg(RA8876_REG_MRWDP, color & 0xFF);
  writeReg(RA8876_REG_MRWDP, color >> 8);

  SPI.endTransaction();
}
5

You might be able to speed things up if you can avoid setting the cursor on every pixel (i.e. if the display can advance to the next column automatically).

6

But all video buffer must be on CPU RAM ?
SAMD have 32KB ram and TFT buffer is 1.2MB
I have app note, about LVGL And RAIO chip.
But there are not way for upload here or add drop box link

7

The speed of the SPI may not be a problem, especially if use DMA

There are 3 possible configurations regarding the buffer size:

  1. One buffer LVGL draws the content of the screen into a buffer a

The only problem can be so little RAM
SAMD have 32KB ram and TFT buffer is 1.2MB

Dedicating 10KB of RAM buffer, on a 1.2MB Display, what can be powerful ?

I wasting my time if I make porting ?

8

1024x600 is a very large resolution to be driving over a SPI interface. 10KB of RAM probably won’t be enough to achieve a smooth frame rate. It would mean that LVGL can only redraw 1.6% of the display’s area at a time. That may be acceptable for displays which refresh rarely, but I think animations will be extremely choppy with frequent tearing.

On a display of this size LVGL usually works best with a proper LCD controller that has the framebuffer located in CPU-accessible memory. A controller like yours which is designed to do the rendering itself is not really something LVGL can take advantage of.

1 Like
9

I can confirm this,