Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

ESP32 / Arduino TFT / SPI Hardware

Status
Not open for further replies.

Wp100

Well-Known Member
Hi,
Just a simple question without getting involved in loads of code.

Have been running an ili9341 tft screen with both an Ardunio Nano and ESP32 using the Adafruit GXF libraries but in SPI Software mode as that was the only one we could get working in our early days of C++.

Now tried running the standard Adafruit Example \ Graphic Test code example and have been able to get it to run in the much faster SPI Hardware mode.
However when we modify our existing program to run in SPI Hardware mode , the opening screen display in SetUP() works fine, but then anything in the main Loop() or subroutine does not display, just a White blank screen.
Its as if the tft.begin() routine has been closed down, though never seen any such instruction.

If we add tft.begin() to the main loops display code, it will then display ok, but there is a big screen pause each loop of the code as the tft.begin() re- initialises the screen again.

Our ESP32 code is not using any wifi/bt and just using very common libraries like Ds18b20, RTC and EEprom.

Anyone experienced similar problems and a cure ?
 
At a guess, some of the initialisation or inter-character delays are not long enough.

Certain commands need a fixed delay while other can run at full speed. I'm guessing the software SPI was slow enough so characters or commands were spaced enough so it always allowed the execution time before the next byte arrived?
 
At a guess, some of the initialisation or inter-character delays are not long enough.

Certain commands need a fixed delay while other can run at full speed. I'm guessing the software SPI was slow enough so characters or commands were spaced enough so it always allowed the execution time before the next byte arrived?

Thanks, that does sound reasonable, though with over 2000 lines of code it could be a job to find the culprit.

Have played around with the code leaving out libraries in turn etc. but nothing changes.

Perhaps going into the library code and try adding a little delay to each of the D/C instrucions might work, though that might defeat the point of its high speed ?!

For this existing project will revert to its original Software SPI, but for future projects will try the Hardware SPI but check on the display functioning at each stage to ensure its ok.

Apart from the TFT screen have not used the Arduino/ESP32 SPI for any other devices, so wonder if other SPI devices suffer from similar problems with the fast Hardware SPI ?
 
Thanks, that does sound reasonable, though with over 2000 lines of code it could be a job to find the culprit.

Have played around with the code leaving out libraries in turn etc. but nothing changes.

Perhaps going into the library code and try adding a little delay to each of the D/C instrucions might work, though that might defeat the point of its high speed ?!

For this existing project will revert to its original Software SPI, but for future projects will try the Hardware SPI but check on the display functioning at each stage to ensure its ok.

Apart from the TFT screen have not used the Arduino/ESP32 SPI for any other devices, so wonder if other SPI devices suffer from similar problems with the fast Hardware SPI ?
Try slowing the hardware SPI down a little - it may be exceeding what the TFT can accept, but is so close most of the time it works.

Have a look here:

 
Try slowing the hardware SPI down a little - it may be exceeding what the TFT can accept, but is so close most of the time it works.

Have a look here:

Thanks, will have a good read about changing those timings etc.

Just tried converting another more recent and we thought more complicated tft and touch based program from its software SPI to the hardware SPI as surprise, surpise its working fine ?!

Think for the original program problem it points towards what you both say, plenty to try :)
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top