Faster display, SPI or Parallel?

Good evening everyone.
I have a big doubt that I can't get rid of, I'm doing various online searches but I can't understand.

Using the same MCU, for example an ATMEGA1284P that has enough pins, using the same display driver, for example the ILI9488 that supports both protocols, with which protocol you can get better results in terms of speed?

Thank you all

Parallel 8080-16 requires 21 GPIO pins
Parallel 8080-8 requires 13 GPIO pins
SPI requires 6 GPIO pins

Parallel is always going to be faster. Most TFTs are capable of faster speeds than an AVR can achieve.

ILI9488 requires 3 SPI bytes per pixel. Other controllers can use 2 SPI bytes per pixel e.g. ST7796S
Even if you have an Arduino with DMA the ILI9488 is painful with SPI.

Any TFT is painful with a 5V MCU. e.g. 21 level shifter channels for 8080-16

God gave you Xmega and SAM microcontrollers. They work much faster, have DMA and with sensible 3.3V GPIO.

David.

Both will be much faster then your eyes can follow. This is a system decision, what else are you using, how many pins do you have, SPI uses 4 pins+, Parallel uses at least five but as many as 30 depending on the interface etc. Your choice of MCU may be a tad bit short on IO if you use a parallel interface. 24 pins are for data and I think 6 pins are needed for control. I would suggest you study the appropriate data sheets. You will also need to determine your refresh rate and be sure you can support that and your background software.

Ok, perfect, thank you very much David (I am reading a lot of your discussions about your graphics library, I am very interested and would like to try it as soon as possible), thank you very much Gil for the explanation.
So from what I understand is that with a parallel interface I can certainly have higher speeds, obviously with the drawback of using many pins, and that the final speed depends mainly on the software (with the same MCU), on how I manage the graphic commands , essentially how good or bad the library I use is.
I have good experiences with UTFT libraries and its more fast derivatives (olso I maked some modification) on a parallel 16bit display project, now I would like to develop a new project but I have never used SPI displays so I didn't know if they were better or worse (in terms of speed).
Also for the choice of the MCU .... until now I have used the 1284P for the ease of developing the PCB and soldering, but I would love to move on to projects with SAM and work in SMD.

I'm about to have a Display designed on my specifications, with specific characteristics for my needs, so I can choose the type of display, driver and way of use.
It will be a 3.5 320x480 IPS Display, which Driver do you recommend to use? maybe it supports both protocols that I can choose at will, with fuses on PCB, Parallel and SPI?
A driver that supports as many functions as possible and is well compatible with available libraries (even if I need to adapt the new driver if necessary).
Thanks again

You just came up with the question that most of the fans of TFTs in the arduino environment we always do. In buy-install systems, there are very few "quick options" and they are generally the most expensive. In this case, do not forget this: for the hardware to be fast, the library is essential.

UTFT is a good starting point for learning, but it is not the best for achieving a high final speed.

Your TFT must have a dedicated graphics chip (GPU) in addition to the controller chip. The vast majority of display manufacturers (90% or a little more ...) only install display drivers.

If you have the skills to design a base that gets the best performance even with AVR, I recommend this project:

https://andybrown.me.uk/category/arduino/

This is the cherry on the cake: https://andybrown.me.uk/2015/02/02/awcopper/

A couple more thoughts: the elements that you are going to integrate into your project will also influence the speed. Keep in mind that SPI devices can interfere with each other, negatively influencing the final speed

The speed of the MCU will not necessarily influence the final speed.

There are lots of 240x320. 320x480 have less controllers

Adafruit have a HX8357 display that you can configure for SPI or Parallel.
BuyDisplay (EastRising) have ILI9488 display that you can configure for SPI or Parallel.
The HX8357 has better SPI performance.

Both companies have boards that handle 3V - 5V level shifting.

But quite honestly, it is probably easier to have one SPI screen and one Parallel screen.
Then you can compare them at the same time.

If you move to ARM or ESP mcu, they work much faster and have DMA.
So you can drive SPI as fast as the TFT can handle. You always have to slow down to TFT speed when using Parallel.

David.

