Conformity of SPI implementation with embedded_hal::spi::SpiBus trait

[dmholtz]

Structs implementing the SpiBus trait from embedded_hal should be unaware of the chip select (CS) pin in order to allow bus sharing and implement additional traits such as SpiDevice, see embedded_hal docs.

Thus, I believe that the current design of the Spi struct does not provide a appropriate base for implementing th SpiBus trait, as it is tightly coupled to the type of the CS pin.

[Rahix]

I think you misunderstood why our Spi struct deals with a CS pin. It does not actually make use of the CS pin in any way - in fact the Spi::new constructor passes back the CS pin to the user right away. This odd behavior is needed because we must enforce that the CS pin is always an output pin - if it isn't, the hardware SPI peripheral does not behave correctly.

Whether you later use the wrapped CS pin as an actual CS or for different purposes is up to you. You can also use any other pin as a CS, or none at all. This matches the expectations of embedded-hal.

This hardware restriction was originally discussed in #27.