Add wrapper for SD/SDIO/SDMMC driver and vFS

[AlixANNERAUD]

Hi,
According to issue #420 .
Am I heading in the right direction ?

[Vollbrecht]

Thanks for the PR!

Am I heading in the right direction ?

You did a great start we surly will get there!

For the SDMMC support we need to introduce some gated compilation. To my understanding, currently - SDMMC host hardware is only present in esp32 / esp32s3. Other devices such as a esp32c6 uses the SDIO api. The esp-idf docu is a bit confusing on this point. For a first hind you can look at the failed CI runs, that complain that for the specific risc targets the API is not there.

We could feature gate by esp variants directly or use some of the down handed information from esp-idf like SOC_SDMMC_HOST_SUPPORTED flag.

If you first only want to work on the sdmmc part is fine, but it would be extra nice if you could use the sdspi_host api as a fallback for targets that does not support sdmmc. Edit: you already provide both apis ❤️ so its just a matter of gating the sdmmc variant correctly. In concrete i talk about this sdmmc api vs this sdspi api

In either case we would gate the sdmmc api in sd module part you created, so we dont brake targets that dosn't have it.

[Vollbrecht]

can you have a look at the clippy output from the CI runs. If you have a particular question around something feel free to ask !

[AlixANNERAUD]

can you have a look at the clippy output from the CI runs. If you have a particular question around something feel free to ask !

Well, I'm having trouble finding documentation on how the cfg flags of target capabilities are defined. It seems they are exported from ESP IDF #define macros, but I can't figure out which one corresponds to the Rust equivalent of SOC_SDMMC_HOST_SUPPORTED (like esp_idf_bt_classic_enabled is the equivalent of SOC_BT_CLASSIC_SUPPORTED). I'm currently using esp_idf_sdmmc_host_enabled, but I'm not convinced it's the correct one.

[AlixANNERAUD]

What is going on with the CI ? There's an issue with ldproxy installation.

[Vollbrecht]

What is going on with the CI ? There's an issue with ldproxy installation.

wired unrelated install error / i restarted the workflow

[Vollbrecht]

can you have a look at the clippy output from the CI runs. If you have a particular question around something feel free to ask !

Well, I'm having trouble finding documentation on how the cfg flags of target capabilities are defined. It seems they are exported from ESP IDF #define macros, but I can't figure out which one corresponds to the Rust equivalent of SOC_SDMMC_HOST_SUPPORTED (like esp_idf_bt_classic_enabled is the equivalent of SOC_BT_CLASSIC_SUPPORTED). I'm currently using esp_idf_sdmmc_host_enabled, but I'm not convinced it's the correct one.

The correct one should be something like esp_idf_soc_sdmmc_host_supported . You can always double check with running cargo rustc -- --print cfg. This will print out all flags that are available on your current used target.

Regarding the other CI error with respect to "use alloc::ffi::CString;" : We also use alloc flags for stuff that uses heap allocation - this is done so that the hal can technically build on no_std. Its mostly used as a dev helper to mark things explicitly for us where heap allocs occure on our site. You would also need gates here.

[AlixANNERAUD]

Has the binding between rust's std::fs and esp-idf vfs been done? @ivmarkov @Vollbrecht

[ivmarkov]

@AlixANNERAUD Not yet. Sorry for being slow with my feedback. Will return some more today.

[ivmarkov]

Sorry for the delay! Holidays over here. :)

[ivmarkov]

1 - Create a submodule pub mod config and move DelayPhase in there
2 - #[derive(Debug, Default, Copy, Clone, Eq, PartialEq)] and pick which item in the enum should be the default, if there is a meaningful default. Otherwise do not derive Debug
3 - as isize? Why?
4 - If you look at other drivers, we often implement e.g. From<sdmmc_delay_phase_t> for DelayPhase.

[AlixANNERAUD]

2. Ok but why deriving Default ? It doesn't makes sense here ?
3. Since Rust enums appear to be encoded as isize while sdmmc_delay_phase_t is a c_uint, casting becomes necessary.

[ivmarkov]

@AlixANNERAUD I'll merge this shortly, but might do a round of final renames/changes post commit - hope you don't mind. For one, this code is not #[cfg()]-ed yet on the VFS and FAT components being enabled, so it will fail to compile when ESP IDF is compiled without support for VFS.

[ivmarkov]

@AlixANNERAUD I'll merge this shortly, but might do a round of final renames/changes post commit - hope you don't mind. For one, this code is not #[cfg()]-ed yet on the VFS and FAT components being enabled, so it will fail to compile when ESP IDF is compiled without support for VFS.

[AlixANNERAUD]

@AlixANNERAUD I'll merge this shortly, but might do a round of final renames/changes post commit - hope you don't mind. For one, this code is not #[cfg()]-ed yet on the VFS and FAT components being enabled, so it will fail to compile when ESP IDF is compiled without support for VFS.

Thank you very much for your help, it's really kind of you to have taken the time to assist me. I've added the missing cfg for vfs/fat.

[Vollbrecht]

@AlixANNERAUD I'll merge this shortly, but might do a round of final renames/changes post commit - hope you don't mind. For one, this code is not #[cfg()]-ed yet on the VFS and FAT components being enabled, so it will fail to compile when ESP IDF is compiled without support for VFS.

Thank you very much for your help, it's really kind of you to have taken the time to assist me. I've added the missing cfg for vfs/fat.

Thanks for pushing the PR through!

[niuhuan]

my tf card init faild on esp32-s3 use this example .

#439