STM32F749G-Discovery color reproduction

[Fleck]

Hi, as Tectu is busy those days, I decided to post my question here. No matter what pixel format I use (RGB565 or  RGB888) I get low quality image on screen, I use 24bit bmp, here's image of F7 on the left and F4 with SSD1289 on the right, you can see the quality difference: http://imgur.com/rR5K1i2 and bigger image of F7: http://imgur.com/VPzZ5GD, as you can see, colors are not smooth, like 256 color mode on old PCs  Ideas?

[inmarket]

I suspect this is a property of the lcd panel itself. I haven't had time to investigate in great detail.

Evidence that suggests it is the panel is that the f4 board using the same ltdc driver code but with a different panel displays much better. This is not proof though - more investigation is required.

It is interesting to note the stm examples for the board (carefully) avoid images that would show the problem.

[Joel Bodenmann]

@inmarket he's not using the LTDC driver for his F4 as he's using an SSD1289 display module/controller.

However, what was said still applies: This is most likely a display panel property. The display panels you get with the discovery boards are generally of a very poor quality. The ones form the large eval boards are a lot better.
As mentioned, ST takes a lot of care to use images and colors in their examples that hide these "problems".

Also note that the SSD1289 display module that you're using has most likely a higher pixel density than the display on the STM32F7 Discovery. Higher display density will increase the "smoothness" of what is being displayed.

[Fleck]

Don't know, ST demo images in alarm app looks OK, there are gradients, shadows, also ST logo on startup looks OK to me. Can't believe ST used so bad display in 2015. Can't believe SSD1289 performs better. Just can't!

[Joel Bodenmann]

Can you confirm that the issue is the same on an STM32F429i-Discovery board?

We will have a look at the STM32LTDC driver. There has already been an issue in the past where the LTDC wasn't configured with the proper values which resulted in shimmering effects: https://community.ugfx.org/topic/152-improvement-stm32f429i-discovery-display-shimmering/
Sadly this will have to wait for a couple of weeks. If you want to investigate: Compare the configuration values of the µGFX LTDC driver & board file(s) to the one used in the ST demos.

[Fleck]

Nope, F429i uses chibios, no CubeHAL example there!

[Joel Bodenmann]

What do you mean? ST provides at least a dozen different examples ready-to-run for the STM32F429i-Discovery board. You can run µGFX on it the same way you are doing with the STM32F746G-Discovery board

The reason to do this is to check whether it's an issue in the µGFX STM32LTDC driver itself because both platforms would use the same driver.

[Fleck]

You know me, it will take me whole day to get something running on F429i... answer is still the same!

[Joel Bodenmann]

I guess this has to wait a couple of weeks then, sorry!
In the meantime we at least updated the STM32F7-Discovery board files to be compatible with the latest STM32CubeF7 HAL (or what ever the right terminology is...).

We will definitely take a look at it. It's on the short-term ToDo list.

[Fleck]

OK, I have tried STM32CubeF7 demo/example code, there is a picture frame demo code, I uploaded my BMP to sdcard and checked it out, it's definitely not a property of a display, looks great! Next, I will try to find where the problem lies! Here's the image running STM32CubeF7 demo/example code: http://imgur.com/1e3PwtV as you can see, nice and smooth! Will let you know if I find something more on this problem!

Edited June 25, 2016 by Fleck

[Joel Bodenmann]

Good work checking with the ST demo!

I guess it's safe to say that the problem lies somewhere in the STM32LTDC driver or the STM32F746-Discovery board file.
Let us know when you find something!  

[Fleck]

OK, found it, problem is in the board file: boards/base/STM32F746-Discovery/board_STM32LTDC.h
1) Line 139 for PK0 MODER used is GPIO_MODER_MODER0_0 but should be GPIO_MODER_MODER0_1
2) Line 184 for PG12 AFRH is set to 14 (LCD_B1), but needs to be 9 (LCD_B4), LCD_B1 we have on PJ13!

Now there is only one thing left, HardFault when enabling RGB888 mode in drivers config file, I overcome this by setting LTDC_PIXELFORMAT to LTDC_FMT_ARGB8888, LTDC_PIXELBYTES to 4 and LTDC_PIXELBITS to 32, also, in DMA2D init if RGB888 is selected, I set DMA2D to ARGB8888. Yes I know, this is not the right way, but, at least, it doesn't HardFault, HardFault error was unaligned memory access, 24 bits on 32bit cpu?!? Dunno why, I am not so smart in all this, and last line in gdisp_lld_STM32LTDC.c executed before HardFault is 277: PIXEL_ADDR(g, pos)[0] = gdispColor2Native(g->p.color);

Anyways, now I can continue do what I wanted to do on F7-Disco  heh and you have all the info needed to fix all those problems, case closed!

[Joel Bodenmann]

Very well done! Great work at finding the problem!

We just pushed the fixes to the repository. We will have a look at the RGB888 issue with the STM32LTDC driver later. Right now we pushed the workaround as per your suggestion which allows people using RGB888 instead of having a blank screen due to a hardfault.

[Fleck]

Yep, tried, works, thanks!