Anyone managed to get TFT_eSPI working with the Arduino Nano RP2040 Connect (NOT Raspberry Pico) ?

[ruifig]

For the last day, I've been trying to get the library to work with an Arduino Nano RP2040 + IL9341 SPI (https://smile.amazon.co.uk/gp/product/B07QJW73M3/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 ).

After messing around with lots of stuff, such as trying different pins, etc, I couldn't get it to work. It stays a white screen.
To make sure it wasn't a problem with the Arduino or the screen, I tried two Arduino, still without success.
After that, I tried a Pico with that same screen and it worked straight away.

I don't rule the fact I might be getting something wrong, but can anyone confirm they got TFT_eSPI working on an actual Arduino RP2040 (NOT the Raspberry Pico) ?

FYI, this is the config I have, using PlatformIO, with default compiler and Arduino framework.

#define ILI9341_DRIVER
//#define ILI9341_2_DRIVER     // Alternative ILI9341 driver, see https://github.com/Bodmer/TFT_eSPI/issues/1172

// For the Pico use these #define lines
#define TFT_MISO  12
#define TFT_MOSI  11
#define TFT_SCLK  13
#define TFT_CS   2  // Chip select control pin
#define TFT_DC   3  // Data Command control pin
#define TFT_RST  -1  // Reset pin (could connect to Arduino RESET pin)
//#define TFT_BL     // LED back-light
//#define TOUCH_CS 21     // Chip select pin (T_CS) of touch screen

#define LOAD_GLCD   // Font 1. Original Adafruit 8 pixel font needs ~1820 bytes in FLASH
#define LOAD_FONT2  // Font 2. Small 16 pixel high font, needs ~3534 bytes in FLASH, 96 characters
#define LOAD_FONT4  // Font 4. Medium 26 pixel high font, needs ~5848 bytes in FLASH, 96 characters
#define LOAD_FONT6  // Font 6. Large 48 pixel font, needs ~2666 bytes in FLASH, only characters 1234567890:-.apm
#define LOAD_FONT7  // Font 7. 7 segment 48 pixel font, needs ~2438 bytes in FLASH, only characters 1234567890:-.
#define LOAD_FONT8  // Font 8. Large 75 pixel font needs ~3256 bytes in FLASH, only characters 1234567890:-.
//#define LOAD_FONT8N // Font 8. Alternative to Font 8 above, slightly narrower, so 3 digits fit a 160 pixel TFT
#define LOAD_GFXFF  // FreeFonts. Include access to the 48 Adafruit_GFX free fonts FF1 to FF48 and custom fonts

// Comment out the #define below to stop the SPIFFS filing system and smooth font code being loaded
// this will save ~20kbytes of FLASH
#define SMOOTH_FONT

// For the RP2040 processor define the SPI port channel used, default is 0
// #define TFT_SPI_PORT 1 // Set to 0 if SPI0 pins are used, or 1 if spi1 pins used

#define SPI_FREQUENCY  20000000

// Optional reduced SPI frequency for reading TFT
#define SPI_READ_FREQUENCY  20000000

// The XPT2046 requires a lower SPI clock rate of 2.5MHz so we define that here:
#define SPI_TOUCH_FREQUENCY  2500000

//#define SUPPORT_TRANSACTIONS 1

My platformio.ini file

[env:nanorp2040connect_2]
platform = raspberrypi
board = nanorp2040connect
framework = arduino
monitor_port = COM5
monitor_speed = 115200
lib_deps = 
	;SPI
build_flags =
	-DUSER_SETUP_LOADED=1
	-include $PROJECT_DIR/src/TFT_eSPI_MySetup_ArduinoNanoRP2040.h

My program:

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

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

void setup(void) {
  MySerial.begin(115200);
  SPI.begin();
  tft.begin();
  tft.setRotation(1);
  tft.fillScreen(TFT_GREEN);
}

void loop() {
  delay(1000);
  MySerial.println(millis());
}

What else I tried:

