PSRAM pins in ESP32 are now reserved only if needed

[Ellerbach]

Description

Removing reserved pins setup on ESP32 for SPI flash in the GPIO controller.

Rational: if SPI Flash is used, then some of the pins will be used by SPI anyway. Not all the pins will be used all the time. The design of some of the ESP32 board (like M5 Stick) uses pins 9 and 10 as they are not used in SPI Flash while the board has some. And those 2 pins are used for IR and Red led.

Motivation and Context

• Fixes ESP32 Pin 6 to 11 not released when SPI flash not present Home#813

How Has This Been Tested?

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Unit Tests (work on Unit Tests, has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[josesimoes]

I would try to make this a bit "smarter" and fool proof...
Meaning that the pin reservation should be there when the SPI flash it's present.

[Ellerbach]

Meaning that the pin reservation should be there when the SPI flash it's present.

I honestly don't see a point of reserving pins. If they are used by SPI flash, you won't anyway be able to open them, you'll get an error. So reserving pins that anyway will return an error if you want to open them doesn't feel logical.

[josesimoes]

Meaning that the pin reservation should be there when the SPI flash it's present.

I honestly don't see a point of reserving pins. If they are used by SPI flash, you won't anyway be able to open them, you'll get an error. So reserving pins that anyway will return an error if you want to open them doesn't feel logical.

🤔 I don't think that's the case... you can reassign the GPIO pins used by SPI flash without getting any exception. The result is that, inadvertently, a developer can screw the execution and make the CLR unusable. Having this check layer was one of the motivations for adding all this CPU pins layer code.

@AdrianSoundy your input here, please.

[AdrianSoundy]

Yes the problem is you don't get an error when pins are used that shouldn't be used. The reserved pins was to make sure that doesn't happen and developer gets a clear message the pin was used elsewhere.
For this case we just need to remove reserved pins for the flash pins if there is no PSRAM.

Could set a flag in memory.cpp or use :-
size_t spiramMaxSize = heap_caps_get_largest_free_block(MALLOC_CAP_8BIT | MALLOC_CAP_32BIT | MALLOC_CAP_SPIRAM);
To test if there is any psram memory available. There may also be an existing flag from bootloader code that can be used.

@josesimoes @Ellerbach

[josesimoes]

Precisely! That check should be all it takes to reserve those pins only when they are being used by PSRAM. 👍🏻

[Ellerbach]

Precisely! That check should be all it takes to reserve those pins only when they are being used by PSRAM. 👍🏻

I would argue that you always have the board pin availability. So as a developer, you can only pins that are physically accessible. If they are used by the psram, they are not physically accessible, so you 1. have no reason to use them, 2. if ever you want to use them, when trying to open them, you'll get an error.

So I really don't think that reserving them is less confusing than not reserving them as anyway, you'll get an error at the end of the day.

[Ellerbach]

So I think I finally got it. The detection of PSRAM is done at boot time, before this code is executed. So at this stage, it's about understanding if there is some. And if there is some reserve the pins otherwise, just skip!

[nfbot]

@Ellerbach there are issues with the code style on the source files.
A PR was submitted with the code style fixes. Please click #2023, review the changes if you want and merge it.

Make sure to follow the project code style. Check the details here on how it works and the tools required to help you with that.

[josesimoes]

@Ellerbach this is building OK now. Care to check if it's working on your test app?

[Ellerbach]

@Ellerbach this is building OK now. Care to check if it's working on your test app?

any already built nanoCLR I can just download and test? (otherwise, will pull and build locally)

[josesimoes]

@Ellerbach this is building OK now. Care to check if it's working on your test app?

any already built nanoCLR I can just download and test? (otherwise, will pull and build locally)

Sure! Just follow the URL to Azure Pipeline build and grab the bin from there. (nanoFramework it's developer friendly) 😉

[Ellerbach]

Works like a charm on en ESP32 PICO (M5 Stick) blinking the led on GPIO 10. Congratulations!