SPI CS Traits / Implementations

[ryankurte]

At the moment we aren't super explicit about management of the chip select pin for SPI transactions, which means drivers have to either manage these themselves or make big assumptions about the underlying SPI implementation.

With #178 we have the ability to execute multiple operations in a single transaction which brings this to the forefront. (@jonas-schievink this is why I didn't call them Transaction because the whole thing is a bus transaction, whoops.)

To mitigate this, I'm proposing the addition of a ChipSelect marker trait for SPI devices that manage SPI themselves, As well as a wrapper object that takes an SPI object GPIO output and implements ChipSelect to simplify the use of devices with manual CS management.

A downside of this is that we now need to return distinct types where ChipSelect or !ChipSelect in cases where either is possible, for example, the linux embedded hal driver may have CS managed automatically or be used with manual CS management. This could be mitigated by splitting the constructors for no_cs and with_cs versions, however, will be required for many SPI devices.

[thejpster]

How would it work with multiple chip selects? Would you have multiple wrappers sharing the same SPI driver object (in some kind of Cell wrapper) each with a unique GPIO?

[ryankurte]

Yeah good question, depends on the implementation (Linux you could just create multiple devices /dev/spidev0.N and leave them to manage CS themselves), but in the more embedded case i think shared-bus could be extended to do the job as you describe.

This is not quite as trivial as using a shared-bus object in the proposed wrapper as you really need to take ownership of the bus before asserting CS, so shared-bus or similar would need to be extended with support for all the CS stuff.

There's also a related issue in shared-bus Rahix/shared-bus#8 discussing this exact problem.