• Different SPI speeds
• IL9341_DRIVER and IL9341_2_Driver. (The Pico actually works with both)
• Different pins (other than the SPI pins of course)
• Reset with an explicit pin and -1 (the the jumper wire connected to the Arduino's RESET pin)
• SUPPORT_TRANSACTIONS define and undefined

Next thing I'll try is the Adafruit_ILI9341 library, since there are actual videos of people using that combination (AdaFruit_ILI9341 + Arduino RP2040 + SPI screen).

[Bodmer]

You must use #define TFT_SPI_PORT 1 since you are using pins 11, 12, 13.

[ruifig]

No luck, it seems. :(
By the way, I just tested with Adafruit_ILI9341, "graphicstest" example, and it's working as-is.
Going to try and clean up whatever I have in my TFT_eSPI sample, including using the same pins as the Adafruit sample, and see what happens.

[Bodmer]

Try the Earle Philhower RP2040 package. It is available on Github and is very good.

[ruifig]

Cleaned up things, made sure I'm using the same pins, same breadboard, etc. Literally just swapping between building the TFT_eSPI sample and the Adafruit sample. Adafruit is working, TFT_eSPI is not.

Yep, it's on my list to troubleshoot this.
Been trying to avoid it, because picoprobe debugging is broken with Philhower RP2040.

By the way, just got the latest of TFT_eSPI, and not building for me.
In TFT_eSPI::initDMA, it fails in:

channel_config_set_dreq(&dma_tx_config, spi_get_dreq(SPI_X, true));

Can't find spi_get_dreq.

If I define RP2040_PIO_SPI is defined, then it doesn't build because it doesn't support Mbed. :) :

  // Board package specific differences
  #ifdef ARDUINO_ARCH_MBED
    // Not supported at the moment
    #error The Arduino RP2040 MBED board package is not supported. Use the community package by Earle Philhower.
  #endif

Anyway. On to maybe try Philhower's core, otherwise I'll stick with the sluggish Adafruit_ILI9341 :)

[Bodmer]

Looks like the Arduino package uses an out of date sdk.

Replace the spi_get_dreq with this line to avoid the error:

channel_config_set_dreq(&dma_tx_config, spi_get_index(SPI_X) ? DREQ_SPI1_TX : DREQ_SPI0_TX);

I did modify a copy of the Adafruit library to boost performance with the RP2040. See here:
https://github.com/Bodmer/Adafruit-GFX-Library
and here:
https://github.com/Bodmer/Adafruit_ILI9341

[Bodmer]

I tried selecting the Arduino Nano RP2040 Connect board in Earle Philhower's package and it compiled uploaded and ran fine on a standard RP2040 Pico, this suggests there is nothing special about the Arduino Connect board.

[Bodmer]

As far as I can see the Nano Connect does not provide some of the GPIO pins you have selected:

Note that when a number for a pin is provided the library assumes it is a GPIO designation.

[ruifig]

Since you wrote TFT_eSPI, you know better than me, so correct me if I'm wrong....
Regarding the Arduino framework, it seems to me that if I'm using a Pico, then pin numbers in the code are their GPIO designation like you suggest.
For example, I got it working with a Pico, with the default pins such as:

#define TFT_MISO  0
#define TFT_MOSI  3
#define TFT_SCLK  2
#define TFT_CS   20  // Chip select control pin
#define TFT_DC   18  // Data Command control pin
#define TFT_RST  19  // Reset pin (could connect to Arduino RESET pin)

