Does PlatformIO set the proper pins for us?

PlatformIO Core
1

Hi,

Sorry for the question that may be stupid, but I looked everywhere and couldn’t find a clear answer…

I am new to embedded software developpement and I am trying to build a personal project that I’ve had at heart for a long time.
I don’t worry about the software part, but my biggest fear is to blow up my board… I purchased a wesp32 and in the product description (https://wesp32.com/files/wESP32-Product-Brief.pdf) they say:

If the user loads software on the ESP32 that does not configure the RMII pins correctly, it is possible the software will configure the pins in such a way that physical damage may result, for instance connecting an output from the PHY to an output of the ESP32, resulting in a short circuit through the chip’s output drivers.

So my question is the following:

Because PlatformIO supports my board (Silicognition wESP32 — PlatformIO latest documentation), does it means that it automatically set the proper pins both for ESP-IDF and Ardunio and that I don’t have to care at all about this warning ?

And if yes, what about the libraries I may use, will they also be automatically configured to use proper pins ?

Thanks in advance for you help,

Jonas

2

In summary, no, it’s your responsability. Good luck.

In more detail:

I would be 99% certain that it is up to the developer to avoid doing things like that. The data sheet for your board/microcontroller is a great place to start understanding this sort of thing. PlatformIO isn’t like the Arduino system where that does configure certain pins, timers, and so on. PlatformIO does not.

I often forget to enable interrupts on my ATmega328 code, leading to nothing working – but that same code works in Arduino IDE mode, which does enable interrupts.

The data sheet for the ATmega328, used in the Arduino Uno et al, has a warning similar to yours, where the AREF pin must not be connected to an external voltage if the ADC reference voltage is configured to be internal, or on the AVCC pin. Else blue smoke!

Many home built “Arduinos” on the web are built with AREF connected to 5V. Go figure.

HTH

Cheers,
Norm.

3

There are two sides to this which have to be differentiated. I’ll go into some details here.

Number 1. Setting a specific board = xxx board will make PlatformIO select that board definition JSON file. E.g., setting board = wesp32 will make PIO use wesp32.json. The board file then declares the used Arduino variant and other things.

The “variant” then maps to a specific folder in the “variants” folder of the Arduino-ESP32 framework. In your case, this is here and online contains one file, the pins_arduino.h.

These files declare global variables and macros which contain the default pin number for certain things. For example, that the default SPI MOSI pin is GPIO23. So when you e.g. use the SPI library without giving it any further pin information, it will use these default pin assignments. However, it is up to the library to use these pins – they can also ignore it. So, this file just gives the rest of the system (framework, libraries) the opportunity to do the right things by default. And when you use another board = .. value, it uses another variant folder with another pins_arduino.h which can set different default vales. This is how it works in Arduino.

As you can also see there are ETH_PHY_MDC etc. definitions here for the ethernet PHY. This would enable a built-in Ethernet library for example to use the correct pins by default. As you can see when searching for usages of this macro name, that is the case:

As you can see there, when ETH.begin() is called, the arguments have default values which map to the macros set by the variant’s pin definition file. So thereby, this automagically works by default. A sketch like https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFi/examples/ETH_LAN8720/ETH_LAN8720.ino should work without modifications and use the right pins.

Note: ESP-IDF has no notion of “variants” or a variant folder. You have to use menuconfig to setup the Ethernet PHY pins directly.

Number 2. PlatformIO will happily compile a firmware for you in which you write the commands to set a pin as an output, which is connected to the output of the PHY chip and thus creates a driver conflict. There’s no way for PIO to prevent that or warn you, that is too complex. The user has to take care that the code (and that’s the user’s, framework’s and library’s code) running on it uses the right pins. Note that the begin() method allows you to also not use the default parameter values and input any pin. So e.g., a user can call ETH.begin(12, 34, 23...) with pin numbers that will create an output conflict and destroy the board. Or, just pinMode(12, OUTPUT); and digitalWrite(12, HIGH); directly (example pin) to create the conflict.