On ESP32, and a lesser extent on ESP32-S2 and other chips, pin state after reset is not consistent. In general pins are to set an input state, but some have a pull-up enabled, some have a pull-down enabled, and some have neither. As an example, ESP32 GPIO2 has a pull-down enabled after reset.
The pin states are listed in the "Pin List" tables in the respective datasheets. Here is a clip from the ESP32 Pin List:
wpd is "weak pull-down; wpuis "weak pull-up";ie` is input enabled.
We currently use the ESP-IDF routine gpio_pin_reset() to reset a pin, which uniformly sets the pin to have its input and output disabled, with a pull-up. That does not always match the states given in the Pin Tables. "Input" vs "disabled" doesn't really matter, but the pulls do.
Consider whether it's worth replicating the default hw state instead of just using gpio_pin_reset().
On ESP32, and a lesser extent on ESP32-S2 and other chips, pin state after reset is not consistent. In general pins are to set an input state, but some have a pull-up enabled, some have a pull-down enabled, and some have neither. As an example, ESP32 GPIO2 has a pull-down enabled after reset.
The pin states are listed in the "Pin List" tables in the respective datasheets. Here is a clip from the ESP32 Pin List:
wpdis "weak pull-down;wpuis "weak pull-up";ie` is input enabled.We currently use the ESP-IDF routine
gpio_pin_reset()to reset a pin, which uniformly sets the pin to have its input and output disabled, with a pull-up. That does not always match the states given in the Pin Tables. "Input" vs "disabled" doesn't really matter, but the pulls do.Consider whether it's worth replicating the default hw state instead of just using
gpio_pin_reset().