I'm having performances issues using emwin/appwizard, and i cant figure out if it is expected from that type of configuration with this type of hardware, or if i'm missing something.

Our client developped the interface using Appwizard, so we wouldn't have to modify our code every little design change.

Hardware is:
180MHz cortex M4F (LPC54607)
2Mbytes SDRAM 16bits @90Mhz
800*480 24bits display

I am using double buffering with GUIDRV_LIN_16 with GUICC_565.

so about 1.5Mbytes for vram, and 500kBytes for emwin memory.

emwin execution is from external qflash with eXecute In Place

all ressources are also on the flash (not enough flash in the uC).

Im running RTOS but there is no other task than this GUI task

The screen that showed me there was a problem has:

- 5 boxes
- about 50 text
- 7 images (about 100*100) each

when this screen is the first screen to load, it takes about 25 seconds to load.

When this screen is not the first one, it takes about 2m40s to load. same screen.

I was puzzeled so i tried with emWin without appwizard, the temperature control example.

reaction is quick, I'd say about 80-100ms. the screen is pretty full of elements aswell.

with the example i was able to test with emWin lib in CPU flash, it was a bit faster, but not by that much.


I am starting to beleive that the Appwizard eventloop costs way too much time to execute because of the "runtime configuration" aspect.

so first question is:

Is that the kind of speed that you expect from this configuration and this hardware?

and if it is not, do you have any idea how i can debug the reason of this slowness?



we are really trying to not have to redesign the interface using only EmWin (project has around 12 screen and 300 objects)


I hope you are able to direct me to a fix


Best regards,

Alexis Marquet

Thanks a lot for your answer,

I was able to change the format, first to "high color 565", with no noticable improvement, and then with auto, with a 10s improvement (going from about 25 to about 15 seconds) when the screen in question was the first one.

That led me to try this with the screens order the "original way", and again, load time was decreased by about 10seconds, from 2 minutes 40s down to 2 min 30s.

That problem is still not clear to me, why loading this screen first or loading this screen 4th would lead to such a different load time.

I wanted to try the GUIDRV_NULL that is discussed briefly in EmWin UM but that driver does not seem to be available without source code.

I looked into the flash being too slow, and with the temperature control, i was able to fit it in memory on chip and there is a slight improvement compared to execution off chip. The flash running with a clock at 96MHz in quadSPI, so it doesn't seem to me like that would be the bottleneck. again, there is a slight improvement running from internal flash, but nowhere near the kind of factor that would make this usable...



and when you mean "your CPU seems to be not that fast, especially with a screen of 800x480 pixels", i could understand it two ways:
1. the CPU seems to be running slow compared to the specs given
or
2. the chosen cpu specs seems too low, considering the 800x480

which were you thinking?


I was thinking that the problem was transparency (since multiplication for each pixel might add a lot of processing time), but that does not seem to fix the problem

I hope we can narrow it down,

Best regards,

Alexis Marquet
Hepia
Switzerland