defaukt pins for uart1/2

[jumjum123]

Are there any default pins for UART1 and UART2 ?
Couldn't find any definitions in ESP-IDF.
AFAIK, any pin could be assigned, but which pins are defined, if -1 is given for pins ?

Looks like Arduino uses their own definition.
In Arduino UART1 uses rxPin = 9 and txPin = 10
UART2 uses rxPin = 16 txPin = 17
Devkit C has no pins for gpio 9/10, so in my understanding UART1 could not be used.

[kolban]

The loose answer is that if you can use a pin for regular GPIO then you can use it for UART. As such, there are no "hard bindings" between UART and pins. I am going to "guess" that a call to uart_set_pin() is a mandatory part of the setup for configuring a UART for use.

I am also guessing that you are using the ESP-IDF UART drivers for interacting with UART as opposed to poking directly at SOC registers. That would be my recommendation. However, if you were using the low-level SOC/Poking then there is one slight twist to the story ... I mention it for completeness rather than as a recommendation so you can ignore.

At the hardware level, there is a concept called GPIO multiplexing which means that when, for example, UARTx wants to drive its pins, it has to do a lookup in a translation table to determine which pins are mapped to which function ... eg. TX is mapped to GPIOtx and RX is mapped to GPIOrx. This lookup in the SOC takes time ... an INCREDIBLY small amount of time ... but time none the less. If you are poking at the SOC, you can bypass the lookup table and use some pre-architected pins which are listed on pages 41 and 42 of the current technical reference manual. For the vast majority of us, this is simply overkill ... and my guess is that the UART drivers simply ignore this and assume the use of the GPIO multiplexing.

If something in this response is unclear, please don't hesitate to post back ... it is as likely as not that I made a poor job at the description.

[jumjum123]

Hello Neil,
your explanation is clear, as always
But, sorry, it doesn't fit to my question.

For Espruino, I would like to support default pins for UART1 and 2
And this default should match existing defaults.
Taking a look to http://www.espressif.com/sites/default/ ... t_v1_0.pdf, there is an assignment of GPIO to function. This can be changed, as you wrote, no question about that.
But standards are always a good choice.

[kolban]

Howdy,
When we talk about a default, what I take that to mean is that if I *dont* specify a value, then there is an implicit value already defined. For the ESP-IDF UART drivers, I do not believe that there are any defaults for TX and RX mapping. (This doesn't mean that there isn't, just that I don't believe there to be). If there are no defaults, then what would be used if I configured a driver and didn't specify the GPIO pin mapping ... and in there is the crux of our question ... I'm of an impression that it is invalid to configure a UART through the ESP-IDF driver without specifying GPIO mapping pins. The driver doesn't have enough information to complete its configuration.

Now ... lets pause here ... because THIS speaks to using the ESP-IDF driver ... but that isn't the whole story. There is more ... however ... I am recommending that for 99.9% of folks like us, this is all we need to be aware off. At the lowest level, the ESP32 is a System on a Chip (SOC) meaning that not only does it have CPU but it has hardware IO built into the silicon. That includes UART driving. At the SOC level there are registers to be poked that cause it to operate. The purpose of the ESP-IDF drivers are to act as an encapsulation layer on top of this low level interface to make the whole story more "consumable". In some cases the drivers simply make it easier, in some cases they add "opinionated" choices that are correct for the 99.9% of use cases.

At the SOC level, there are two ways the silicon implemented UART code can drive the GPIO pins ... the UART can do a lookup in a multiplexer ... ie. TX maps to Pin X and RX maps to Pin Y .... OR ... there is the option of saying "I am UARTx and I WILL use Pins A and B". These are hard-coded and in this mode you can't change the pin mapping (by definition ... or else you would be multiplexing). The "advantage" of using fixed/hard-coded pins is that the silicon has one less job to do ... i.e. it no longer has to do a multiplexing lookup and thus saving clock cycles. This sounds good, I'm all in favor of saving cycles ... but the savings are so small that it is "unlikely" that anything but the most very advanced projects will need that level of saving.

When we look at the pin-out diagram that you posted, we see:

UART1 TX - GPIO 10
UART1 RX - GPIO 9
UART2 TX - GPIO 17
UART2 RX - GPIO 16

What that means is that IF we use the super-optimization of bypassing the multiplexing, THEN these will be the pins that MUST be used for these UARTs.

But ... if we step back to what I said before, I am of the belief that the ESP-IDF driver always uses multiplexing and IF we are using multiplexing THEN the hard-assignments of UART functions to GPIO pins goes away.

Now we can step into the discussion of "conventions" and "standards" ... these are distinct from "requirements". For example, the boot strapping pins of an ESP32 require that GPIO0 be used for bootstrapping ... I can't choose an alternative. However with UART, I am not required to use certain pins for certain functions but can instead use arbitrary pins ... putting it another way ... I have "choices". When a group of people have choices, confusion arises. One project may use RX on GPIO 21 and TX on GPIO 22 while another might use RX on GPIO 22 and TX on GPIO 21. Is this a problem? Some may think so ... and hence standards and conventions arise which are "gentlemans agreements" on what pins to use for what functions ... but they are not mandatory ... they are literally ... conventions.

And now we might come to the close ... when we use the ESP-IDF UART drivers, I do not believe that their implementation has implemented a convention. I don't believe that with the ESP-IDF UART drivers that there is a tacit agreement that says Pin X will be TX and Pin Y will by RX if you don't tell me otherwise. I believe that the identification of which pins map to which GPIOs is required.

Maybe your question wasn't "Are there default pins for UART GPIOs" but rather "Are there standards or conventions for UART GPIOs" ... and if that is the case, then I would say the closest we come is to the decisions made by the Arduino library project.

[WiFive]

Arduino uses those pins as default because there is an option for that function on those pins in the gpio MUX. Makes sense as this is the most direct path for those signals.

The gpio MATRIX doesn't suggest any default pins.

So value in a default choice should either be board specific or chip specific (MUX) or picked not to conflict with other defaults.

The driver function uart_set_pin when called with UART_PIN_NO_CHANGE is if you want to change only a subset of pins and doesn't actually even check if it can use the MUX with the pin numbers chosen, but only uses the matrix.