Bitmap on STM32F746G-DISCO discovery board

[Vietvinh Nguyen]

Posted on April 19, 2017 at 09:29

Hi all

Recently, I created a Win32 application to convert a bitmap (.bmp) file into a header file (.h) in order to display it in mySTM32F746G-DISCO discovery board. Everything works fine but the bitmap (24 bit depth) displays differently (see attached photo) compared to the original bitmap.

Does everyone experience the same? The displayed bitmap seems to be skewed and de-colored. I have done again with a 16-bit-depth bitmap but no further advance.

(I reused the BSP example in STM32CubeF7Packets for the test)

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[AvaTar]

Posted on April 19, 2017 at 12:04

There are other guy around in this forum, experienced with the F746 disco board and Cube code.

I expected them to comment as well, but either they are away, or are hindered by the time shift ...

[Vietvinh Nguyen]

Posted on April 20, 2017 at 03:28

Hi again

I have modified my conversion app to change the byte order of the generated header file. However the result is worse as shown bellow:

I think I should check the LCD driver thoroughly.

[john doe]

Posted on April 20, 2017 at 03:39

i get that when the image isnt in memory where i think it is.

i have a 769 disco board with external sdram and i can go from uSD card -> sdram -> screen without any gimp foofah, just raw binary.  it helps very much if the bitmap is in the format expected by the system call.

[Vietvinh Nguyen]

Posted on April 20, 2017 at 04:02

Really? I did it the same way the example did for ST logo. However, as you see on my photos, the ST logo can display it well.

[Tesla DeLorean]

Posted on April 20, 2017 at 04:52

>>

I think the function can recognize the current colour mode of the LCD because as you see below

I think you are far too optimistic about the coding of the libraries and the assort .BMP formats. You should perhaps analyze the data rather than assume the code others have written handles all situations correctly. Dump the headers, and confirm the content.

The .BMP to .H conversion should be a byte-for-byte equivalent unless it does more processing to change the colour depth.

https://community.st.com/0D50X00009XkZvsSAF

 

https://community.st.com/0D50X00009XkfXMSAZ

 

[Vietvinh Nguyen]

Posted on April 20, 2017 at 08:16

Yes, at first I usually rely to the written code. After experiencing something abnormal, I will try to resolve it.

Yes, the .bmp to .h converter is byte to byte equivelent. I don't want to modify the bit map file because I want it to be universal over the STM32 platform, Windows platform...

[AvaTar]

Posted on April 20, 2017 at 08:29

To add two further comments:

ST's cube examples are not quite known for very careful design, nor exhaustive documentation, versatility or bug free-ness. Most often, they use to prove just one single point / property. ST's SW team just does not have the time for polished commercial-ready stuff. Not that other suppliers are much different.

When dealing with my LCD driver application, I included code to display a test image with (supposedly) known colour bars.

Red, green and blue are obviously the first candidates. If this is not displayed properly, there is no reason to proceed with image files.

[Io D]

Posted on April 20, 2017 at 11:27

Could you please provide the Layer Settings of the LCD from CubeMX project?

Probably, you have to re-configure the Pixel Format of the Foreground(Layer 0). I suggest to use RGB888 or ARGB888 format.

In any case you may have to confirm that the pixels of the bitmap are 'aligned' in the peripheral's memory.

For example, if you use 

RGB888 format (3 bytes per pixel) and the address of the Layer Buffer begins at 0xC0000000, your first pixel should occupy the memory addresses 0xC0000000,0xC0000001,0xC0000002, [R-G-B] the second 0xC0000003, 0xC0000004, 0xC0000005... etc. 

[Vietvinh Nguyen]

Posted on April 20, 2017 at 11:48

Here is the layer setting:

void BSP_LCD_LayerDefaultInit(uint16_t LayerIndex, uint32_t FB_Address)

{ LCD_LayerCfgTypeDef layer_cfg;

/* Layer Init */

layer_cfg.WindowX0 = 0; layer_cfg.WindowX1 = BSP_LCD_GetXSize(); layer_cfg.WindowY0 = 0; layer_cfg.WindowY1 = BSP_LCD_GetYSize(); layer_cfg.PixelFormat = LTDC_PIXEL_FORMAT_ARGB8888; layer_cfg.FBStartAdress = FB_Address; layer_cfg.Alpha = 255; layer_cfg.Alpha0 = 0; layer_cfg.Backcolor.Blue = 0; layer_cfg.Backcolor.Green = 0; layer_cfg.Backcolor.Red = 0; layer_cfg.BlendingFactor1 = LTDC_BLENDING_FACTOR1_PAxCA; layer_cfg.BlendingFactor2 = LTDC_BLENDING_FACTOR2_PAxCA; layer_cfg.ImageWidth = BSP_LCD_GetXSize(); layer_cfg.ImageHeight = BSP_LCD_GetYSize(); HAL_LTDC_ConfigLayer(&hLtdcHandler, &layer_cfg, LayerIndex);

DrawProp[LayerIndex].BackColor = LCD_COLOR_WHITE;

DrawProp[LayerIndex].pFont = &Font24; DrawProp[LayerIndex].TextColor = LCD_COLOR_BLACK; }

You can find the whole example project in the Cube downloaded from st website.

By the way, the bitmap used is 90x76 in size. It means that the bmp file must be of 90*76*4+54=27414 bytes. However its real size is 20726 bytes. The bitmap was edited in Paint.exe in Win7. I don't know why it loss a thousand of bytes. Could anyone explain it more detail?

[Io D]

Posted on April 20, 2017 at 11:58

Please try to change  

LTDC_PIXEL_FORMAT_ARGB8888 to 

LTDC_PIXEL_FORMAT_RGB888