Split crate to two about embedded-sdmmc-rs

[thejpster]

This crate is intended to allow you to read/write files on a FAT formatted SD card on your Rust Embedded device, as easily as using the SdFat Arduino library.

Can you list the advantages that splitting the crate would bring? As stated in the README, the primary goal is simplicity.

[no111u3]

It makes library clear: you can extend and update fat fs crate without hw depends and you can improve hw support without changes in fat fs. So crate is staied commonly easy for use - you can create default feature flag for use another hw support, or you can support hw extension as in serilalization in serde.

[thejpster]

OK, so if embedded-sdmmc was left as a simple, high-level crate, I'm fine with the FAT implementation being booted off into fat-rs or something, where it can be consumed by other applications / crates without all the SD stuff coming along too.

[thejpster]

Likewise the SD over SPI protocol implementation, and any future SD over SD Bus implementation - they can be in other crates, as long as this crate brings it all together is a nice easy to use format.

[elpiel]

I'd like to continue this discussion but instead of splitting it up, let's create a feature for enabling the fs for fat32 & fat16.

This will allow people to still depend on the crate for raw access, like for using it with e.g. littlefs2

[thejpster]

But if you don't use the FAT32 code, it all gets dead-code eliminated, doesn't it?