GPIO20 redundance (not be used)?
GPIO20 redundance (not be used)?
Why software can't use GPIO 20? I need this last pin in my product.
Re: GPIO20 redundance (not be used)?
You plan to expose the die and wire bond to it?
Re: GPIO20 redundance (not be used)?
I want to change one pin from LED RGB to 20 (before in 15) to use analog function in 15. Just blink LED wired in top layer pcb. IDF (gpio.h) doenst support gpio_num_20WiFive wrote:You plan to expose the die and wire bond to it?
- martinayotte
- Posts: 141
- Joined: Fri Nov 13, 2015 4:27 pm
Re: GPIO20 redundance (not be used)?
As WiFive mentioned, GPIO20 isn't exposed on QFN package ...
Re: GPIO20 redundance (not be used)?
martinayotte wrote:As WiFive mentioned, GPIO20 isn't exposed on QFN package ...
Why WROOM has this pin in package? just to fool me? LOL
One WROOM pin map in google, shows gpio 20 in wroom, but I looked another and say's "NC"...... Ok... But why gpio20 cannot be used? 6-11 is flash, 0/2/15/12(?) is boot, and 20?
Re: GPIO20 redundance (not be used)?
My guess is that internally in the MCU, there is the logical notion of the existence of additional GPIOs such as GPIO 20. Now imagine you are the designed of the physical package that is the ESP32. You are now told that you can only have a finite set of pins surrounding its edge. You map the ones that you know you absolutely must have. By the time you are done, you have found that you still have logical functions that, in theory, could be exposed ... but in reality you have no where to expose them to as you have used up all the pins on the package for other functions. What are you to do? Perhaps you could make a physically bigger package? Or, maybe, as in this case, you simply don't expose them to the outside of the package. They become "un-usable". Do you continue to document their logical existence? I think yes. If internally the logical pins have numbers that don't change, then you would again notice that some are "missing".
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
-
- Posts: 9746
- Joined: Thu Nov 26, 2015 4:08 am
Re: GPIO20 redundance (not be used)?
I think the pin was intended for the /CS line of a flash chip internal to the package. While it was never used as such, the PSRAM code does use it as an intermediate internal signal wire to delay a signal by one or two clock cycles.
Re: GPIO20 redundance (not be used)?
False https://github.com/espressif/esp-idf/co ... 6L521-L549ESP_Sprite wrote: the PSRAM code does use it as an intermediate internal signal wire to delay a signal by one or two clock cycles.
-
- Posts: 2
- Joined: Tue Oct 27, 2020 10:55 am
Re: GPIO20 redundance (not be used)?
Anyone using GPIO20 on ESP32-PICO-V3 SoC?
I keep getting these messages on idf v4.1:
E (317) gpio: IO20 is not a valid GPIO
E (317) gpio: gpio_set_level(215): GPIO output gpio_num error
I keep getting these messages on idf v4.1:
E (317) gpio: IO20 is not a valid GPIO
E (317) gpio: gpio_set_level(215): GPIO output gpio_num error
-
- Posts: 9746
- Joined: Thu Nov 26, 2015 4:08 am
Re: GPIO20 redundance (not be used)?
At least v4.1 does not take into account that ESP32 chips can have an usable GPIO20 yet. We'll see if we can add/backport this. For now, you may be able to make this change to make it work: in esp-idf/components/soc/soc/esp32/gpio_periph.c, search for 'IO_MUX_GPIO19_REG' and change the line under it from '0,'to 'IO_MUX_GPIO20_REG,'.
Who is online
Users browsing this forum: No registered users and 86 guests