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
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.
void RA8876::drawPixel(int x, int y, uint16_t color)
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);
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.