What is the use of framebuffer and FB24bpp graphic driver?

[Shrikant Vaishnav]

Hello all,

I have found these two driver  "framebuffer and FB24bpp " inside the gdisp folder. Now my question is: Are they used for Parallel controller less RGB display ?

Actually i have one Controller Display name: TM050RDZG03-30 From Tianma Which i wanted to interface with STM32 Microcontroller with no LTDC.

Please help.

[Joel Bodenmann]

Hello & Welcome to the µGFX community!

From the readme in the GDISP driver directory:

framebuffer        - Supports any non-palletized, non-bitpacked color display with a framebuffer
Fb24bpp            - Same as 'framebuffer' driver but supports RGB888 and BGR888 packed framebuffer formats.

So to answer your question: They are technically the same thing. Fb24bpp just supports RGB888 and BGR888 packed formats whereas the regular framebuffer driver assumes non-packed formats.

In general: The µGFX library is designed to support a vast number of different interfaces. To achieve this, we provide three different display driver models: https://wiki.ugfx.io/index.php/Display_Driver_Model
We have yet to encounter a display/controller/module that doesn't fit into one of these categories.

I'd recommend you to read the wiki page linked above and checking the datasheet if your physical display controller to figure out which mode applies. Please don´t hesitate to ask if you have any questions.

[inmarket]

To also add some more detail...

Most small display controllers use a pixel framebuffer that is outside the CPU address space. This is because the CPU is talking to them over a very slow bus like SPI or even 8 bit parallel. These buses are far too slow to be feeding display data directly to the display. Instead graphic commands are sent to the display controller which then renders into the off-CPU framebuffer. This covers most of the GDISP drivers.

The few CPU's that have the display controller built in (or are on a very high speed bus) will typically map the pixel framebuffer directly into the CPU address space. The framebuffer and fb24 drivers are for these displays.

The only odd one out is the LTSC driver for STM32 CPU'S. While this is theoretically a framebuffer driver situation, it has very complicated initialisation and eccentricities due to its support of DMA operations thus warranting a specialised driver for it.

[Shrikant Vaishnav]

18 hours ago, Joel Bodenmann said:

Hello & Welcome to the µGFX community!

From the readme in the GDISP driver directory:

framebuffer        - Supports any non-palletized, non-bitpacked color display with a framebuffer
Fb24bpp            - Same as 'framebuffer' driver but supports RGB888 and BGR888 packed framebuffer formats.

So to answer your question: They are technically the same thing. Fb24bpp just supports RGB888 and BGR888 packed formats whereas the regular framebuffer driver assumes non-packed formats.

In general: The µGFX library is designed to support a vast number of different interfaces. To achieve this, we provide three different display driver models: https://wiki.ugfx.io/index.php/Display_Driver_Model
We have yet to encounter a display/controller/module that doesn't fit into one of these categories.

I'd recommend you to read the wiki page linked above and checking the datasheet if your physical display controller to figure out which mode applies. Please don´t hesitate to ask if you have any questions.

Sir for Controller-less display like TM050RDZG03-30 which model i should use? some images for reference are attached...Please help.I have planned to interface it with STM32 micro controller with GPIO and no LTDC/GPU.

Tianma 5 inch 3.0.pdf

[Joel Bodenmann]

The HX8664/HX864 is just a display driver - it's not a display controller. The interface it offers appears to be a standard "raw" RGB interface where you have your parallel RGB input as well as signals for vertical & horizontal synchronization. That input basically needs to be driven constantly to "see" something on the actual display. That would be the job of the display controller. You cannot interface the HX8664/HX8264 in any meaningful way directly. What you seem to have is just a display panel with a display driver. You still need a physical display controller to generate those continuous RGB interface signals.

Either you need another dedicated display controller OR you actually use the STM32 LTDC - which is a display controller built into some STM32 devices for exactly this situation.
The µGFX library provides a driver for the STM32 LTDC display controller so you should be able to use that out of the box.

I'm not sure why you want to explicitly avoid the STM32 LTDC peripheral but that's exactly what you'd need in this case (or any other display controller).

[Shrikant Vaishnav]

Actually sir I don't want any dependency on STM32's LTDC.I want to interface my LCD with any Micro controller(if it has enough RAM,Timer and DMA). I believe with just GPIO, DMA and Timer we can create a Virtual LTDC like thing...Correct me if i am wrong.

[Joel Bodenmann]

Well yes, theoretically this is certainly possible. If your host has enough RAM and fast enough I/O you can certainly do this. The question would then be: why? I can only assume that this would be for educational purposes (which is fine).
Traditionally, microcontrollers/CPUs are very bad at a task like this. Which is why you'd usually use a dedicated display controller. If you want to implement one yourself, you might have a much better time using an FPGA.

All of that aside, usually physical display drivers (like yours) will have some minimum requirements regarding the main pixel clock. That should be your first thing to check whether you can keep up with that. Next, there are usually rather tight timing windows for the synchronization signals.
Assuming that you can satisfy the I/O requirements your next consideration will be memory: For your 800*400 display you'll need 800*480*bytes-per-pixel of memory for your framebuffer. So for RGB565 that would be 768 kB. For RGB888 it would be around 1.15 MB. Does your STM32 have this much memory available? You'd most likely have to add external memory via the FSC/FSMC bus. Then you'll run into bandwidth limitations. Look at the specs of that driver chip. It will allow you to calculate the minimum bandwidth required to keep it working. Again, while potentially possible, in a real life scenario your MCU will simply not be able to keep up with it.

I'm not trying to discourage you from doing this. I just want to roughly (!) explain the situation. You might be able to get this to work with an STM32 microcontroller but you'll not have a good time with it nor will you have much of it left to do anything else. This is why ST includes a dedicated display controller (LTDC) in some of their MCUs.

Maybe if  you can describe your intentions/ambitions/ideas/goals a bit we can be of more help here.