TFTLCDCyg:
You just came up with the question that most of the fans of TFTs in the arduino environment we always do. In buy-install systems, there are very few "quick options" and they are generally the most expensive. In this case, do not forget this: for the hardware to be fast, the library is essential.

UTFT is a good starting point for learning, but it is not the best for achieving a high final speed.

Your TFT must have a dedicated graphics chip (GPU) in addition to the controller chip. The vast majority of display manufacturers (90% or a little more ...) only install display drivers.

If you have the skills to design a base that gets the best performance even with AVR, I recommend this project:

https://andybrown.me.uk/category/arduino/

This is the cherry on the cake: https://andybrown.me.uk/2015/02/02/awcopper/

A couple more thoughts: the elements that you are going to integrate into your project will also influence the speed. Keep in mind that SPI devices can interfere with each other, negatively influencing the final speed

The speed of the MCU will not necessarily influence the final speed.

TFTLCDCyg:
You just came up with the question that most of the fans of TFTs in the arduino environment we always do. In buy-install systems, there are very few "quick options" and they are generally the most expensive. In this case, do not forget this: for the hardware to be fast, the library is essential.

UTFT is a good starting point for learning, but it is not the best for achieving a high final speed.

Your TFT must have a dedicated graphics chip (GPU) in addition to the controller chip. The vast majority of display manufacturers (90% or a little more ...) only install display drivers.

If you have the skills to design a base that gets the best performance even with AVR, I recommend this project:

https://andybrown.me.uk/category/arduino/

This is the cherry on the cake: https://andybrown.me.uk/2015/02/02/awcopper/

A couple more thoughts: the elements that you are going to integrate into your project will also influence the speed. Keep in mind that SPI devices can interfere with each other, negatively influencing the final speed

The speed of the MCU will not necessarily influence the final speed.

well, thank you very much, beautiful project, for sure having a dedicated GPU would be the best solution, more complex, but feasible thing. At this point I might also think about displays like Nextion ...
But the fact is that I have to build the display to my specifications, with a specific PCB for my needs, so the Nextion (or any other PCB display already prepared) is not good.

david_prentice:
There are lots of 240x320. 320x480 have less controllers

Adafruit have a HX8357 display that you can configure for SPI or Parallel.
BuyDisplay (EastRising) have ILI9488 display that you can configure for SPI or Parallel.
The HX8357 has better SPI performance.

Both companies have boards that handle 3V - 5V level shifting.

But quite honestly, it is probably easier to have one SPI screen and one Parallel screen.
Then you can compare them at the same time.

If you move to ARM or ESP mcu, they work much faster and have DMA.
So you can drive SPI as fast as the TFT can handle. You always have to slow down to TFT speed when using Parallel.

David.

So of this 2 drivers, the best would still be the HX8357 ... good.
I'm only ever working on 3V3, even with the 1284P, so I don't need a level adaptation.
My idea would be to switch to ARM or ESP (even here a suggestion would be useful, considering that I would still like to use a good part of the current firmware developed on the AVR, obviusely with adaptation).
So what you tell me is that: if I use an ARM or ESP with DMA and SPI display can I still have the maximum performance? without having to use the Parallel? Did I understand well?

It is worth prototyping with ready-made components.

You get your project working faster. You soon see any advantages or problems with a component.

Then it is simply a question of designing a pcb for your own basic components. And getting your "working software" to operate smoothly on your custom hardware.

The cost of ready-made modules for prototyping is pretty cheap nowadays.
And the risk of problems with your home grown custom pcb is reduced when you can copy the schematic and layout from the proven modules.

Regarding SPI performance. Look at Bodmer's TFT_eSPI for ESP boards.
And at Marek's ILI9341_due performance for a Due.

The SPI will be plenty fast enough for most projects. And use less pins.
There is a limit to the actual speed of a TFT controller. Parallel will be faster.

David.

fine, perfect.
Meanwhile, I have removed the doubts I had, thanks to you.
Now first I'll try to figure out which MCU to use based on all the IO channels I need, with all the functions my device will need to have.
In the meantime, thank you very much, I will certainly still need your help :slight_smile:
Many Thanks