LPC1787 emWin Performance

[lpcware]

Content originally posted in LPCWare by mikeDonahoe on Wed Jun 17 10:15:34 MST 2015
I have an issue with the performance of an emWIN application that is too large to fit in internal flash.   Currently I have  a stage 1 (u-boot) that is initializing all hardware and then running the main application from SDRAM.  The system has 32MB of SDRAM and I have noticed that if I clock the processor down from 120 to 84 and then set the EMC to 84 (was CPU 120 EMC 60) that there is a noticeable improvement in rendering content to the screen.  I've read the forums question concerning performance and I am now in the process of moving the most used calls out of SDRAM and into IRAM.  Are there any other options that I should take to improve the performance?


Size output
   text   data    bss    dec    hexfilename
496332  159601336835613880648 d3cd48


Linker Script

ENTRY(ResetISR)

SECTIONS
{

    /* MAIN TEXT SECTION */    
    .text : ALIGN(4)
    {
    FILL(0xff)
KEEP(*(.isr_vector))

/* Global Section Table */
. = ALIGN(4) ;
__section_table_start = .;
__data_section_table = .;
LONG(LOADADDR(.data));
LONG(    ADDR(.data)) ;
LONG(  SIZEOF(.data));
__data_section_table_end = .;
__bss_section_table = .;
LONG(    ADDR(.bss));
LONG(  SIZEOF(.bss));
__bss_section_table_end = .;
__section_table_end = . ;
/* End of Global Section Table */

        *(.startup*)
        . = ALIGN(4);
    } > RamLoc64
    
    .images : ALIGN(4)
    {
     *(.image*)
    } > RamLoc64
 .rodata : ALIGN(4)    
    {
        *(.text*)
        *(.rodata .rodata.* .constdata .constdata.*)
        . = ALIGN(4);
        
    } > RamEXT

    /*
     * for exception handling/unwind - some Newlib functions (in common
     * with C++ and STDC++) use this. 
     */
    .ARM.extab : ALIGN(4)
    {
    *(.ARM.extab* .gnu.linkonce.armextab.*)
    } > RamEXT
    __exidx_start = .;
    
    .ARM.exidx : ALIGN(4)
    {
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    } > RamEXT
    __exidx_end = .;
    
    _etext = .;
        
    
    /* MAIN DATA SECTION */
    

    .uninit_RESERVED : ALIGN(4)
    {
        KEEP(*(.bss.$RESERVED*))
        . = ALIGN(4) ;
        _end_uninit_RESERVED = .;
    } > RamEXT


/* Main DATA section (RamEXT) */
.data : ALIGN(4)
{
   FILL(0xff)
   _data = . ;
   *(vtable)
   *(.ramfunc*)
   *(.data*)
   . = ALIGN(4) ;
   _edata = . ;
} > RamEXT AT>RamEXT


    /* MAIN BSS SECTION */
    .bss : ALIGN(4)
    {
        _bss = .;
        *(.bss*)
        *(COMMON)
        . = ALIGN(4) ;
        _ebss = .;
        PROVIDE(end = .);
    } > RamEXT
    
    
    /* DEFAULT NOINIT SECTION */
    .noinit (NOLOAD): ALIGN(4)
    {
        _noinit = .;
        *(.noinit*) 
         . = ALIGN(4) ;
        _end_noinit = .;
    } > RamEXT
    
    /* SDRAM */
.VRAM (NOLOAD) : ALIGN(4)
{
  *(.VRAM)
} > RamEXT

.GUI_RAM (NOLOAD) : ALIGN(4)
{
  *(.GUI_RAM)
} > RamEXT
    
    PROVIDE(_pvHeapStart = DEFINED(__user_heap_base) ? __user_heap_base : .);
    PROVIDE(_vStackTop = DEFINED(__user_stack_top) ? __user_stack_top : __top_RamEXT - 0);
}

[lpcware]

Content originally posted in LPCWare by mikeDonahoe on Mon Jun 22 09:12:01 MST 2015
Thank you for the suggestions I will report back any improvements.

[lpcware]

Content originally posted in LPCWare by wmues on Thu Jun 18 01:00:56 MST 2015
Make the Bank address bits of the SDRAM to be the upper address bits, and put the code into the lower address range of the SDRAM, and the framebuffer into the upper address range of the SDRAM. So the code will have an open bank all the time, and the framebuffer DMA will have another open bank all the time. No more need to waste time for open a bank for the framebuffer DMA.

Use a 16bit (RGB 565) framebuffer, not 24bits. Do ordered dithering if you want high quality output.

Urgent: put your stack into internal RAM. This will make a big performance difference.

regards
Wolfgang

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Wed Jun 17 11:21:15 MST 2015
Running out of SDRAM, you also have to contend with contention with access to code and access to image data.
There is only one bus (the System bus) for external RAM. Code in flash or in internal SRAM access code via (and
concurrently) using the I bus.

We opted out of placing code in SDRAM for this very reason, although different applications will have different
requirements and/or constraints.

Cheers, Mike.