At My Wits End - Display Recommendation

[RDJunc]

As I am sure we have all been there at one point for one issue or another but I am at that point. Lots of reading, searching, experimenting. I'm close but not there. I could really use a suggestion.

I don't think my requirements are too difficult.

Hardware:

• I am using an ESP32-S3
• 3.5" display (slightly larger is OK)
• Touch screen capability (resistive is fine)
• Parallel interface (8-bit preferred so I can still use TFT_eSPI)

Library

• Usual text, line, and shape drawing
• Ability to load in image files (e.g. png, jpg)
• Sprite and viewport support highly preferred but can work around that if needed

I did a lot of prototyping on a SPI display. The application works great except for the excessive time it takes to do the graphics which can interfere with the incoming data. That is why I need the parallel interface. I have a parallel display from DIYMall (ILI9496) but as we know, the touch screen is not supported by this library. I had hoped that all it would take is to add another library for the touch screen but the pins for that are not shown on the board or in the sparse documenation. I have not gotten any response from DIYMall yet.

I can only assume that there have been others that have been down this same path. I have read all of the threads here and tried all the suggestions that seemed to apply but to no avail.

I am open to using another display. I would highly prefer to use the TFT_eSPI library as it has been an excellent library for my application. The bottom line is that I need a display and libraries that support 8-bit parallel and touch screen.

Any assistance is greatly appreciated.

[Basitadam]

Hi @RDJunc,
"I did a lot of prototyping on a SPI display. The application works great except for the excessive time it takes to do the graphics which can interfere with the incoming data."
Do you say this for UNO board or ESP32-S3 ?

[RDJunc]

I am designing my own board and am using an ESP32-S3. For trying to figure out the best display, I have been using an ESP32-S3 development board. I am not using the Arduino pin format at all. It is just that many displays are designed to be used directly by UNOs, MEGAs, etc.

[Basitadam]

So you tested ESP32-S3 with hardware SPI @80MHz clock and it is not fast enough?

[RDJunc]

I have been running the display at 40MHz because it distorts at 80Mhz. That said, I did a quick test at 55Mhz and the display did not distort. Even at 55Mhz, I may now have another problem, or at least a new one.

I am using another ESP32 to create incoming data over the Serial1. It creates and sends a string to the display ESP32 containing the six values that need to be displayed. With a 55MHz display rate, I am able to send the data every 20ms. Pretty good. Anything less than that, and the sending ESP32 sort of craps out. It may be the way I am trying to send the data. I may have an opportunity to clean that up.

Any thoughts as to the 55Mhz limitation? I would expect that at 80Mhz, the SPI display would be perfectly fine.

Again, you are very helpful. Thanks very much.

[Basitadam]

For the 55MHz limitation there may be some reasons:

• TFT driver capability. Check datasheet. I could not find for ILI9496 but ILI9486 says SPI SCK max 15MHz (on paper):
  

• There are some TFT driver chips "fakes of clones / clones of fakes", no way to check. They might be failing at high frequencies

• If you are using Dupont like wires for the prototypes, they might be distorting the signals. You need an oscilloscope at least with BW 100MHz and 1Gsa/s to check the signals properly. For example I could go max. 42MHz with wires and full 80MHz with a good PCB for ST77916 driver. MCU was ESP32-S3. ST77916 datasheet says SPI SCK max 62.5MHz:

And

• For parallel drive, PCB design will be more important and difficult. You will have to match the lengths of at least eight traces. Will be more prone to electromagnetic noises like from inverters, high powered smps supplies, motors.
• Figure out to use DMA if you want a real speed advantage

[RDJunc]

Once again. All great information. It was a typo. The driver is the ILI9486. I guess I am already starting with that limitation. I will look into a display with a faster driver. (Any source recommendations?)

I am not using Dupont wires but I am using a protoboard. I cut discrete wires and route them on the protoboard so things are not a jumbled mess. I do have a scope and have lots of experience laying out PCBs with careful attention to routing so when I get there, I should be OK.

Ideally, I would love to just find a parallel display that I can work with but I think I will be fine with an SPI display if I can get it to run just a bit faster than the 40MHz I was using. I will also look into DMA which I assume will be another whole kettle of fish.

I also realize that there is probably some code optimization I can do that will help things. The way the code is now is that in the loop, the serial port is checked for data. If there, the data is read. If any of the six values received are different, then the display is updated. The display shows four of the six at a time depending on the scroll value. Each value is displayed numerically but also graphically, either a bar, dial, circle (iris), or wedge. That grahical animation can take some time. Things get funky if the display has not finished updating before new data comes in. Too fast and data gets missed or some of the graphics don't update properly. Like I said, I am sure that there is some optimization that could be done.

Thanks again for your great help.

[Basitadam]

Thank you.
Nice protoboard work. Much better than mines. But again, you will have crosstalk and noise. Will have better performance with the PCB. Unfortunately I don't have a source or recommendation for display/TFT driver.
One ESP32-S3 should be enough for an SPI display and serial port data collection. I would suggest to use interrupt for the serial communication. With enough cache for serial receiver. Even, you can use one core for serial, the other for display. I did something similar.
A note: TFT_eSPI has a pending problem with DMA SPI on ESP32-S3.

[RDJunc]

I have been looking at how I am handling the incoming serial data. There is definitely room for improvement. I am unnecessarily tying up the ESP32 when data is coming it. I think once I stream line that, I should be OK. As you can see in the picture with the two ESP32s, one is receiving the data and displaying it. The other is sending data. The one that is running the display, can either create dummy data internally or receive data over the serial port. When using internal data, the display updates fine and the data can be generated quickly. When it is set to use incoming data, things get bogged down. I think that is a opportunity for optimization.

[RDJunc]

I was able to increase the SPI frequency to 75MHz without the display crapping out. A PCB may get me to 80MHz.

After looking for optimization options, I am OK with how I am sending and receiving data over the serial ports. Adding start and stop characters took care of missing or corrupted incoming data. With the animations turned off, the screen updates with just numerical data just fine. I then tested each of the different graphica animations by setting the four windows to the same graphical type. The bar is the fastest. I can pretty much keep up with the incoming data no problem. With all of them set to the gauge/dial, that is almost as good. (All that is going on is a sprite rotate.) With them all set to be iris animation, things really bog down. I have to send the data much slower, just under every 100ms. The wedge is the worst. The iris and wedge have a lot of filling and so they take the longest. I will try to optimize the animations but the best solution is a parallel display but I have yet to find one that is an 8-bit parallel interface with a separate touch input so I can use a different touch library.