RGB888 format，The black color is not displayed correctly. It shown as dark blue on LCD

Question

Dear sir,

When I transfer our UI page( designed by EW 9.20) to our prototypy hardware board which based on NXP RT1062, I found the black color can't be displayed correctly, it was shown as dark blue on LCD (actually, it is black color in our design).

Some parameters as below:

• PlatformPackage is "NXP.iMX_RT.RGB888"
• DirectAccess for both "FormatOfBitmapResources" and "FormatOfBitmapResources" in Profile Configuration.

After generate code and run it in our prototype board, the black background was shown as dark blue. I can't find the root cause.

In additional, we have further tesing with other colors, red(#FF0000FF), green(#00FF00FF,blue(#0000FFFF) and yellow(#FFFF00FF) can be displayed correctly, only black was displayed as drak blue.

Please see the attached pic. The LCD frame is black for comparison. The picture's background is dark blue, but it is actualy black in UI page design.

The RGB888 color code is marked on each color block. Except for black, all other color blocks can be displayed correctly.

So, please help to analyze what the reason is and how to solve this case.

Thanks a lot. 

Answer 1

Hello Jerry,

first of all, great to see that you have running a first GUI application on your own hardware!

Let me recommend to create the following color gradients in order to see that the display is connected correctly:

You will find this within the example ColorFormats (subdirectory /Examples within the iMXRT106x Build Environment).

All color gradients should have a linear appearance without any steps. Is this the case on your target?

Best regards,

Manfred.

Comments

Dear Manfred,

thanks for your reply.

As your mentioned, the color gradient is not linear appearance, there are some steps for each color bar.

All color defination for each color gradient is baseed on the RGB888 profile of example ColorFormats.

The testing result as the pic below.

Do you know what the reason?

Thanks.

 

 

---

Hi Jerry,

this seems to be more a hardware problem - please check all RGB lines between the MCU and the display.

Btw: Is your display connected as RGB565 (16bit), RGB666 (18bit) or RGB888 (24bit)? Please ensure that the LCDIF settings are suitable to your display connection.

Best regards,

Manfred.

---

Hi Manfred，

LCDIF setting is right in my code. We have created a RGB888 display demo on our board, after that, switch to Embedded Wizard.

Maybe as your said, I met a hardware problem. I'll check this next monday.

Further questions:

1.  in some case, we only have about 600K Bytes for memory poor, is it enough?

          #define MEMORY_POOL_ADDR      (void*)((unsigned char*)0x20220000)
          #define MEMORY_POOL_SIZE      (0xA0000)

2. How can I define the size of "EW_MAX_SURFACE_CACHE_SIZE" ? 

    Is the cache located in memory pool ?

    It will be the best if you can have a memory usage mapping for me? 

    What is the size?  What does each buffer used for?

    Such as Frame buffer, Double frame buffer, memory pool, or others?

3. I noticed that in the example for NXP RT1062, the LCD pix size is 480x272

• In IAR project, EW_MAX_GLYPH_SURFACE_WIDTH= 256  and   EW_MAX_GLYPH_SURFACE_HEIGHT= 256, Why aren't they 480 and 272?
• If I use a 480x480 LCD,  change them to 480 and 480, or just keep them as 256 and 256 

So many questions.   :)  

Thank you in advance.

Thanks.

---

Hi Jerry,

so let us wait for the results on monday about the hardware...

Concerning the other questions: Please do not make a mixture of the topics. These settings are not related to the connected display. If you have other questions, please open another thread.

Anyhow:

1.) This depends on your GUI application - without knowing the design it is difficult to give you helpful advices.

2.) EW_MAX_SURFACE_CACHE_SIZE is just a threshold value, it is not a preallocated memory - the define EW_MAX_SURFACE_CACHE_SIZE is used to control the number of bytes that can be occupied by bitmap resources that are no more used by the UI application. As long as there is enough memory available, the bitmap resources are still available within the memory in order to avoid further loading and decompression in case they are used again. Just a kind of runtime optimization.

3.) The size of the glyph cache has nothing to do with the size of the display. The glyph cache is a preallocated piece of memory that is used to store all uncompressed glyphs within the memory - this means, all glyphs that are requested during runtime in order to draw a text are decompressed and stored within the glyph cache. As long as there is enough space within the glyph cache, all frequently used glyphs are kept within the cache to avoid decompression again and again.

The glyph cache is allocated by the memory manager - in case of iMXRT10xx it will be allocated somewhere in the provided memory pool. The size of the glyph cache can be configured by setting the defines EW_MAX_GLYPH_SURFACE_WIDTH and EW_MAX_GLYPH_SURFACE_HEIGHT.

Let me recommend to set it between 128x128 ... 256x256

Best regards,

Manfred.

 

---

Hi Manfred,

Thanks for the answers for my questions.

I re-test the color blocks and color gradient on new hardware board and new LCD. refer to the pic below.

You can see, the black block is right, but these color gradients still have some steps.

So do you know what the reason is?  some wrong with LCD drivers?

Thanks.

 

Jerry

Thanks.

---

Hi Jerry,

I still think this is more a hardware problem - please check all RGB lines between the MCU and the display.

Btw: Is your display connected as RGB565 (16bit), RGB666 (18bit) or RGB888 (24bit)? Please ensure that the LCDIF settings are suitable to your display connection.

Best regards,

Manfred.