I took a look at https://github.com/espressif/esp-idf/blob/master/examples/storage/sd_card/sdmmc/README.md and it appears that we are currently hardcoding the MMC pins for the original ESP32 pins which cannot be configured.

As mentioned other ESP32 variants use the GPIO matrix for the SDMMC peripheral so we can't get away with simply using pre-processor directives here to set default values based on the ESP32 variant.

Here's two spots where we're hardcoding the pins:

https://github.com/nanoframework/nf-interpreter/blob/453bf3dee0be63e5538323f1116ca88d3e37e191/targets/ESP32/_nanoCLR/System.IO.FileSystem/nf_sys_io_filesystem_nanoFramework_System_IO_FileSystem_SDCard.cpp#L28
https://github.com/nanoframework/nf-interpreter/blob/453bf3dee0be63e5538323f1116ca88d3e37e191/targets/ESP32/_common/Target_Windows_Storage.c#L107

Additionally it looks like we should be setting the pins and width on the slot_config as shown in the example: https://github.com/espressif/esp-idf/blob/d4cd437ede613fffacc06ac6d6c93a083829022f/examples/storage/sd_card/sdmmc/main/sd_card_example_main.c#L149

As @josesimoes mentioned in #1475 we don't want to expose platform specific concerns in "general" classes so we'll need to think this through. That being said I'm only seeing the SDCard functionality currently implemented on the ESP32 platform so I don't have any reference as to how other platforms.

My initial thought is that a new MMC value should be added to nanoFramework.Hardware.Esp32.DeviceTypes with new functions (MMC1_CLOCK, MMC1_COMMAND, MMC1_D0, MMC1_D1, MMC1_D2, MMC1_D3) added to nanoFramework.Hardware.Esp32.DeviceFunction. The hardcoded values would be replaced with the appropriate NativeGetPinFunction() calls.

This requires some thinking about the feature design. So far we've been trying (and succedded) in NOT having platform specific stuff in the "general" class libraries. The platform specifics are all in the various nanoFramework.NNNN.
Worth give it some though before we decide how to implement this.

My initial thought is that a new MMC value should be added to nanoFramework.Hardware.Esp32.DeviceTypes with new functions (MMC1_CLOCK, MMC1_COMMAND, MMC1_D0, MMC1_D1, MMC1_D2, MMC1_D3) added to nanoFramework.Hardware.Esp32.DeviceFunction. The hardcoded values would be replaced with the appropriate NativeGetPinFunction() calls.

I think this plan is great

Didn't even realise S3 could use alternate pins. Think thats the way to go as it aligns with what we are doing for other pins.

@AdrianSoundy can you please follow up with this one?

@josesimoes No problem

@AdrianSoundy We are really looking forward to the GPIO pin configuration feature. Thanks

@AdrianSoundy We are really looking forward to the GPIO pin configuration feature. Thanks

Currently testing so should be available in next few days. @dkovyazin