Sharing SPI bus between TFT_eSPI and other SPI devices - Pi Pico & Arduino IDE

[wavejaco]

Hi everyone

Firstly, after recently starting to use the TFT_eSPI library with an ST7789 display, I must express my sincere thanks to @Bodmer for this amazing library! I have great appreciation for the work that went into this to make it as easy to use as possible.

I have the following scenario for which I would like to please ask for assistance:

The display I am using is this one with a Raspberry Pi Pico, using the TFT_eSPI library and the Arduino IDE, without the touch functionality. Using the display on its own works perfectly. However, I would like to send/read data to/from an additional SPI device using the same SPI bus as the screen.

After searching through all 17 pages of discussions in this repository, the only discussion that hints towards something that I would like to do is #1569, which doesn't really help me.

I am aware of the SPI pins defines (and for other pins used by the display) in the Setup23_TTGO_TM.h file, but I am not sure how that translates to setting up the SPI bus.

Here follows a very simple (and incomplete) sketch in which I am attempting to send data on the SPI bus, while probing the bus with an oscilloscope to see if I can see the data being sent:

#include <SPI.h>
#include <TFT_eSPI.h> // Hardware-specific library

TFT_eSPI tft = TFT_eSPI();       // Invoke custom library

void setup() 
{
  // put your setup code here, to run once:
  tft.init();
  tft.setRotation(3);
  tft.invertDisplay(1); /* Required for correct colours */

  /* For testing SPI bus usage */
  SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));
  while (1)
  {
    SPI.transfer(0xAA);
    delay(1000);
  }
}

Needless to say, the above just leaves me with the Pi Pico's built-in LED doing its 4-slow-4-fast flashing, indicating what seems to be the firmware that has crashed.

How can I use the same SPI bus to communicate with an additional SPI device, while using the TFT_eSPI library? A simple example that illustrates this would be of great appreciation.

Thank you very much in advance.

[Bodmer]

I need to run some tests thus need to copy your setup to ensure the validity of the test:

Which board package are you using? (Mbed or Philhower's)
Which SPI pins are you uisng (I assume SPI port 0)?
Are you trying to use the SPI PIO interface (using #define RP2040_PIO_SPI in setup) or standard SPI peripheral?

[Bodmer]

I ran the following code and it is working as expected, SPI data 0xAA is sent to the screen (note brown colour - 0xAAAA) in this case for test purposes. This is achieved by keeping the TFT CS permanently low with the tft.startWrite function. Note that the SPI rate to the screen is also correctly changed as expected to 1MHz in this case. These results show that I have not used the same hardware/software configuration as you have, hence the questions above.

#include <SPI.h>
#include <TFT_eSPI.h> // Hardware-specific library

TFT_eSPI tft = TFT_eSPI();       // Invoke custom library

void setup() 
{
  // put your setup code here, to run once:
  tft.init();
  tft.setRotation(3);

  // Show speed of fillScreen
  tft.fillScreen(TFT_RED);
  tft.fillScreen(TFT_GREEN);
  tft.fillScreen(TFT_BLUE);
  delay(1000);

  tft.invertDisplay(1); /* Required for correct colours */
  tft.startWrite();     // Fix TFT CS low for test purposes
  
  /* For testing SPI bus usage, change the settings */
  SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));
  while (1)
  {
    // fillScreen is now slow so SPI rate changed to 1MHz
    tft.fillScreen(random(0x10000));
    for (uint16_t i = 0; i < (320*50*2); i++ ) SPI.transfer(0xAA); // 50 line brown band written (colour 0xAAAA)
    delay(1000);
  }
}

void loop(){

}

So tell me more about your configuration.

[wavejaco]

Many thanks for your replies.

Which board package are you using? (Mbed or Philhower's) Which SPI pins are you uisng (I assume SPI port 0)? Are you trying to use the SPI PIO interface (using #define RP2040_PIO_SPI in setup) or standard SPI peripheral?

I am using the Mbed package, version 3.3.0. I have been able to use both SPI ports 0 and 1 with the screen only, by changing the defines in Setup23_TTGO_TM.h. I am even able to specify the pins to use for SCLK, MOSI and MISO in this header file and it still works fine.

To answer your last question above, I believe it is the standard SPI peripheral that I am trying to use, since I don't have #define RP2040_PIO_SPI in my setup.

These results show that I have not used the same hardware/software configuration as you have, hence the questions above.

I can confirm that your sketch on my side works fine until it reaches the line, whereafter the system crashes with the blinking LED symptom described in my initial question:
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));

However, if I add the following line just before the above line, everything seems to work perfectly:
SPI.begin();

Why would this be? Is the above line (or the equivalent thereof) not called in TFT_eSPI::init( ... ) (in TFT_eSPI.cpp) when the following line executes?
spi.begin(); // This will set HMISO to input

