embedded-hal
embedded-hal copied to clipboard
sdmmc: add HAL traits for SD/MMC peripherals
Adds the initial implementation of the embedded-hal SD/MMC traits.
Includes types and traits useful for handling SD/MMC peripherals.
Did you get a chance to read https://github.com/rust-embedded/embedded-hal/blob/master/docs/how-to-add-a-new-trait.md?
Not yet, I missed it before opening the PR. Going over it now.
This PR is missing some background work, and demonstration that it can be implemented on at least two targets.
I'm currently implementing it on one platform that uses a DesignWare MMC controller. Should the second platform use a different controller type to meet the requirements?
Finally, is this worth abstracting over in eh?
I think so, but I'm open to differing opinions. SD/MMC controllers are common on SBC boards, and some other microcontrollers. Are there any examples of SD/MMC drivers that implement an e-h block device trait for a SD/MMC peripheral in a non-SPI mode?
the fact you're trying to cover SPI commands here too
That's not exactly the intention. How I imagine it working is that users will implement the SPI trait(s) for the controller/peripheral, and use those methods to implement the Mmc traits. I basically just want the Mmc traits to be generic enough to cover that use-case.
This PR might be better as a stand alone crate, at least initially, to demonstrate its viability.
I am currently working on the traits in the jh71xx-hal crate, and the driver crate that builds on that work in sdmmc-driver.
Perhaps a more worthwhile abstraction for eh would be a block device trait?
The BlockDevice trait appears to be missing the critical init, set_ios, and setup_bus functions that abstract over the low-level register access necessary to properly perform device initialization. I don't think BlockDevice is going to work without modification to provide HAL traits that drivers can target for SD/MMC peripherals. Happy to be shown otherwise.
After discussion in today's meeting, I've created the embedded-hal-sdmmc crate.
I opened an upstreaming issue in rust-embedded-community/meta#35.
Not sure whether its better to leave this PR open for the eventual future upstreaming effort, or close until ready to upstream. Thoughts?