If we want to release `embedded-io` 1.0 and the adapters live there, we can't make any
breaking changes to them after release. Putting them in a separate crate
allows doing breaking changes without breaking everyone using the IO traits.
463: embedded-hal: digital: add #[inline] hints for PinState functions r=Dirbaio a=luojia65
Add inline hints for:
- `<PinState as Not>::not`
- `<PinState as From<bool>>::from`
- `<bool as From<PinState>>::from`
Those hints would allow further optimizations if PinState structure functions is used on embedded-hal projects.
Co-authored-by: Luo Jia / Zhouqi Jiang <luojia@hust.edu.cn>
Add inline hints for:
- <PinState as Not>::not
- <PinState as From<bool>>::from
- <bool as From<PinState>>::from
Those hints would allow further optimizations if PinState structure functions is used on embedded-hal projects.
Signed-off-by: Zhouqi Jiang <luojia@hust.edu.cn>
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 <dirbaio@dirbaio.net>
458: bus: Add a doc example for i2c::RefCellDevice r=Dirbaio a=tomgilligan
`embedded-hal-bus` is turning out to be very useful for something I'm working on. It wasn't too hard to work out how to use it but it feels like an example would still be helpful here. Not sure:
- is this the best place to put such an example?
- how much of the example should be hidden with `#`?
Co-authored-by: Thomas Gilligan <thomas.gilligan@icloud.com>
448: Misc doc fixes. r=eldruin a=Dirbaio
- Switch from GAT to AFIT has already happened.
- We're no longer planning to integrate EHA into EH
- Fix all broken links.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
