LCD parallel Interface vs LCD TFT Controller

[btorres]

I have an 8 bit parallel, 240x280 TFT display and was wondering:

What's the difference between the "LCD parallel Interface" and the "LCD TFT Controller" under the "Display controller" section?

Is there a significant difference in fps or processing consumption between an MCU with the LCD parallel Interface and an MCU with NO display controller? If so, what makes the performance difference significant?

Thanks!

[Issamos]

Hello @btorres 

LCD parallel Interface need to Connect the MCU's GPIO pins to the display's data and control lines manually. That requires precise timing control and increased software effort. But, for the LCD TFT Controller, there is a specialized hardware component within the MCU designed for TFT display control, delivering improved performance and reduced processing power consumption.

That's why if we compare an MCU with an LCD TFT Controller to one without we find out that The MCU without a TFT Controller consumes more processing power, as it handles display tasks in software, potentially limiting its capacity for other tasks. Also, the MCU with a TFT Controller achieves higher frame rates due to efficient display data management, while the other may have lower frame rates.

Best regards.

II

[AScha.3]

it depends on the type of display:

a: simple "raw" display, needing continuous data stream to show a picture -> need TFT controller

b: display with onboard RAM and controller, need just serial or par interface to send picture data once to TFT

usually small TFT have ram+controller onboard, big displays (need big RAM area for picture) have only line drivers and need continuous data to refresh picture.

+

c: there are also big displays with special complex controller + ram onboard, connected serial SPI, that can generate the picture with high level commands, like : draw line x-y , fill circle with color x , put character x-y size z ...etc.

(look for "EVE" controller... ) 

https://www.dev-tools.de/BT81X-EVE3-Display-Module

[waclawek.jan · Accepted solution]

"LCD parallel Interface" is just ST's marketing trying to sell mcus with no specific LCD-related functionality, but having FMC/FSMC so that an external LCD controller (or LCD module with controller) can be interfaced through parallel external memory bus.

> Is there a significant difference in fps or processing consumption between an MCU with the LCD parallel Interface and an MCU with NO display controller?

This is a tricky question, and there is no single and simple answer, as it depends on many factors, e.g. expected type(s) of graphics features (e.g. color depth, requirement to support various formats, layering/transparency, windowing, scrolling, other bitblt features); bus widths, involved memories data widths and latencies, capabilities of used internal and/or external controller(s)... [EDIT] that was answer to a different question, "difference between MCU with "LCD parallel interface" vs. mcu with integrated LCD controller (LTDC) [/EDIT]

As I've said above, "LCD parallel interface" means NO display controller.

JW

[btorres]

Ah, I had a feeling it might be for marketing. So let me rephrase my second question. Is there a difference in fps or processing consumption between:

an MCU using the FMC/FSMC to interface with an 8 bit parallel LCD

and

an MCU without/not using the FMC/FSMC to interface with an 8 bit parallel LCD?

[btorres]

Ah ok. My TFT has a "JD9851A" driver IC so I definitely don't need the TFT controller. That leads me to wonder though:

Does an MCU with the "LCD parallel interface" (FSMC) lead to better fps or processing consumption compared to an MCU WITHOUT the "LCD parallel interface" (FSMC)?

[MM..1]

You self reply only need rephrase (FSMC) lead to better or equal fps AND processing consumption compared

[waclawek.jan]

> Does an MCU with the "LCD parallel interface" (FSMC) lead to better fps or processing consumption compared to an MCU WITHOUT the "LCD parallel interface" (FSMC)?

I don't know; again, the exact answer is dependent on many circumstances.

Individual accesses using "bit-banged" parallel bus ("manually" manipulated RD/WR/CS) may turn to be faster than accesses through FSMC (although not necessarily).

However, using FSMC as compared to bit-banging has the advantage that the processor can perform a write and that's buffered, so the processor may continue executing some other code even if the write itself is slow and maybe even slower than if it would be "bit-banged". You can also use it at target of DMA.

But, at the end of the day, in a particular application it may turn out that neither of these is relevant, as processing to generate the picture may be significantly longer than storing the result to the LCDC using either method.

A good way to estimate the capabilities of any approach is to get a ready-made board such as some of the DISCOs, and experiment.

JW

[btorres]

Gotcha. Thank you so much