Hello friends, I am trying to better understand how data located at frame buffer address translates to what I am seeing on the LCD.

[RMora.4]

For example I have the following frame buffer data with mostly 0's and only the first value populated with a blue color.

static const uint32_t image_data[480] = {
    0x000000ff,  0x00000000,  0x00000000,  0x00000000,  0x00000000,  0x00000000,  0x00000000,  0x00000000,  0x00000000,  0x00000000,  0x00000000,  0x00000000, 
.
.
    0x000000, 0x000000, 0x000000, 0x000000, 0x000000, 0x000000,
.
.
    0x00000000,  0x00000000,  0x00000000,  0x00000000,  0x00000000, 
}

With LTDC PixelFormat set to LTDC_PIXEL_FORMAT_RGB888 - I get the following output on the LCD. A single blue line on the left-most side of the LCD.

I think I can reason about the output but this still raises a question. I was expecting the first value from the frame buffer data to represent a single point on the screen not an entire line. How would I represent a single point if not like this?

I can reason about the color of the line since the value is 0x000000ff and the 2 least significant bits represent blue. The following 2 bits represent green, The next 2 bits represent red. I am assuming the 2 most significant bits are of no significance. I am just setting them to zero to explicitly represent the 32 bit number for each value expected by the array. And of course the rest of the zero values in the frame buffer translate to the rest of the screen being black.

So if each value represents a line on the LCD I modify my frame buffer data to set all values to blue. My expectation is a blue screen.

static const uint32_t image_data_IMG_4138[480] = {
    0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,
.
.
    0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff, 
.
.
    0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,  0x000000ff,
}

But the result is actually a consistent pattern of black and white lines. I am guessing there is something I am not understanding about how this frame buffer data is being translated to the LCD. Any hints? I have gone through the LTDC app note AN4861 and the slides for LTDC overview. Any additional material I can read the fix my understanding?

[KnarfB · Accepted solution]

The frame buffer can be considered as a 2-dim array of pixels like pixel_t fb[W][H]; It is often accessed as a 1-dim array using fb[y*W+x] instead of fb[y][x]. The result is in both cases at the same offset.

H is the height of the frame buffer, W its width. Both may be greater than the part visible on the screen.

Each pixel has a fixed number of bits for representing red, green, and blue color values. Typical sizes are 32-bit (RGBA, ARGB), 24-bit (RGB, BGR) and 16-bit (5+6+5 or 5+5+5). The order of color channels varies.

My guesses:

• you are not using the correct pixel format and therefore see the stripes. RGB888 has 24-bits not 32. Try a (packed) struct of 3 uint8_t members.
• static const uint32_t image_data[480] seems to be a single line, not the entire frame buffer. Maybe that line is copied (repeated) to fill the entire screen later by some code.

More infos about the chip, display, .. might help

hth

KnarfB

•  

[RMora.4]

Okay thanks for the pointer on the 2d array - this definitely makes sense. I will rewrite my frame buffer using a 2d array and uint8_t datatypes. I see where where I might be going wrong here - i am passing 32 bit color values and the LTDC is expecting RGB888.

[RMora.4]

Okay thanks for the pointer on the 2d array - this definitely makes sense. I will rewrite my frame buffer using a 2d array and uint8_t datatypes. I see where where I might be going wrong here - i am passing 32 bit color values and the LTDC is expecting RGB888.

[RMora.4]

Thank you that solved my issue. I'm now seeing expected results.

[dhs.1]

I actually have tested it. If I remark out the definition, this system may be created correctly and it works. The downside is that after each code generation with CubeMX the exchange has to be finished again to find on huntingmanual.com.