Problem with low performance

[DCWR]

Hi,

We have a problem with low GUI performance on TFT.

Our HW setup:

• LPC1853 - Cortex-M3, 180 MHz
• External SDRAM - 90 MHz 
• TFT - 768x128px, RGB, TFT running at 10 MHz

Our SW setup:

• RGB565 format 
• single framebuffer (framebuffer footprint - 192kB)
• FreeRTOS

We setup uGFX and established initial code for that :

void APP_Init(void)
   {
   TFT_BacklightOnOff(true);
   Set_TFT_Backlight(PWM_100);

   SysInterfaceInit();

   // Create the initialization task
   xTaskCreate(APP_InitTask, "Init Task", 1024, 0, 1, &InitTaskHandler);
   vTaskStartScheduler();
   }

static void APP_InitTask(void* pvParameters)
   {
   gfxInit();

   xTaskCreate(APP_GuiTask, "Gui Task", 1024, 0, 1, 0);

   vTaskDelete(InitTaskHandler);
   }

static void APP_GuiTask(void* pvParameters)
   {

   for (;;)
      {
      gdispClear(Black);

      vTaskDelay(1000);

      gdispClear(White);

      vTaskDelay(1000);
      }
   }

 

And we quickly find out that it works slowly. It is easy to see the redrawing process. There is nothing else in the system. We are only drawing this in one task.

We tried also to show on the display .png file from USB stick. We set up a FatFs on that and tried to show pictures like that :

• Variant 1 - png format directly from USB;
• Variant 2 - the same picture converted to raw RG565 format;

// VARIANT 1
static void APP_GuiTask(void* pvParameters)
   {
   gdispImage myImage1;

   gdispImageOpenFile(&myImage1, "1:1.png");
   gdispImageCache(&myImage1);
   }

// VARIANT 2
static void APP_GuiTask(void* pvParameters)
   {
   gdispImage  myImage2;

   gdispImageOpenFile(&myImage2, "1:a.bin");
   gdispImageCache(&myImage2);
   }

Both ways gave us an answer: very slow performance.

We used cache mechanism to improve performance with a result: slow performance (a small improvement,  really small).

We also check how it looks when we use external flash memory (QSPI, 60 MHz) - nothing happens, GUI is still working slow enough to see the redrawing process.

Please see gfxconf.h in the attachment. Could you help us? 

 

PS. We made on this HW setup one project with commercial graphics framework, and we had good performance (with animations).

 

Best regards,

DCWR

 

gfxconf.h

[inmarket]

I presume you are using an M3 with the internal ltdc video controller. If that is not the case the below discussion may help even if it not directly applicable to your circumstances.

The problem is likely to be related to your external sdram and it's bandwidth. The proof of this is the slow performance (noticeable redraw speed) of the gdispClear loop.The image drawing tests are therefore meaningless until that problem is solved.

The first thing to try is putting the framebuffer into internal ram as a test. If that operates quickly the problem is your bus interface to the external sdram.

Note that if your framebuffer is in external ram do not put any other objects, heaps, stacks, code or anything else in that external sdram. Framebuffers are extremely bandwidth intensive just with video refreshing.

Other things to check are your CPU clock is running at full speed, wait states and speed and width of the sdram bus and also look for any other high speed requirement that may affect available bandwidth or speed.

[Joel Bodenmann]

I'd like to add some info: This is not a hardware problem but how your uGFX board file(s) are configured. That's the reason why you're getting better performance with a different solution. The LTDC stuff allow for a lot of different configurations - You have to go through everything and figure out what the right ones for your hardware are. Especially check on DMA2D.
Also don't forget to set your CPU and compiler in the uGFX configuration file.

[DCWR]

On 06/11/2018 at 13:31, inmarket said:

I presume you are using an M3 with the internal ltdc video controller. If that is not the case the below discussion may help even if it not directly applicable to your circumstances.

The problem is likely to be related to your external sdram and it's bandwidth. The proof of this is the slow performance (noticeable redraw speed) of the gdispClear loop.The image drawing tests are therefore meaningless until that problem is solved.

The first thing to try is putting the framebuffer into internal ram as a test. If that operates quickly the problem is your bus interface to the external sdram.

Note that if your framebuffer is in external ram do not put any other objects, heaps, stacks, code or anything else in that external sdram. Framebuffers are extremely bandwidth intensive just with video refreshing.

Other things to check are your CPU clock is running at full speed, wait states and speed and width of the sdram bus and also look for any other high speed requirement that may affect available bandwidth or speed.

I would like to notice, that we have to use external RAM as a Framebuffer (we do not have 200kB in internal RAM).

Heap after adding file system on external Flash/USB grows up to enormous size (png converter) - we have to keep it in external RAM also.

We use the same external RAM configuration (and the same HW) for TouchGFX framework, and it works fine.

 

On 07/11/2018 at 13:16, Joel Bodenmann said:

I'd like to add some info: This is not a hardware problem but how your uGFX board file(s) are configured. That's the reason why you're getting better performance with a different solution. The LTDC stuff allow for a lot of different configurations - You have to go through everything and figure out what the right ones for your hardware are. Especially check on DMA2D.
Also don't forget to set your CPU and compiler in the uGFX configuration file.

We don't have LTDC on NXP mcu. We set up CPU and compiler in configuration file.

We spent time to figure out how to handle our external RAM and FLASH properly. And we prove it on commercial product with TouchGFX on board. Now we would like to check your library. And we can not find out how to solve performance problem.

We have problem with filling the screen with color, and we have huge problem with showing .png file from external memory (even if it cached in RAM).

 

DCWR