LVGL is very slow - STM32F7 SSD1963 P16 - Advice on how to optimise it?

RGarrett93 · February 18, 2021, 12:42pm

LVGL is very slow - STM32F7 SSD1963 P16 - Advice on how to optimise it?

What MCU/Processor/Board and compiler are you using?

Nucleo 144 STM32F767ZI

What LVGL version are you using?

7.11.0

What do you want to achieve?

I want to increase performance for LVGL running on a Nucleo 144 F767ZI with a 7" SSD1963 display, currently the speed for scrolling/ animations is too slow.

What have you tried so far?

I have tried adjusting the display driver (my_disp_flush) and increased the refresh rate but cant seem to speed things up

I have also tried disabling the ICache and DCache in case that was slowing things down.

Code to reproduce

This draws everything correct but is very slow

void my_disp_flush(lv_disp_drv_t *disp, const lv_area_t *area, lv_color_t *color_p)
{
  uint16_t c;
    tft.setWindow(area->x1, area->y1, area->x2, area->y2 ); // set the working window 
    for (int y = area->y1; y <= area->y2; y++) {
      for (int x = area->x1; x <= area->x2; x++) {
        c = color_p->full; 
        tft.pushColor(c, 1);
        color_p++;
     }
  }
  lv_disp_flush_ready(disp); // tell lvgl that flushing is done 
}

Screenshot and/or video

Video attached

Nucleo 144 LVGL demo video.zip
Nucleo 144 LVGL demo video.zip (2.3 MB)

RGarrett93 · February 18, 2021, 12:58pm

I have just realised disabling the ICache & DCache was actually slowing things down, re-enabling it all again has sped things up.
That was my bad for testing several combinations and leaving the Caches disabled.

I still get a bit of screen tearing but not as bad as shown in the video above.

barbiani · February 18, 2021, 9:02pm

Try doing the tft window update using dma and calling disp_flush_ready in the dma complete interrupt.

zapta · February 18, 2021, 10:30pm

What kind of connection do you have to the TFT, SPI? 8 bit parallel? 16 bit parallel? Something else? Different kinds of connections vary in their max speed. Also, a DMA and dual buffering will rendering and transfer to the TFT at the same time.

As for your code, you can optimize that loop. Also, I don’t know how tft.pushColor() is implemented by probably you can optimize it as well (e.g. no need to always pass a ‘1’ in your most inner loop).

You can see here an example of an optimized loop, only one level of loop, and it performs multiple pixels in one iteration.

github.com

zapta/simple_stepper_motor_analyzer/blob/master/platformio/src/display/tft_driver.cpp#L218


#define RENDER_NEXT_PIXEL                               \
  {                                                     \
    const uint64_t bssr64 = ram_color_bssr_table[*p++]; \
    GPIOA->BSRR = (uint32_t)bssr64;                     \
    GPIOB->BSRR = (uint32_t)(bssr64 >> 32);             \
    TFT_WR_HIGH;                                        \
  }

