White screen on ILI9488

[inmarket]

There seems to be a confusion here between the display DPI interface and the framebuffer format. They usually do not need to be the same. For most controllers, they will do the conversion on the fly between the frame buffer RAM interface and the DPI lcd interface. E.g. if you are using an 8 bit palette framebuffer format the display controller will do the palette lookup to create the 18/24 bit wide DPI data. Similarly, the framebuffer can be in RGB565 format which is efficient for the CPU, RAM and memory usage, and convert it on the fly to the 18bit DPI interface (by bit shifting the red and blue values).

Layering also occurs at this level. Layers involves taking 2 framebuffers in potentially different pixel formats and "mixing" them to produce a single 18/24 bit hardware DPI value for the LCD.

That is the other thing about layers, you need a full size framebuffer for each layer. They can usually be in different pixel formats. In fact, they may have to be in different pixel formats in order to not exceed the total RAM bandwidth limitations.

E.g. an STM4 chip using LTDC with external RAM can only support 1 x 320x240 framebuffer at RGB565 unless frame rates are quote low. If you want the 2nd layer it needs to run at RGB232 or an 8 bit palette mode to meet RAM and LTDC bandwidth requirements. As implied there are things that can be done to help here, 2 x RGB565 are available at low frame rates. It may help to split the RAM interface, it may be possible to use higher speed static RAM, a different CPU may also help etc. I will leave the bandwidth calculations to be part of your hardware design.

 

[Joel Bodenmann]

On 10/11/2023 at 16:16, PaulyLV said:

Is there a way to specify the pixel format in the 'file2c' utility?

The file2c utility simply creates a C array of the byte-content of the file you feed into it. It doesn't perform any conversion. In fact, it doesn't even know whether you feed it a picture, an audio file or an SQL database dump. It just wraps binary data into a C array and adds some entries to use it with ROMFS.
If you need to do conversions you'll have to make them before feeding the file through file2c.

@inmarket An STM32F4 with LTDC and external SDRAM via FMC can actually handle a 320x240 display with two layers and RGB565. I think it can also handle 320x480. I was working on a project not so long ago with a 480x480 display, dual layer LTDC and RGB565.
But yes, this is definitely true: Bandwidth considerations need to be part of the hardware design phase. If your application needs a lot of I/O bandwidth then LTDC can be a real show stopper - especially when paired with SDRAM

 

[PaulyLV]

4 hours ago, inmarket said:

There seems to be a confusion here between the display DPI interface and the framebuffer format. They usually do not need to be the same. For most controllers, they will do the conversion on the fly between the frame buffer RAM interface and the DPI lcd interface. E.g. if you are using an 8 bit palette framebuffer format the display controller will do the palette lookup to create the 18/24 bit wide DPI data. Similarly, the framebuffer can be in RGB565 format which is efficient for the CPU, RAM and memory usage, and convert it on the fly to the 18bit DPI interface (by bit shifting the red and blue values).

Layering also occurs at this level. Layers involves taking 2 framebuffers in potentially different pixel formats and "mixing" them to produce a single 18/24 bit hardware DPI value for the LCD.

That is the other thing about layers, you need a full size framebuffer for each layer. They can usually be in different pixel formats. In fact, they may have to be in different pixel formats in order to not exceed the total RAM bandwidth limitations.

E.g. an STM4 chip using LTDC with external RAM can only support 1 x 320x240 framebuffer at RGB565 unless frame rates are quote low. If you want the 2nd layer it needs to run at RGB232 or an 8 bit palette mode to meet RAM and LTDC bandwidth requirements. As implied there are things that can be done to help here, 2 x RGB565 are available at low frame rates. It may help to split the RAM interface, it may be possible to use higher speed static RAM, a different CPU may also help etc. I will leave the bandwidth calculations to be part of your hardware design.

 

