I'm using an imx rt 1052 nxp processor on a custom board and I see that when I use large images on my application, display is shifted when large images are displayed (100 x 100).
This feature is active only when images are read directly from flash memory.
I'm also able to reproduce this issue on nxp MIMXRT1050-EVK eval board with ColorFormats example provide by EW when setting formatOfBitmapResources project option to directAccess. This example run well when option is set to compressed. BrickGame example also show problem with directAccess for images.
My custom board has only 512Kb internal RAM memory, and only 288Kb are available for Embedded wizard application (150Kb for frame buffer and 138Kb for memory pool for 320 x 240 screen), so I'm not able to display large image with so little memory, but it is possible when images are stored in flash memory (except with this issue).
Display screen shot:
I have observed the same issue and we did further analysis together with the NXP support team. The reason for the shift effect is a LCD underflow. This means, the LCD controller does not get enough data from the internal bus.
I assume you are using version 9.20 of Embedded Wizard and the RT1050 Build Environment - there you will find a prepared solution to avoid the LCD underflows.
Please have a look into the file /TargetSpecific/ew_bsp_display.c - there you will find the following code snippet within the function EwBspConfigDisplay():
/* In case you get LCD underflows (e.g. flickering of LCD while PXP is active),
you can increase the read priority for the LCD by modifying the NIC read_qos
value for it. It is at 0x41044100 (register that isn’t in the header file)
The default value is 1 which is a pretty low priority.
If you change this register to a value grater than 1 (up to 5), then that
will make the LCD higher priority. It should solve the underflow issue.
If it creates a problem for another master, then you might need to experiment
with the value to find something that keeps the LCD from underflowing, but
allows enough bandwidth for other masters.
uint32_t* LCD_read_qos = (uint32_t*)0x41044100;
*LCD_read_qos = 0x02;
Just uncomment that in order to increase the priority of the LCD controller.
Does this solve the shift problem in your environment also?
well, since version 9.10, the PXP hardware is used in order to accelerate the graphics composition.
This means, that at least three bus masters (CPU, PXP, LCDIF) have to share the available memory bandwidth.
If you want to disable the usage of the PXP hardware, you can call NxpRtUsePXP( 0 ) after the initialization of the Graphics Engine. Then you should have the same behaviour as it was the case with version 9.0 - of course, with lower performance.
Which color format are you using? If you are using RGBA8888 or RGB888 color format, you can try to use RGB565 instead in order to reduce the memory bandwidth used by LCDIF.
Are you using double buffering or single buffering of the framebuffer?
Ask Embedded Wizard
Welcome to the question and answer site for Embedded Wizard users and UI developers.
Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!