-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add correct pin availability for ESP32 Mini modules #4450
Conversation
Do you know if the ESP32 Mini needs a newer bootloader (esp-idf 4.4.x), or would it also work with the older esp-idf 3.5.x / arduino-esp32 1.0.6 framework? |
not sure about the bootloader, i tested it with the one here |
This is the "old framework" bootloader. If the module works with it, then the mini1 should work with our standard bootloader (we're still on the old framework due to "200kb for nothing" flash increase when using a newer framework....). |
if (gpio > 5 && gpio < 12) return false; //SPI flash pins | ||
} | ||
|
||
if (((strncmp_P(PSTR("ESP32-PICO"), ESP.getChipModel(), 10) == 0) || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the difference between "ESP32-PICO" and "ESP32-PICO-D2" which both also correspond to "ESP32-U4WDH"? the double checking is a bit confusing to me, can you add comments on why this is needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DedeHai I can explain partially; there are actually 3 PICO boards:
- ESP32-PICO-D4 (already supported)
- ESP32-PICO-V3-02 (our old framework does not support this type)
- ESP32-PICO-D2 (older frameworks wrongly identify the ESP32-U4WDH as PICO-D2)
All PICO boards, plus the U4WDH, have in common that gpio 16+17 are reserved for internal SPI flash. So blocking 16+17 for all these variants is correct.
FYI using bootloader from older versions (PIO 3.5 or earlier) is prone to flash corruption. There is a post/comment from @Jason2866 regarding that. You must only use DOUT flash mode if using that bootloader. My recommendation would be to finally switch to PIO platform 6.3.x for ESP32 and then update necesary GPIO reservations using chip names. |
That's funny, I'm actually running in the same problem but for the ESP32-PICO-V3-02 and need pin 7 available. Can I piggyback off this and we add an additional check in place for the V3 and V3-02 somehow? Only gpio pins 6,9,10,11 should be blocked, not 7,8.
|
@codeman256 I'm sorry but your board is another chip, and I don't see a way to easily "mee-too" your board on this PR. Please research how to identify your special board with @blazoncek I only wanted to explain why we still use an old framework, and for me a discussion of framework versions should be done separately. It has nothing to do with the esp32 mini1 module. @ladyada thanks for the changes, I'll test your code quickly in the next days and then we should be ready to merge. Maybe add some explaining comments as mentioned by @DedeHai. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK from my side - tested against ESP32-PICO-D4 to ensure that changes for ESP32-PICO-D2 are not affecting pin availability on other PICO modules.
thanks everyone! 👱♀️ |
Add correct pin availability for ESP32 Mini modules
Add correct pin availability for ESP32 Mini modules
ESP32 Mini modules (https://www.espressif.com/en/module/esp32-mini-1-en) from Espressif have /slightly/ different pins available due to having internal SPI flash on different pins than WROVER/WROOMs. this code checks if its part of the "ESP32-U4WDH" family (or, due to espressif/arduino-esp32#10683 may be called "ESP32-PICO-D2")