Yes, I am definitely not understanding something. I would like to use 18-bit DPI interface with LTDC. According to the LTDC application note, it is possible. But, in the gdisp_lld_config.h file included in the STM32LTDC folder in uGFX, the pixel formats mentioned are only RGB565 and RGB888. Second, in "stm32f4xx_ltdc.h", RGB666 is not listed as a pixel format. Third, in "gdisp_lld_STM32LTDC.c", only two pixel formats are available. Are you saying that the pixel format specified in these files is not related to the DPI interface but is the framebuffer format?  How does the LTDC peripheral "know" that I want the RGB666/18-bit DPI format then? What am I missing?

  

[PaulyLV]

2 hours ago, Joel Bodenmann said:

The file2c utility simply creates a C array of the byte-content of the file you feed into it. It doesn't perform any conversion. In fact, it doesn't even know whether you feed it a picture, an audio file or an SQL database dump. It just wraps binary data into a C array and adds some entries to use it with ROMFS.
If you need to do conversions you'll have to make them before feeding the file through file2c.

@inmarket An STM32F4 with LTDC and external SDRAM via FMC can actually handle a 320x240 display with two layers and RGB565. I think it can also handle 320x480. I was working on a project not so long ago with a 480x480 display, dual layer LTDC and RGB565.
But yes, this is definitely true: Bandwidth considerations need to be part of the hardware design phase. If your application needs a lot of I/O bandwidth then LTDC can be a real show stopper - especially when paired with SDRAM

 

Here are snippets of the C files generated using file2c utility and LCD image converter (specified RGB565 format). I don't understand how both these arrays would generate the same result when used as the framebuffer address in LTDC. Sorry that the snippets I included are actually two different images so they will not generate the same result, but I hope you understand what I am trying to ask. Does the 8-bit vs 16-bit data format not matter?

 

 

 

 

[Joel Bodenmann]

18 minutes ago, PaulyLV said:

Here are snippets of the C files generated using file2c utility and LCD image converter (specified RGB565 format). I don't understand how both these arrays would generate the same result when used as the framebuffer address in LTDC.

One of them is a binary representation of an actual file (Target_whiteBG_20x20.bmp in your case) whereas the other one is most likely raw decoded pixel data.
The file2c utility just creates a C array of the binary representation of any file you pipe into it. You'd use its output to include into ROMFS and then draw the actual image via the high-level GDISP API with all the bells and whistles (color conversion, rotation, palette stuff, RLE and so on).
Your "LCD image converter" on the other hand provides a raw pixel values tied to a specific format and resolution.
Two entirely different things.

 

50 minutes ago, PaulyLV said:

Are you saying that the pixel format specified in these files is not related to the DPI interface but is the framebuffer format?  How does the LTDC peripheral "know" that I want the RGB666/18-bit DPI format then? What am I missing?

You don't see an RGB666 option for the LTDC pixel format because that is not supported by the LTDC peripheral found in the STM32F429.

[inmarket]

In this case it is the LTDC peripheral that is doing the pixel conversion and layer mixing I talked about in my earlier post. While the LTDC does not support RGB666 DPI it does support RGB888. You can connect that to a RGB666 panel by simply not connecting the two lowest bits of each colour byte.

So, You can use RGB565 as the CPU and framebuffer pixel format for a layer, and then you program the LTDC to take that RGB565 pixel data and convert it to the RGB888 output DPI bus. That RGB888 DPI bus you then connect to RGB666 panel by ignoring the bottom 2 bits of each colour on the DPI bus.

So, uGFX works and is programmed around the chosen framebuffer pixel format - not the DPI bus format. The LTDC converts that framebuffer pixel format on the fly to your RGB888 DPI bus.

Note: when you have 2 layers they can be in different framebuffer formats. uGFX then may have a "system" pixel format and two different display/layer pixel formats.  uGFX drivers convert from the system format (which all drawing operations occur in) to each display/layers internal format in the driver. That conversion is obviously trivial when the system and all drivers agree.