I'm working with the Nano ESP32 and the TFT_eSPI library. Part of using the TFT_eSPI library is defining pins to control the display in the User_Setup.h file. Here is my definition section:
#define TFT_MISO D12
#define TFT_MOSI D11
#define TFT_SCLK D13
#define TFT_CS D4 // Chip select control pin
#define TFT_DC D3 // Data Command control pin
#define TFT_RST -1 // Set TFT_RST to -1 if display RESET is connected to ESP32 board RST
#define TOUCH_CS -1
If I'm reading the document correctly, using these definitions should work with either PIN Numbering mode in the IDE. But when I use By Arduino Pin, the display doesn't work, and when I use By GPIO Number, it does. Both ways compile fine.
The Cheat Sheet document will answer your question. You do know you can change the pin meaning in Tools/Pin Numbering.
A single pin can be known by two different schemes, example the silkscreen number or NANO D10 is also known as GPIO21. You can use either legacy NANO/Silkscreen numbers or ESP32 GPIO numbers depending on the setting in the Tools menu. https://docs.arduino.cc/tutorials/nano-esp32/cheat-sheet/
the remapping has problems. not everywhere in the core are the pins remapped. and in Arduino pin mapping D13 is just 13.
I recommend to not use the Arduino remapping, but to use the Dn names as it is common for example with the Wemos D1 mini for long time now..
@IraSch did you try without the prefix, both of the below should work
Arduino
#define TFT_MISO 12
#define TFT_MOSI 11
#define TFT_SCLK 13
#define TFT_CS 4 // Chip select control pin
#define TFT_DC 3 // Data Command control pin
Legacy
#define TFT_MISO 47
#define TFT_MOSI 38
#define TFT_SCLK 48
#define TFT_CS 7 // Chip select control pin
#define TFT_DC 6 // Data Command control pin
I think the defines will compile with the prefix but not compile when you try to use them in code, I tend to stick with the default and it works fine so I'm not sure if there are any quirks in there
EDIT I must mention you still have to select default/legacy pin mode under the Tools menu
Hello @IraSch! Both things are expected, and that's the reason the menu was born. I'll try to explain why, hope it's helpful to someone!
The core issue behind this is that the way Espressif chips name their pins is different and incompatible from the way all Nano boards do. Numbers are just numbers and it's simply impossible to figure out what they are referring to.
For example, should your sketch say:
#define TFT_MISO 12 // never do this with the Nano ESP32
... would that be 12 as in "the Espressif signal 12 (GPIO12)" or 12 as in "the Nano pin 12 (D12)"? As you can see in the Cheat Sheet, they're very different! The IDE/compiler can't be sure what you mean, and that's bad.
The "Pin Numbering" menu lets you tell the core how the numbers are to be interpreted by the Arduino API functions (digitalWrite, for example). However, if you want to experiment with the option, you would have to change all the pin numbers in your sketch every time, since they will now be interpreted differently!
Sounds like a nightmare, and that's where those Dxx / Axx macros come in - they are defined by the core to numbers that automatically match the current Pin Numbering choice, so that their meaning is constant - D12 in the sketch always refers to the pin labeled D12 on the board, but its value is 12 in Arduino mode or 47 in GPIO mode.
Unfortunately, as has been said, this compatibility isn't perfect - libraries do not have the concept of "Arduino pins", and if they use ESP32-specific stuff - like TFT_eSPI does - they implicitly assume numbers relate to GPIO signals. That is why when using libraries, using "by GPIO number" is preferred: you avoid many, many headaches.
So, takeaways for the Nano ESP32:
ALWAYS use pin labels, such as D12, in your sketch. You can't be wrong!
If you use libraries, select "by GPIO Number" to avoid issues.
If it wasn't for the fact that "Arduino" were so determined that this board should be pin compatible with the classic Nano then none of this pin mapping sleight of hand would have been necessary
I have ESP32 development boards and can use the pin numbers as printed on them in a sketch or with libraries with no problem
In the attempt to produce an ESP32 board with pin numbers somewhat compatible with the classic Nano we have ended up in a situation where there is a menu option that does something that is less than obvious, makes no difference in some circumstances and a 3.3V board that is not compatible with the classic Nano in any case
It is too late now and the Nano ESP32 is out in the wild causing confusion
So I think this does explain it. Unfortunately the documentation fails to mention the caveat about libraries. I will continue to use Dx labelling and stick with "by GPIO Number".
What is the .h file and where located that defines all the Dxx and I assume Axx. I am wondering if there are defines for pins other than Dxx or Axx so would like to see the actual hdr file involved.
You can touch the gory details in the variants/arduino_nano_nora/pins_arduino.h file you have in your Arduino15 folder inside packages/arduino/hardware/esp32.
Or see a copy of it online here
If I use the 'D' prefix in my sketch while trying to control the rgb led I get an error thats why I tend not to use the prefix and I mentioned in my previous post there may be quirks, I am sure there must be an explanation.
I started out in hardware almost 60 years ago, so gory details don't bother me.
Thank you so much for your patience in helping an 82yo autistic grumpy old man finally get an understanding of this board. Earlier today I had decided to abandon this board as too complex for me to understand but maybe as early as tomorrow I will start using it with some sample sketches in the WiFi and BT area to see how it goes. The small form factor is of interest to me.
Thanks again.
@sonofcy I have done a few small projects with the Nano ESP32 and I like it, offering options to rename the pins has always been a little confusing to me but I have found a method I am comfortable with and it works well. Good luck with your projects.
It seems to me that all of this confusion could have been avoided by labelling the pins on the board with their GPIO pin number rather than the way that it was done in a futile attempt to maintain some compatibility with the classic Nano
Maybe I have it wrong, but my understanding is the board is labelled right. Stick a D or A in front of that number with other Tools menu set to GPIO and everything works as intended, your code and library code. Might there be a (hopefully) rare library coded wrong? Maybe, but that is their problem and will quickly get reported and fixed.
The board is labelled correctly. The D* and A* pin numbers work if you use them but by introducing the Pin Numbering option in the Tools menu extra confusion has been caused.
There is a now a menu option that seems to imply that the pin numbering is either "By Arduino pin" or "by GPIO number" but whichever option is selected the D* and A* pin numbers work in the sketch.
To me that makes no sense. You are either using Arduino pin numbers of GPIO pin numbers, why confuse things with a mixture of both ?
As I said earlier in the topic, I have other ESP32 boards solely with GPIO pin numbers printed on them and they work fine when used in a sketch or in a library
@lburelli Do you know why plain GPIO numbers were not used for pin numbering on this board ?
The 'mixuture' is your sketch is using Dx, but most/all library code for esp32 is using GPIO.
So the solution is set the Tools menu to GPIO (for the esp32 libraries), and strictly use Dx, Ax in the sketches you write just like a NANO. Does that make sense?
As you can see 