Add SdCardDevice trait #185
Conversation
src/sdcard/sd_card_device.rs
Outdated
| Cs, | ||
| } | ||
|
|
||
| impl<BUS, CS> SdCardDevice for (&RefCell<BUS>, CS) |
There was a problem hiding this comment.
I couldn't add an impl for (BUS, CS) because it conflicted with this one.
|
Seems reasonable enough, but I'd like to see some current users of embedded-sdmmc-rs port over to this style to check it's usable in practice. |
|
There's also some overlap with #170, which is about SD Cards in general (i.e. using SD Card Host Controllers with the 4-bit bus) rather than this which is about SPI bus based SD Cards specifically. |
Co-authored-by: Jonathan 'theJPster' Pallant <[email protected]>
I'll also do some dogfooding by using it in my project. I'm mostly interested in the async API but I think I can do some tests with the block API.
How do you want to move forward with this? There hasn't been any recent activity on that PR. I think it makes sense to first fix the dummy byte issue. |
|
If we're going to abstract the SD card transport it makes sense to do it in a way that both fixes the SPI issue and allows the use of SD Host Controllers. I also have a mild preference for custom types over implementing traits on tuples. I think it makes it clearer what's going on. Maybe something like:
|
|
Personally I don't have the need for a generic |
|
|
||
| - `embedded-hal-bus-03`: adds support for `embedded-hal-bus::spi::ExclusiveDevice`. This is probably the easiest way to use this crate when the SD card is the only device on the bus. | ||
| - `embassy-sync-06`: adds support for using a blocking mutex from the `embassy-sync` crate. This allows sharing the bus between multiple tasks. | ||
|
|
||
| ```rust | ||
| use embedded_sdmmc::{SdCard, VolumeManager, Mode, VolumeIdx}; | ||
| // Build an SD Card interface out of an SPI device, a chip-select pin and the delay object |
There was a problem hiding this comment.
This example needs to be kept in sync with the copy in readme-test.
|
Ok, fair enough. |
Closes #184.
This only adds a blocking trait. Once #176 is merged I can rebase and add the async version. Or this can be merged first and the other PR can add the async version. Either is fine with me.