emWin for NXP MCU without any external memory or SDRAM

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • emWin for NXP MCU without any external memory or SDRAM

      Hi,
      I want to develop a project using LPC54608J512 MCU from NXP.

      While using the LPCXpresso54608 Development Board I have done very good GUI with the help of emWin Library that comes with SDK from NXP MCUXpresso.

      Now I want to implement a project without Development Board, only using LPC54608J512 MCU.
      But emWin works only when I use SDRAM - I need to initialize it with:
      BOARD_InitSDRAM();

      The LPC54608J512 MCU has enough memory itself to handle framebuffer and the code:
      512 KB of internal flash, 200 KB of on-chip SRAM.

      I have read in another post that it is necessary to change some values in "LCDConf.c" file - LCD_LAYER0_FRAME_BUFFER and GUI_BUFFER_ADDRESS
      (maybe something else???).

      But I do not have "LCDConf.c" file. I have only pre-complied library “libemWin_M4F.a”
      MCUXpresso says I have emWin "GUI_VERSION 53800".

      Is possible in this case to implement emWin project without SDRAM? The resources of internal memory of MCU are more than enough for it.

      Thank you.
    • Hi,

      I have read in another post that it is necessary to change some values in
      "LCDConf.c" file - LCD_LAYER0_FRAME_BUFFER and GUI_BUFFER_ADDRESS
      Yes, the project is configured to place the GUI memory (allocated in the function GUI_X_Config()) and the framebuffer to the external memory. So you have to make sure to place it into the internal memory, now.

      But be aware that the internal RAM of 200k might not be enough. It can be enough for the framebuffer but the GUI memory (a memory block emWin needs to create windows, memory device, etc. (not the framebuffer)) has to be placed somewhere as well. So you should double check if the internal memory is still enough.

      But I do not have "LCDConf.c" file
      NXP has uses different names for their configuration files. I guess it's named 'emwin_support.c'.

      But you can also search for the function LCD_X_Config(void). That is the place where the framebuffer address gets passed to emWin.

      Regards
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • Hi,
      danke für die Antwort.

      Yes, I have file 'emwin_support.c' and there is a function void LCD_X_Config(void) in it.

      I have here parameters VRAM_ADDR (GUI_MEMORY_ADDR + GUI_NUMBYTES) defined as (0xa0000000) + 0x20000)

      So do I understand it right, that the whole GUI memory block starts from 0xa0000000 and has size of 0x20000 (160 kB)?
      Isn't it too small memory block - 160 kB for the whole GUI? Or is it only chunk for framebuffer?

      I have found parameter #define SDRAM_BASE_ADDR 0xa0000000 in the header file 'emwin_support.h' and it is used in the function 'void GUI_X_Config(void)'
      Of course the address 0xa0000000 is far beyond the internal memory and I guess I have to change this parameter here.

      But I still cannot find where I can change the starting address for framebuffer - neither LCD_LAYER0_FRAME_BUFFER nor GUI_BUFFER_ADDRESS -
      I can't find them in the whole workspace. Maybe the necessary parameter for this purpose has another name? And where I can define the size of framebuffer?

      Thanks.
    • Hi,

      nichts zu danken.
      So do I understand it right, that the whole GUI memory block starts from 0xa0000000 and has size of 0x20000 (160 kB)?
      No, VRAM seems to start at 0xa0020000 (0xa0000000 + 0x20000).

      I guess in GUIConf.c (not sure where it is in the NXP files) the working memory (GUI_RAM) is placed at 0xa0000000 and has a size of 0x20000. The calculation of the VRAM address should make sure that the frame buffer gets placed behind the GUI_RAM.

      You have to distinguish between the framebuffer and the working memory of emWin (GUI_RAM). The framebuffer is only for drawing into and is shared with the LCD-controller (at least if using the GUIDRV_Lin driver).

      The GUI_RAM gets allocated in the function GUI_X_Config() by a call of GUI_ALLOC_AssignMemory(). This peace of memory gets used if emWin needs some memory for creating windows, memory devices, decoding JPEGs, etc.

      The framebuffer gets set in the function LCD_X_Config() by a call of LCD_SetVRAMAddrEx(). This is used by emWin to draw into and used by the LCD-Controller to read from and generate signals for the display.



      But I still cannot find where I can change the starting address for
      framebuffer - neither LCD_LAYER0_FRAME_BUFFER nor GUI_BUFFER_ADDRESS -

      I can't find them in the whole workspace. Maybe the necessary parameter
      for this purpose has another name? And where I can define the size of
      framebuffer?
      The starting address can be set by modifying VRAM_ADDR. In your case it is placed directly behind the GUI_RAM, but can be placed any where else (but make sure not to overwrite any other sections). You could also define VRAM_ADDR to any other value, like:

      VRAM_ADDR 0xa0100000

      If you know that nothing else gets placed at and after the start address of the framebuffer it is not necessary to have a size set. But you can also declare an array in the external RAM with a specified number of bytes and use the address of this array as start address of the framebuffer.

      Like this, declare the array and place it into the section ".EXT_MEM". It has a size of x * y * BPP * number of buffers:

      static U8 _aVRAM0[XSIZE_PHYS * YSIZE_PHYS * NUM_BUFFERS * NUM_VSCREENS * BYTE_PER_PIXEL_0] __attribute__ ((section (".EXT_MEM")));

      Now you can use the address of the array for the definition of VRAM_ADDR:

      #define VRAM_ADDR (U32)&_aVRAM0[0]

      Regards
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.