Driving 24 Bit RGB Display With STM32F750. RGB565 or RGB666?

[MHenz]

Hello,

I am new to TouchGFX and I am very impressed with not only your technology, but with how responsive this forum is. I have watched a number of tutorials on TouchGFX. I have an STM32F7508-DK development board and I have been able to successfully generate interesting user interfaces.

My question relates to porting TouchGFX to a 144 pin version of the STM32F750. I am designing a custom board with this chip. I have a very cost sensitive application and cannot use the BGA package. As a result . . . by the time I assign the FMC controller and the Quad SPI, I am only able to use the LTDC in either RGB565 mode or RGB666 mode. 16 bit color depth is fine with me, but I am forced to use a display with RGB888 interface format.

So . . . my questions are:

1. Do I simply tie the lower order bits (R0, R1, B0, B1, G0, G1) on the display to GND?
2. Should I use RGB565 or RGB666 mode?
3. The ability to have transparent background bitmaps is very important in my application.
4. Will there be any color banding in the transparent images if I tie the lower order bits to GND?

Thank you for your help.

All the best,

Max

[T J]

Colour banding, you will see the bands as colour slightly changes usually only obvious in photo images.

if you are displaying graphic blocks, where individual shapes contain one colour,

RGB565 and RGB666 will display just the same, there will be no banding.

use RGB565, its faster to process(dma), but not as many colours, obviously lacking in a photo image.

if RGB666 is not good enough the difference in cost for a 176/208 pin is not huge in volume

tying R0 R1 etc to gnd on the LCD connector will dim every pixel a little, tie them high for a slightly brighter image where black is a little grey.

about the transparent bitmap background question, it will work regardless of the LCD connections.

[Martin KJELDSEN]

1 +2 ) See @Community member​s answer.

3) The 16-bit version of the LCD class in TouchGFX will let you use ARGB8888 images and blend using ChromART into a 16-bit framebuffer.

4) That depends on your graphics. For instance, a gradient would give you banding.

/Martin

[eng23]

Hi,

I was checking the STM32F750N8H6 and comparing with STM32F756BG that I'm going to use and I realised that the first one is cheaper than mine, almost a half, while the features is equal, the mainly difference is less flash size 64kb.

Do you know the reason for this? Is there something that I couldn't see?

Regards.

[MHenz]

Thank you very much for your reply. For cost reasons, I cannot use the BGA package. This is not because of the cost of the chip, but the cost of the assembly is higher. My application is extremely cost sensitive and every penny counts. I will be using pictures as semi transparent backgrounds in my application. I guess I'll just have to build a prototype and see the results.

Thank you again for your help.

[MHenz]

Thank you Martin,

First, I would like to say that I really enjoy your videos. I make my own instructional videos for my clients and I know how much work is involved. Thank you very much for your effort.

So . . . to understand . . . I build the hardware with an RGB565 structure. In TouchGFX I know how to add an image and place it on my UI. I use .PNG images. I have used interactions to set the opacity of the image as required. But, do I have to do anything in code to identify the image as ARGB888?

Thank you again for your reply.

[Martin KJELDSEN]

Hi Max,

No problem. We are multiple Martins here at the office, but have both done videos so i'm not sure i can take credit, haha. But thanks! Videos are a great learning resource but yes, takes a lot of time to get right.

You do not have to do anything in terms of supporting transparency. The images are evaluated by the image converter (a part of the build process from both designer and makefiles) and the type is stored in a database, so the LCD classes in TouchGFX will evaluate the image formats when rendering and then use ChromART to do hw alpha blending if required.

All you do is specify what your nonopaque and opaque and formats are. In this case RGB565 and ARGB8888 - The image converter will handle the rest.

/Martin

[MHenz]

Thank you!

I look forward to seeing the results of the prototype. Should take about two weeks. I'll let you know how it goes.

All the best,

Max

[Martin KJELDSEN]

Let me know how it goes!

[T J]

The F750 seems to be the faulty F756 parts re-badged.

I just made a new board to run the F750/F756

My new board will run 3 shields side by side, and 2 XBees / MikroBus

I have wired unique SPI, Uart and IIC ports for each shield

comes with a detailed and verbose connection manual...

Supports H753 H743 F750 F756 F722 F767 F733 F732

Most of the primary comms interfaces are prewired uniquely to each shield position,

many however are uncommitted but provided as a patchable block,

so inter-shield wiring can be customised, either between them or back to the STM32 uncommitted pin banks.