SPI

Anyone working on, or thinking of working on, an SPI bus/manager API? It’s something I’ll be needing to sort out in the next few months for the TouchBook & Pandora touchscreen, and Pandora LCD brightness/contrast/gamma.

There also needs to be a configuration/initialisation call to allow the following to be specified:

Polarity of chip select lines

Potentially some of the per-transfer properties? (the other clock polarities, clock rate, delays, etc.?)

In terms of the RISC OS side of things, there’ll be an SPI manager module with SWIs available for enumerating busses, configuring chip selects, performing transfers, etc. (using parameters similar/identical to those used with the HAL calls). There’ll be the option for whether transfers should be completed in a blocking or non-blocking manner.

Handling of invalid configurations: I’m thinking that for clock rates, delay values, etc. the driver should just silently set the out-of-range value to the nearest supported value, being sensible where appropriate (e.g. clock rate can only be rounded down, delay values can only be rounded up). For completely unsupported modes (start bit, invalid RX+TX mode, etc.) an error will be returned.

Can anyone spot anything that I’ve missed? (Apart from slave mode, which I’m ignoring for the moment – unless someone needs it for something?)

Handling of invalid configurations: I’m thinking that for clock rates, delay values, etc. the driver should just silently set the out-of-range value to the nearest supported value, being sensible where appropriate (e.g. clock rate can only be rounded down, delay values can only be rounded up).

I think that will be a friendlier way to handle things. With SPI, what concerns me is something probably out of the remit of RISC OS to do much about:

There’s no concept of “clock stretching”, so the slave apparently cannot signal to the host that the communication needs to be delayed (though, on the other hand, the RPi’s IIC timeout is too damn short for some MCU activities).

There doesn’t appear to be a formal ack protocol, so the master could be talking to a phantom and not even know it.

Error checking protocol?

Related to the above, it appears as if SPI is prone to noise transients which can mess with communications.

It seems there are a billion different types of SPI with no formal “definition” (one could say that JTAG behaves in a manner similar to SPI). I’m not so much worried about the RISC OS API, which – by the way – looks about right, as I am worried about the poor sod that needs to communicate with SPI! ;-)

I think there’s a bit of extra functionality the SPI manager will need – the ability to gain exclusive access to the bus for a series of operations. Initially I was thinking the “keep chip select enabled at end of transfer” flag would be all that would be necessary for this, but that wouldn’t allow you to keep exclusive access if the chip you’re talking to needs the chip select to disable between transfers.

I have now started work on a SPIDriver module. An initial HALDevice for spi has been added to kernel.HDR, though this will be subject to change as further HAL calls are created. I am mindful of Jeffrey’s post above, but would appreciate any further suggestions/requests. The iMx6 HAL is the HAL I’m doing this with, though the driver will be within the main ROOLCVS.
Thanks

One feature I’ll be adding is the capability to request/reserve additional Chip select lines from a subset of ‘available’ GPIO lines. Logic behind this is iMx6 SPIO has 2 built in CS lines. The connector bringing this out also has 8 GPIO lines, any or all of which could usefully be incorporated as CS lines.