so I know they are indeed their GPIO designation[

But when coding for an Arduino RP2040, I'm fairly certain a pin number is a Dxx designation. E.g: SCK is pin 13 (aka D13).
E.g: You make calls to pinMode of course, but if I go look at the pinMode implementation, I see this:

void pinMode(pin_size_t pin, PinMode mode)
{
  mbed::DigitalInOut* gpio = digitalPinToGpio(pin); <<<<<<< converts digital pin to GPIO
  if (gpio != NULL) {
    delete gpio;
  }

Also, as I got the Adafruit sample working, I can confirm that it's indeed the Dxx designation (regarding the Arduino framework), otherwise my wiring would be wrong.

If I'm correct, and TFT_eSPI makes the assumption the pin numbers for the Arduino RP2040 are the GPIO number like when for the Pico, then maybe that's the problem ? I haven't looked at any of the TFT_eSPI implemenation details, so I can't say.

Fyi, I'm a software engineer by trade, but fairly new to the Arduino/IOT world, and just started using the RP2040, so feel free to correct me anywhere. :)

[Bodmer]

You have the option of using Dxx or GPIO numbers. The Arduino environment maps the GPIO pins to Dxx pins. GPIO 7 is mapped to D11 so you can thus use either:

#define TFT_MOSI D11 // Arduino reference
or:
#define TFT_MOSI 7 // GPIO reference

I prefer to use GPIO numbers as the library supports processors where ther are no Dxx designations for some pins and the mapping varies between processors, boards and suppliers.

I think this is the root cause of the problems you are having.

[ruifig]

Ok, trying that at the moment.
Update:
If the library expects the defines to be the GPIO designations, then you have a problem when compiling for the Arduino RP2040:

I see that for example, in some GPIO specific code that it's indeed a GPIO you expect. E.g:

////////////////////////////////////////////////////////////////////////////////////////
// Define the CS (TFT chip select) pin drive code
////////////////////////////////////////////////////////////////////////////////////////
#ifndef TFT_CS
  #define CS_L // No macro allocated so it generates no code
  #define CS_H // No macro allocated so it generates no code
#else
  #if !defined (RP2040_PIO_INTERFACE) // SPI
    #if  defined (RPI_DISPLAY_TYPE)
      #define CS_L digitalWrite(TFT_CS, LOW);
      #define CS_H digitalWrite(TFT_CS, HIGH);
    #else
      #define CS_L sio_hw->gpio_clr = (1ul << TFT_CS)      <<<<<<<<<<<<<<< THIS
      #define CS_H sio_hw->gpio_set = (1ul << TFT_CS)    <<<<<<<<<<<<<<< THIS

But then because you also use pinMode, that same TFT_CS it is treated as a Dxx in other places.

E.g:

void TFT_eSPI::initBus(void) {

#ifdef TFT_CS
  pinMode(TFT_CS, OUTPUT);    <<<<<<<<<<<<<
  digitalWrite(TFT_CS, HIGH); // Chip select high (inactive)
#endif

Note: This is not a problem when building for the Pico, because a raw pin number is a GPIO number in the Arduino API, so the library is treating it as a GPIO everywhere.
But when building for the Arduino RP2040, it ends up treating the same TFT_CS as a GPIO in some places and Dxx in others.

[Bodmer]

Unfortunately the Dxx designations are managed in different ways by different board packages. If you try this:

void setup() {
  Serial.begin(9600);
}


void loop() {
  Serial.println(D10);
  delay(1000);
}

You will find out.

Using Earle Philhower's RP2040 package this prints 5 which is the correct GPIO for the RP2040 Nano Connect.

However I strongly suggest you use GPIO numbers as the approach to pin number handling varies between packages.

[ruifig]

Got it working. :D
The problem is indeed the mixup of meaning if we just specify pins as raw numbers when compiling for Arduino RP2040.
If I specify all pins as "pX", then it works:
E.g:

#define TFT_MISO  p4
#define TFT_MOSI  p7
#define TFT_SCLK  p6
#define TFT_CS   p5  // Chip select control pin
#define TFT_DC   p21  // Data Command control pin
#define TFT_RST  -1  // Reset pin (could connect to Arduino RESET pin)

Those work because they are enums with the respective GPIO value, and work fine internally with pinMode/digitalWrite because of override for those enums.

Passing raw integers as pin numbers will never work because TFT_eSPI will treat them as GPIO, but the internal calls to pinMode/digitalWrite treat them as digital pins.
For example, say I do:

#define TFT_CS 5

TFT_eSPI will use GPIO 5, but the internal calls to pinMode/digitalWrite will end up using GPIO 17 because of Arduino's digitalPinToPinName.

Also, it seems we can't use the Dxx designations as-is, because those aren't available depending on platform defines.
E.g, the Arduino's RP2040 PinNames.h does this:

#ifndef ARDUINO_ARCH_MBED
    D0          = p1,
    D1          = p0,
    D2          = p25,
    D3          = p15,
    D4          = p16,
    D5          = p17,
    D6          = p18,
    D7          = p19,
    D8          = p20,
    D9          = p21,
    D10         = p5,
    D11         = p7,
    D12         = p4,
    D13         = p6,

    A0          = 26,
    A1          = 27,
    A2          = 28,
    A3          = 29,
#endif

I hope it makes sense.
I assume you don't have an Arduino RP2040 to test?

[Bodmer]

Yes, there are package compatibility issues, the problems at the moment are:

1. Earle Philhower's board package expects the GPIO number in pin functions such as digitalWrite(), whereas in the Arduino world normally the functions use an abstracted pin name.
2. To get the pin number mapping with Earle's package it is necessary to use Dxx pin names in digitalWrite(). This should also work with the Arduino Mbed package but as you note these pin references are not yet available to a library or user sketch, even though the issue was raised > 6 months ago.

To resolve this in the short term, when using the Arduino Mbed package with TFT_eSPI I think that using your suggested pxx pin reference is a good approach. When using Earle's package then use the GPIO number or Dxx for Arduino pin references.

I think Earle's package has better community engagement, features and bug fix response time so the priority is for TFT_eSPI to support that package.

Thanks for raising this issue. I don't have an Arduino Connect but I can use that Mbed package and run digital I/O based examples on any RP2040 board.

[ruebarb]

Got it working. :D The problem is indeed the mixup of meaning if we just specify pins as raw numbers when compiling for Arduino RP2040. If I specify all pins as "pX", then it works: E.g:

#define TFT_MISO  p4
#define TFT_MOSI  p7
#define TFT_SCLK  p6
#define TFT_CS   p5  // Chip select control pin
#define TFT_DC   p21  // Data Command control pin
#define TFT_RST  -1  // Reset pin (could connect to Arduino RESET pin)

Those work because they are enums with the respective GPIO value, and work fine internally with pinMode/digitalWrite because of override for those enums.

Passing raw integers as pin numbers will never work because TFT_eSPI will treat them as GPIO, but the internal calls to pinMode/digitalWrite treat them as digital pins. For example, say I do:

#define TFT_CS 5

TFT_eSPI will use GPIO 5, but the internal calls to pinMode/digitalWrite will end up using GPIO 17 because of Arduino's digitalPinToPinName.

Also, it seems we can't use the Dxx designations as-is, because those aren't available depending on platform defines. E.g, the Arduino's RP2040 PinNames.h does this:

#ifndef ARDUINO_ARCH_MBED
    D0          = p1,
    D1          = p0,
    D2          = p25,
    D3          = p15,
    D4          = p16,
    D5          = p17,
    D6          = p18,
    D7          = p19,
    D8          = p20,
    D9          = p21,
    D10         = p5,
    D11         = p7,
    D12         = p4,
    D13         = p6,

    A0          = 26,
    A1          = 27,
    A2          = 28,
    A3          = 29,
#endif

I hope it makes sense. I assume you don't have an Arduino RP2040 to test?

Can you post the User_Setup.h file you used to get this working on an Arduino connect, I can't get it working on a 9488.

I had the same screen working super fast on a pico. I apprecaite the help, thanks

[Bodmer]

Here is an example setup file:
https://github.com/Bodmer/TFT_eSPI/blob/master/User_Setups/Setup62_RP2040_Nano_Connect_ILI9341.h

[ruebarb]

Thanks, I had no idea these were in the library the entire time.