⏳ add helper class for ESP32 pins

[Dweaver309]

Description

Motivation and Context

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)

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.

Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>

[nfbot]

Hi @Dweaver309,

I'm nanoFramework bot.
Thank you for your contribution!

A human will be reviewing it shortly. 😉

[CLAassistant]

All committers have signed the CLA.

[AdrianSoundy]

I am not sure what you are trying to achieve with this class. Its only useful if you only ever just use the default mapping. Then i am not sure where you would use it.
All you are doing here is listing what the default pins are currently set for the ESP32 on boot.
There is no fixed assignment of pins to a function with ESP32 which is unlike the STM32 devices which have fixed functions assigned to pins and then you select which function to use on a pin.

For example you can assign whatever pins you like for most devices(e.g SPI1, SPI2 etc) using Hardware.Esp32.Configuration.SetPinFunction(Int32, DeviceFunction) which changes the mapping for when the device is referenced. The SPI1 pins are where they are because the Wrover board display uses those pins. Another board may use different pins for SPI bus.

I think the ADC pins are the exception to this.

[Dweaver309]

I wrote it to help me remember the default pins. Jose thought it would be useful. If you feel it is not needed I would agree with you. Change the code however you want or don't include it . Thanks for the feedback

…

On Tue, Apr 23, 2019 at 7:10 AM Adrian Soundy ***@***.***> wrote: ***@***.**** commented on this pull request. I am not sure what you are trying to achieve with this class. Its only useful if you only ever just use the default mapping. Then i am not sure where you would use it. All you are doing here is listing what the default pins are currently set for the ESP32 on boot. There is no fixed assignment of pins to a function with ESP32 which is unlike the STM32 devices which have fixed functions assigned to pins and then you select which function to use on a pin. For example you can assign whatever pins you like for most devices(e.g SPI1, SPI2 etc) using Hardware.Esp32.Configuration.SetPinFunction(Int32, DeviceFunction) which changes the mapping for when the device is referenced. The SPI1 pins are where they are because the Wrover board display uses those pins. Another board may use different pins for SPI bus. I think the ADC pins are the exception to this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1288 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD5AFHAWAV7MUTRHCO5CG6TPR34EDANCNFSM4HHJYLPQ> .

[josesimoes]

@AdrianSoundy I was the one suggesting @Dweaver309 to add this, following what is there in STM32.

I understand that EPS32 pins can be configured on-the-fly. The same happens (with less flexibility) on STM32. The point here is to have a mapping with more friendly names for the pins when one is coding.

Equivalent helper classes exist for STM32 and they are useful, specially for developers that are jumping in.

Considering the above, do you have any suggestions on making this more "developer friendly"? 😉

[josesimoes]

@Dweaver309 we are giving this some thought internally and thinking on how this pin remapping can be improved even further.

[Dweaver309]

Thanks for improvements in advance!

…

On Wed, Apr 24, 2019 at 7:26 AM José Simões ***@***.***> wrote: @Dweaver309 <https://github.com/Dweaver309> we are giving this some thought internally and thinking on how this pin remapping can be improved even further. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1288 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD5AFHE6C7PVMOR7API2KH3PSBGWLANCNFSM4HHJYLPQ> .

[AdrianSoundy]

Started adding this to Hardware.Esp32

[AdrianSoundy]

I have been looking at this but there is a problem.
The pin assignments are not fixed so you can't have a simple constant for the definition of say a SPI1.Mosi pin which means you end up with a function for every pin as it has to get the current pin assignment. This will add a lot of mostly unused code to the assembly.

So what i have decided to just limit the change to a new function :-
public static int GetFunctionPin(DeviceFunction function)

This will return the current pin assignment for any device pin which was missing from the assembly.
Also i have change it to directly be able to set the mapping instead of using the alternate function on a gpio pin.

I will extend it to include ADC which is currently missing, but these are fixed pins.

[josesimoes]

Got you. If you think that's the best way to tackle this go for it! 👍

[AdrianSoundy]

This can be closed once Esp32 hardware update #1392 is closed and the update to
lib-nanoFramework.Hardware.Esp32
@Dweaver309