Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
461: spi: remove write-only and read-only traits. r=Dirbaio a=Dirbaio 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. - write-only SPI: for SPI displays you don't want to read from, or to abuse it to bitbang stuff like ws2812b, - read-only SPI: some ADCs that can't be configured at all, you just clock out bits. Or even weirder abuses, like to build a logic analyzer 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 not `SpiBus`. 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 full `SpiBus`, 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. Co-authored-by: Dario Nieuwenhuis <[email protected]>
- Loading branch information