Add support for multiple xfer buffers in the RTOS SPI Slave driver

[shuchitak]

Thank you for submitting an SDK feature request. Please provide as much information you can.

Describe the feature
I'm using the RTOS SPI slave driver to implement control over SPI Slave for the xvf3800. I'm using the xcore_sdk device_control service as well to which I've added support for SPI Slave transport (#55). The design I'm aiming for is this:

• If the command cannot be accepted in the device, since the internal queues are full, the tx_buf for the command's xfer contains a special sequence of bytes indicating COMMAND_IGNORED_IN_DEVICE.
• Otherwise, the command is accepted in the device and the tx_buf for the command's xfer contains the response for the last command sent by the host that was accepted in the device.

This will require switching xfer buffers between the good buffer (command accepted) and the dummy buffer (command ignored) in the driver. I want to understand if this is possible? Or else, if there's another design that could help me meet my 2 requirements listed above.

Will this change any current APIs? How?

Who will benefit with this feature?

Any Other info

[shuchitak]

I've added a sequence diagram for the 2 buffers proposal

[shuchitak]

Copying @xmos-jmccarthy's comments describing another proposed driver implementation where the command would be responded within a since CS assert.
In my bytes by byte driver (which is unfortunately much slower data rate right now), what I think you could do is all of this in a single CS assertion.

The main benefit of this implementation will be the ability to respond on a byte by byte basis.

I am imagining implementing something more like the I2C protocol.

To do a write command, the master would:

CS Assert

MOSI the data bytes.

The master would then continue to clock 0's until it sees a magic number on MISO, this magic number would essentially be like the I2C ACK.

During the above the slave would get the command bytes sent, and output 0's until the application had processed and given the driver the buffer to write out.

The spi slave bytes callback, would probably have some callback, like, if I did 50 clocks and the app hasn't responded send a timeout magic byte to the HIL and alert the app we gave up on this transaction.

Basically, you implement pseudo clock stretching by having the master just continue clocking until it sees the TIMEOUT or ACK magic bytes.

This shoudl also allow reusing a lot of the I2C logic with the SPI slave

[xmos-jmccarthy]

Closed by xmos/xcore_iot#537