Another question if I may: By using the following defines in Setup23_TTGO_TM.h (note the changes made to MISO, MOSI, SCLK and CS:

#define TFT_SPI_PORT 0 // Set to 0 if SPI0 pins are used, or 1 if spi1 pins used
#define TFT_MISO 4 //was 12
#define TFT_MOSI 19 //was 11
#define TFT_SCLK 18 //was 10
#define TFT_CS   5 //was 9 // Not connected
#define TFT_DC   8
#define TFT_RST  15  // Connect reset to ensure display initialises
#define TFT_BL   13  // LED back-light
 #define TFT_BACKLIGHT_ON HIGH  // Level to turn ON back-light (HIGH or LOW)

I notice that if I perform a SPI loopback test (by connecting MOSI and MISO directly and printing the result of SPI.transfer(...) to the serial monitor), no data is read from pin GP4, as per the #define. The actual MISO pin used by the Pi Pico is GP16 (I figured this out by probing all the possible SPI0RX pins). If I connect MOSI (on GP19) to MISO (on GP16, instead of GP4), the loopback test is successful.

Why is the active MISO changed from what is defined in Setup23_TTGO_TM.h?

[Bodmer]

This all comes down to choice of pins I think. The SPI default is GPIO 16 and GPIO 19. See here:
https://datasheets.raspberrypi.com/pico/Pico-R3-A4-Pinout.pdf

It is probably best to pick up the SPI class inatance direct from the TFT_eSPI library as otherwise the TFT_eSPI library may be working with a different set of pins to the default and cause problems. I happen to be using default pins so do not see the problem.

Try this sketch:

#include <SPI.h>      // We only use SPI interface for this example
SPIClass& spix = SPI;  // Create a class variable to hold the SPI class instance (default instance is SPI port 0 pins only)

#include <TFT_eSPI.h> // Hardware-specific library

TFT_eSPI tft = TFT_eSPI();       // Invoke custom library

void setup() 
{
  tft.init(); // Initialise library (will also get SPI class instance)

  spix = tft.getSPIinstance(); // Set to instance used by TFT library (may be SPI port 0 or 1)

  tft.setRotation(3);

  // Show speed of fillScreen
  tft.fillScreen(TFT_RED);
  tft.fillScreen(TFT_GREEN);
  tft.fillScreen(TFT_BLUE);
  delay(1000);

  tft.invertDisplay(1); /* Required for correct colours */
  tft.startWrite();     // Fix TFT CS low for test purposes
  
  // Now we use the spi instance used by the library (may not be default SPI instance)
  spix.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));
  while (1)
  {
    // fillScreen is now slow so SPI rate changed to 1MHz
    tft.fillScreen(random(0x10000));
    for (uint16_t i = 0; i < (320*50*2); i++ ) spix.transfer(0xAA); // 50 line brown band written (colour 0xAAAA)
    delay(1000);
  }
}

void loop(){

}

[Bodmer]

Ah, I see you are using the Mbed board package, not the Earl Philhower package which I prefer and the above examples work fine.

Yep, I just tested with the Mbed package and the processor crashes. I don't have time to find out why as I don't use that package. As far as I am aware all the library examples work OK with both packages., but you have a new use case So you will need to work out a way forward for your needs as I am not so familiar with the Mbed package.

[wavejaco]

I didn't even see the function getSPIinstance() in your library (you really thought of everything when you wrote this :)) - that is very useful!

I have tested your code as posted above and I can confirm that it works on the Mbed package, provided that I add spix.begin() before calling spix.beginTransaction(...). The crash caused by not adding that must probably be something to do with some variable that is not initialised in the SPI class by the time spix.beginTransaction(...) is called. Nevertheless, that small detail is not a matter of concern for me.

One thing that has me very curios, and it is probably because I don't fully understand all the inner workings of the SPI class, the board package/core and your library (as well as the fact that I come from a C background, not C++)... How are you able to "duplicate" the SPI0 pins on the alternative SPI0 pins by specifying the appropriate GPIO pins in Setup23_TTGO_TM.h? For example, by specifying #define TFT_MOSI 7, the SPI bus drives the MOSI signal on both GPIO 19 (the default for SPI0) and GPIO 7. The same applies for MISO.

Attempting to figure this out, I have noticed that MOSI is configured as output in SPI.cpp:

void SPIClass::begin()
{
  uint8_t sreg = SREG;
  noInterrupts(); // Protect from a scheduler and prevent transactionBegin
  if (!initialized) {
   
  /* ... */
  /* *** Code stripped for easy reference in discussion *** */

    // Set direction register for SCK and MOSI pin.
    // MISO pin automatically overrides to INPUT.
    /* ... */
    pinMode(SCK, OUTPUT);
    pinMode(MOSI, OUTPUT);
  }
  initialized++; // reference count
  SREG = sreg;
}

But where is MOSI being "defined"/"specified" in terms of which pin is used for the signal? I cannot find something obvious that answers this question for me.

Looking at your library, the SPI bus is initialised when you call spi.begin() in TFT_eSPI::init( ... ) (in TFT_eSPI.cpp). Where does the "mapping" or "duplication" (for lack of the correct term) of the SPI pins, as defined in Setup23_TTGO_TM.h, happen? This, I believe would be one of the key pieces of the puzzle for me in understanding how this all works.

[Bodmer]

Pins are defined when the class is created here:
https://github.com/Bodmer/TFT_eSPI/blob/master/Processors/TFT_eSPI_RP2040.c#L14

[wavejaco]

Pins are defined when the class is created here: https://github.com/Bodmer/TFT_eSPI/blob/master/Processors/TFT_eSPI_RP2040.c#L14

Fantastic! It never appeared to me to look further at the files in the /Processors/ directory. Thanks for pointing me in the right direction.