There are several softwares developed by ST or third party to dump the binaries of an BMP file and generate c code and header files. However, I did not find any software available for linux, so, after reading how the BMP files is organized and what type of images uses this LCD controller. I wrote a code to generate C and header files.

According the Application Note AN4861, the required images for the LCD are RGB 565 format. Regularly an image is RGB 888, that means that a colour can be represented by 24 bits, 8 bits per channel. However, this LCD doesn support such amount of colours according to the unofficial datasheet. That's why the image have to be transform to a smaller colours space. and saved as a raw image, that means no compression. There might be several formats outside that accomplish this requirement, however the STD library for the discovery board uses dumped BMP files with some modifications in the header, we will see it.

So, I have an image produced by ST software. Let's dump it and matching that information with BMP file format requirements. For this purposes, I will use xxd:

xxd image_rgb565.bmp | head -n 6

As a result we got:

00: 424D 36E2 0400 0000 0000 3600 0000 2800
10: 0000 9001 0000 9001 0000 0100 1000 0300 
20: 0000 00E2 0400 0000 0000 0000 0000 0000 
30: 0000 0000 0000 853a 264b c853 053b 674b
40: 2743 252a 883a cd6b c952 253a e631 c429
50: c321 c321 e631 ...

Obviously this is a reduced version of the results, but, Im avoiding the non essentials. At the first glance this might look intimidating, but let's dig a compare with the BMP file format.

According to the BMP file format the first 14 bytes are the header file, that means how large the file itself is and what type of is. let's see:

# Header File
00: 424D 36E2 0400 0000 0000 3600 0000 
# Header End
# DIB Header
0F: 2800
10: 0000 9001 0000 9001 0000 0100 1000 0300 
20: 0000 00E2 0400 0000 0000 0000 0000 0000 
30: 0000 0000 0000 853a 264b c853 053b 674b
40: 2743 252a 883a cd6b c952 253a e631 c429
50: c321 c321 e631 ...

Splitting it according to the documentation, we have

# Header File
00: 424D      # File identification
02: 36E2 0400 # File size
06: 0000 0000 # Application that created the file
0A: 3600 0000 # Offset 
# Header End

This identifies the file as a BMP on the system

The file size in bytes, including header:

File Size = HEADER_FILE + DIB_HEADER + OTHER_HEADERS + RAW_IMAGE + TAIL

In this case, the formula is simpler:

File Size = HEADER_FILE + DIB_HEADER + RAW_IMAGE

Two of them are fixed parameters:

HEADER_FILE = 14, DIB_HEADER = 40

then

File Size = 54 + RAW_IMAGE

There's no much to say. Most of the time is zero.

Where the data image itself starts, before this, everything is just headers. Many headers that arent usefull for the LCD can be ingnored, so, this fixes the Offset always be 0x36.

The Next chunk is the DIB Header, splitting, this is what shows:

0E: 2800 0000 # Size of this header in bytes (DIB Header)
12: 9001 0000 # Image width 
16: 9001 0000 # Image Height 
1A: 0100      # Color planes, this has to be always 1
1C: 1000      # bits per pixel, in our case 16
              # RGB565, 5 + 6 + 5 = 16bits = 2bytes 
1E: 0300 0000 # Compression Method. This method is supposed to
              # include a color map, but for the LCD and STM32 apparently is ignored
22: 00E2 0400 # Raw Image Size = Width * Heigh * bytes_per_pixel
26: 0000 0000 # Real horizontal resolution (useful for print on a paper)
2A: 0000 0000 # Real vertical Resolution (useful for print on a paper)
2E: 0000 0000 # Number of colours in the palette (apparently ignored)
32: 0000 0000 # Number of important colours (apparently ignored)
# End DIB Header
# Raw Image starts
36: 853a 264b c853 053b 674b 2743 252a 883a
4C: cd6b c952 253a e631 c429 c321 c321 e631 
62: ...

By knowing this, any c code or header file can be constructed based on an image. An important observation, some BMP images have padding zeros, so the Raw Image Size:

Raw Image Size = (width + 1) * height * 2 However the padding zeros have to be avoided, I didnt see any padding zero on the generated files by the ST software.