As discussed in #99, split Spidev into SpidevDevice and SpidevBus, each implementing the respective embedded-hal trait.
Compared to the original plan, it seems easier to just let the CS pin be driven normally, and say users can configure SPI_NO_CS if required. I couldn't spot any good way for us to change the configuration to just set this flag without overriding whatever existing mode configuration the user had, and since it should always be a dummy pin anyway, it shouldn't usually matter if it gets toggled.
In the end therefore there's no change to the implementations, just splitting which struct each trait is implemented for (and duplicating the various helper impls).
As discussed in #99, split
Spidev
intoSpidevDevice
andSpidevBus
, each implementing the respective embedded-hal trait.Compared to the original plan, it seems easier to just let the CS pin be driven normally, and say users can configure SPI_NO_CS if required. I couldn't spot any good way for us to change the configuration to just set this flag without overriding whatever existing mode configuration the user had, and since it should always be a dummy pin anyway, it shouldn't usually matter if it gets toggled.
In the end therefore there's no change to the implementations, just splitting which struct each trait is implemented for (and duplicating the various helper impls).