Gui Guider Frame Buffer Location SDRAM or SRAM issue

[akift]

Hi,

I use RT1064EVK and I design UI with GUI Guider v1.6.1 and LVGL v8.3.5.

From Settings, if I select Frame Buffer Location as SDRAM or SRAM and click Generate C code, there is no difference between the generated C codes.

I assume some changes should appear and indicates that build with SDRAM or SRAM.

Could you explain what is the purpose of this selection?
If there is any other to do it, how I can set Frame Buffer location as SDRAM or SRAM in my project?

Thanks

[akift]

Thank you for your comments. I think this can explain the issue clearly.

I have attached the project. The issue I am having is ethernet task stuck when UI task exist in the code.

The attached project is connecting to TCP server and sending some data and basic LVGL guider UI example is working. After couple of seconds the MCU doesn't send data and UI stuck.

I thought it can be solved with moving entire UI task to SRAM, but maybe there is a simple fix.

Any help would be appreciated. Thanks

[EdwinHz]

Hi @akift,

There is no difference from the GUI Guider Code Viewer because this viewer only shows the files relevant to what it modifies inside folders like "Custom" and "Generated". However the actual project is bigger than this, and it contains a lot more information and code outside of the GUI Guider relevant files. If you open the project location using the green folder icon, you will see the whole scope of the project which includes the rest of the necessary files for the project to run on a i.MX RT. More specifically, on the "<project>\sdk\Core\board" path, you will find files with the name "lvgl_support.c" and "lvgl_support.h". The header file contains a macro definition:

#define FB_USE_SRAM 0

This macro states whether the FrameBuffer will use SRAM or not, so changing the Frame Buffer Location from SDRAM to SRAM will change the value of this macro from 0 to 1.

This will affect some lines of code on the lvgl_support.c file, like the following:

#if FB_USE_SRAM
#define DRAW_BUF_HEIGHT (LCD_HEIGHT / 5)
#define DEMO_DB_SIZE LCD_WIDTH * DRAW_BUF_HEIGHT * LCD_FB_BYTE_PER_PIXEL
SDK_ALIGN(__attribute__((section("FrameBuffer"))) static uint8_t s_frameBuffer[1][DEMO_FB_SIZE], DEMO_FB_ALIGN);
SDK_ALIGN(__attribute__((section("DrawBuffer"))) static uint8_t s_lvglBuffer[DEMO_DB_SIZE], DEMO_FB_ALIGN);
#else
SDK_ALIGN(static uint8_t s_frameBuffer[2][DEMO_FB_SIZE], DEMO_FB_ALIGN);
#endif

Using internal SRAM can result in better performance, as stated on the GUI Guider User Guide: https://docs.nxp.com/bundle/GUIGUIDERUG-1.6.1/page/topics/performance.html

BR,
Edwin. 

[mjbcswitzerland]

Hi

Note that when locating the frame buffer in internal memory the size and/or resolution of the display may be restricted, but is it very efficient and also avoids EMC issues on external lines (of SDRAM), although it is important to configure all LCD signals with low drive strength otherwise they can generate high levels of radiation (selecting the video clock source from a PLL with spread spectrum capability also helps a lot to ensure EMC levels are achieved).

As reference I developed this product using the i.MX RT 1062 (could also be 1064 since I use the same QSPI flash externally) without any external RAM memory by locating the frame buffer in OCRAM2. This is with a 480 x 272 TFT in 16 bit color mode.

https://ecofort.ch/de/waschetrockner/3222-bora-408.html?gad_source=1&gclid=Cj0KCQiAm4WsBhCiARIsAEJIE...

Video showing its touch display in use:
https://www.utasker.com//WT05/BORA-408.MP4

Since all code, data and the LCD buffers operate completely in internal memory it gives a very clean design (all accesses with zero wait state since no XiP) - see photo below. The QSPI is only accessed when loading images and fonts [when screen pages are changed] (or for web pages as the product support wifi operation too) which are too large to store in program code.

Regards

Mark


For our discounted i.MX and Kinetis stock availability see https://www.utasker.com/Shop/semi.html