// This function is time critical since it dominates the screen update time.
// LVGL writes to the screen via this function.
extern void render_buffer(uint16_t x1, uint16_t y1, uint16_t x2, uint16_t y2,
                          uint8_t* color8_p) {
  setAddrWindow(x1, y1, x2, y2);

  const int32_t w_pixels = x2 - x1 + 1;
  const int32_t h_pixels = y2 - y1 + 1;

  uint8_t* p = color8_p;
  uint32_t pixels_left = w_pixels * h_pixels;

  // The code below was optimized for fast rendering, since it

RGarrett93 · February 25, 2021, 7:25am

I am using 16 bit parallel, I have just got FMC working which has considerably improved the performance. I believe my control method for the display driver can be better optimised.
For instance removing the ‘1’ on my len inner loop for pushcolor

I will look at your examples and see if I can utilise that and improve on how I am doing it now.

I have attached a video of the current performance utilising FMC which I am quite impressed with now.Nucleo 144 LVGL FMC demo video.zip (1.9 MB)

RGarrett93 · February 19, 2021, 11:16am

What about optimising the loop so I can push 32 pixels in one iteration instead of individually like below?

Its quicker to redraw the screen but seems to leave stray pixels on the screen when scrolling

void my_disp_flush(lv_disp_drv_t *disp, const lv_area_t *area, lv_color_t *color_p)
{
 static uint16_t temp[32];
  int i=0;
  tft.setWindow(area->x1, area->y1, area->x2, area->y2); // set the working window 

  for (int y = area->y1; y <= area->y2; y++) {
    for (int x = area->x1; x <= area->x2; x++) {
       temp[i] = color_p->full;
       i++;
       if (i==32){   
       tft.pushColors(temp, i);
       i = 0;
       }
      color_p++;
    }
  }
  lv_disp_flush_ready(disp); // tell lvgl that flushing is done 
}

embeddedt · February 19, 2021, 2:18pm

At first glance, this loop will fail if there are less than 32 pixels total to redraw, since you only send pixels once i == 32.

RGarrett93 · February 19, 2021, 6:48pm

That is true, I’ve not had it occur where less than 32 pixels is not updated… but an issue could arise from it.
I thought I was being clever storing an array to better optimise it.

I will stick with the below as its working well and the speed is good.
I can use some examples to work on the driver and eventually improve.

void my_disp_flush(lv_disp_drv_t *disp, const lv_area_t *area, lv_color_t *color_p) { 
uint16_t c; 
tft.setWindow(area->x1, area->y1, area->x2, area->y2 ); // set the working window
for (int y = area->y1; y <= area->y2; y++) { 
for (int x = area->x1; x <= area->x2; x++) { 
c = color_p->full; 
tft.pushColor(c); 
color_p++; 
}
} 
lv_disp_flush_ready(disp); // tell lvgl that flushing is done
}

robekras · February 20, 2021, 10:24am

Better to say the function fails if ((area_width * area_height) % 32) != 0

But it should work if you add the if (i != 0) {…} just after the for loops

  for (...) {
    for (...) {
    }
  }
 
  if (i != 0) {
     tft.pushColors (temp, i);
  }

  lv_disp_flush_ready (disp); // tell lvgl that flushing is done

You observed a better performance with FMC.
When the SSD1963 is connected as a memory mapped device, you can also try to
transfer the pixel data via DMA.

Nevertheless you should omit the intermediate buffer temp[32].
The pixeldata is already located at a sequential memory area (*color_p),
and copy from one buffer to another one doesn’t make really sense.

zapta · February 20, 2021, 5:00pm

Do you have the source code of tft.pushColors() ? Can yo post it here?

RGarrett93 · February 25, 2021, 7:26am

Thank you for that information.

The library is called GxTFT, I was in contact with the developer trying to get the STM32F7 chipset to work.
It now works directly with FMC which has made a great difference compared to bitbashing.

The library is great as everything is separated with classes, it makes adding new hardware easier.

tft.pushColors()

void GxTFT::pushColors(uint16_t *data, uint8_t len)
{ 
IO.startTransaction(); 
while (len--) { 
uint16_t color = *data++; 
IO.writeData16(color); 
} 
IO.endTransaction();
}

zapta · February 22, 2021, 6:43am

Are IO.startTransaction() and IO.endTransaction() real methods that are called for each pixels. This sounds very non efficient. You may have a lot of room for optimization here. Same for inline whatever writeData16() does in your own render loop.

RGarrett93 · February 22, 2021, 7:56am

No they are not real methods, in this current situation as we’re using FMC they’re just an empty function but if another user was using regular bitbashing then it would be incorporated.

void GxIO_STM32Nucleo144_FSMC::startTransaction()
{
} 
void GxIO_STM32Nucleo144_FSMC::endTransaction()
{
}

The library seperates the tft controller and IO (MCU), because it has support for lots of different setups… it has to cover all scenarios, so some functions are relevant whereas others are not.
This is where I can modify use the relevant bits and disregard the rest.

Initialising FMC

void GxIO_STM32Nucleo144_FSMC::init()
{ 
RCC->AHB1ENR |= 0x00000078; // enable GPIOD, GPIOE, GPIOF and GPIOG interface clock 
volatile uint32_t t = RCC->AHB1ENR; // delay 

GPIOD->AFR[0] = ( GPIOD->AFR[0] & ~PD_AFR0_MASK) | PD_AFR0_FSMC; 
GPIOD->AFR[1] = ( GPIOD->AFR[1] & ~PD_AFR1_MASK) | PD_AFR1_FSMC; 
GPIOD->MODER = ( GPIOD->MODER & ~PD_MODE_MASK) | PD_MODE_FSMC; 
GPIOD->OSPEEDR = ( GPIOD->OSPEEDR & ~PD_MODE_MASK) | PD_OSPD_FSMC; 
GPIOD->OTYPER &= ~PD_MODE_MASK; 
GPIOD->PUPDR &= ~PD_MODE_MASK; 

GPIOE->AFR[0] = (GPIOE->AFR[0] & ~PE_AFR0_MASK) | PE_AFR0_FSMC; 
GPIOE->AFR[1] = (GPIOE->AFR[1] & ~PE_AFR1_MASK) | PE_AFR1_FSMC; 
GPIOE->MODER = (GPIOE->MODER & ~PE_MODE_MASK) | PE_MODE_FSMC; 
GPIOE->OSPEEDR = (GPIOE->OSPEEDR & ~PE_MODE_MASK) | PE_OSPD_FSMC; 
GPIOE->OTYPER &= ~PE_MODE_MASK; 
GPIOE->PUPDR &= ~PE_MODE_MASK; 

RCC->AHB3ENR |= 0x00000001; 
t = RCC->AHB1ENR; // delay 
(void)(t); 

FMC_Bank1->BTCR[0] = 0x000010D9; 
FMC_Bank1->BTCR[1] = (DATAST << 8) | ADDSET;
// swap FMC_REGION used to an address range that has data cache disabled 
SYSCFG->MEMRMP |= SYSCFG_MEMRMP_SWP_FMC_0; 

digitalWrite(_bl, LOW); 
pinMode(_bl, OUTPUT);
}

FMC region

//#define FMC_REGION ((uint32_t)0x60000000) 
// Bank1 FMC NOR/PSRAM
// swap FMC_REGION used to an address range that has data cache disabled
// see e.g. https://community.st.com/s/question/0D50X00009XkWQESA3/stm32h743ii-fmc-8080-lcd-spurious-writes

#define FMC_REGION ((uint32_t)0xC0000000) // Bank1 FMC NOR/PSRAM swapped with SDRAM 
#define CommandAccess FMC_REGION
#define DataAccess (FMC_REGION + 0x80000)

writeData16

void GxIO_STM32Nucleo144_FSMC::writeData16(uint16_t d, uint32_t num)
{ 
while (num > 0) 
{ 
*(uint16_t*)DataAccess = d;
num--; 
}
}

RGarrett93 · February 24, 2021, 10:52pm

Has anyone got any examples of LV drivers in action with LVGL?

zapta · February 25, 2021, 4:18am

I am not sure what exactly you are looking for but if just an example LV drivers that work, mine are here https://github.com/zapta/simple_stepper_motor_analyzer/tree/master/platformio/src/display .

tft_driver is the low level driver and lv_adapter is the interface to LVGL. Running on a 84Mhz STM32F401CE, the pixel transfer rate is 10M x 16bit pixels per sec. No DMA, just bit banging, and on the fly conversion from LVGL 8 bit color depth to the TFT 16 bit color depth. These barley achieves smooth horizontal scrolling of the chart in my app, and plenty fast for all the other screens.

RGarrett93 · February 25, 2021, 7:38am

Thank you,

That’s exactly what I was after, I wanted an example to observe: I was trying to find one on github.
I fancy rewriting what I’ve got now using LV drivers with FMC on the Nucleo-F767ZI.

My current setup is working well but I want to neaten things up on the code.