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.

Not as such… but I have some hardware I’m planning that makes heavy use of SPI on the RPi. Target application is Linux, but it would be fun (if somewhat pointless) if it was usable in RISC OS too.

After looking at the OMAP & BCM TRMs, I’m thinking the SPI API should roughly be as follows:

• Each SPI controller will be a seperate HAL device
• Each SPI controller has the following capabilities which can be read:
  • Number of chip select lines
  • Mask of supported word lengths (32 bits for whether word lengths of 1-32 bits are supported)
  • Min & max clock speed, Hz
  • Supported master mode transfer modes: Full duplex, half duplex, half duplex 1 wire
  • Whether the chip select line can be kept enabled between transfers
  • Whether a start bit is supported (1 extra bit on the start of each word, same value for entire transfer)
• Each master mode SPI transfer has the following properties:
  • Chip select to enable
  • SPI word length (bits)
  • Clock speed, Hz
  • Transfer length (words)
  • RX & TX buffer pointers. Specify null for one of them if RX only or TX only required.
  • Buffer word length (8, 16, 32 bits) – e.g. with a 12 bit SPI word length you can indicate whether the buffer entries are 16 bits or 32 bits. Data is packed into the bottom bits of each word. Could be extended to support tightly packed data (e.g. 12 bit buffer word length) in future.
  • Transfer mode: Full duplex, half duplex, half duplex 1 wire
  • Whether to keep the chip select enabled at the end of the transfer
  • Clock polarity (active high/low)
  • RX sampling edge (clock rising/falling)
  • TX sampling edge (clock rising/falling)
  • SPI word bit order (MSB or LSB first). Doesn’t affect alignment of data within the buffer.
  • Delay between chip select enable and first clock edge (in 0.5 clock units)
  • Delay between last clock edge and chip select release (in 0.5 clock units, ignored if chip select being kept enabled)
  • Idle time after chip select release (in 0.5 clock units, ignored if chip select being kept enabled)
  • Whether to delay RX sampling by 1 clock (BCM “post-input mode”)
  • Start bit enable + value
• 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.

SPI interface should be enabled too, Although that might have to be done before starting the SPI module?

DOUT Hold time if needed?

It has been a while since this thread was updated but I just wondered whether there was any behind-the-scenes progress on this topic please.

Not quite to the ambitions earlier in the thread and limited to the Raspberry Pi, I wrote a module to communicate to SPI chips. Not sure if this is any use but feel free to us: PiSPI

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 ROOL CVS.
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.

Are you/could you base it on Bill Antonia’s work?
(Link posted 21st July)

I hate to see duplicated effort!

The iMx6 HAL is the HAL I’m doing this with, though the driver will be within the main ROOL CVS.

I should like to interface a PaPiRus (electronic ink display) to a Pi Zero. Do we have a SPI driver for the Pi yet please?

Is there a solution to use SPI on Omap3 like Pandora or Tochbook?