-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spi: remove write-only and read-only traits. #461
Conversation
c87f597
to
1567f25
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
defs a fan of simplification, seems good to me. other @rust-embedded/hal folks?
spi.rs https://github.com/esp-rs/esp-idf-hal/blob/master/src/spi.rs#L1337 well i can live with reducing that line count 😺 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the assessment, thank you!
let's merge then! :D bors r+ |
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page.
|
When introducing the Bus/Device split in #351, I kept the ability to represent "read-only" and "write-only" buses, with separate
SpiBusRead
,SpiBusWrite
buses. This didn't have much discussion, as it was the logical consequence of keeping the separation in the already existing traits (Read
,Write
,Transfer
, ...).Later, in #443, when switching from the closure-based API to the operation-slice-based API, this required adding
SpiDeviceRead
,SpiDeviceWrite
as well, because you can no longer put a bound on the underlying bus with the new API.This means we now have seven traits, which we can reduce to two if we drop the distinction. So, is the distinction worth it?
I've always been on the fence about it, now I'm sort of leaning towards no.
First, using write-only or read-only SPI is rare.
Second, for it to be useful HALs have to track "read-onlyness / write-onlyness" in the type signature, so a read-only SPI really only implements
SpiBusRead
and notSpiBus
. HALs already have enough generics. For example, Embassy HALs don't implement the distinction (you can create MOSI-only or MISO-only SPIs, but they all impl the fullSpiBus
, because I didn't want to make the types carry pin information).Third, it makes the API easier to use. Simpler, users only have to import one trait, docs have all the methods in one place. Much less boilerplate to impl the traits (look at how shorter
embedded-hal-bus
gets!).So I think we should remove them.