Document minimum delay requirement in the RTOS SPI Slave driver

[shuchitak]

Thank you for submitting an SDK documentation issue. Please provide as much information you can.

System information

• OS: RPi3
• xcore board xvf3600
• SDK version tag or commit SHA

Describe the documentation issue When using the SPI Slave driver with only one set of xfer buffers, the host cannot send a command unless the previous issued command has been processed in the application, otherwise the xfer buffers get overwritten while the command in being processed. I've added a sequence diagram detailing the delay requirement. This needs to be documented.

Other information

[shuchitak]

Copying @xmos-jmccarthy's comments -

63. This issue cannot be documented in the way that the diagram is asking. The reason for this is because anything after the driver ISR task notify is at the whims of the RTOS scheduler, and nondeterministic. The extent of documenting could be the same lines as what we have in the current legacy XC lib_spi, where we basically say it's app dependent and up to the user to measure.

My original plan was to mitigate this with the byte by byte spi slave. While it doesn't eliminate the problem, it allows for the creation of applications that can implement something were the slave has the potential to respond in a single CS transaction.

[shuchitak]

Copying @xmos-jmccarthy's comments - #63. This issue cannot be documented in the way that the diagram is asking. The reason for this is because anything after the driver ISR task notify is at the whims of the RTOS scheduler, and nondeterministic. The extent of documenting could be the same lines as what we have in the current legacy XC lib_spi, where we basically say it's app dependent and up to the user to measure.

My original plan was to mitigate this with the byte by byte spi slave. While it doesn't eliminate the problem, it allows for the creation of applications that can implement something were the slave has the potential to respond in a single CS transaction.

I agree that what the diagram is asking for cannot be documented and thinking more about it, isn't a reasonable thing to ask documentation for since the response time is application dependant. I think what I want documented is the maximum speed at which the spi clock can run without any signal integrity issues on the MISO or MOSI, so no bits being dropped on either. If we do go with the good buffer - default buffer type of scheme, the diagram for which I've copied below, we've decoupled the HIL thread from the app so essentially any limitation we document is our IO interface limitation and not an application dependant limitation.

[shuchitak]

I agree, that there isn't a good way in the above scheme to profile the response time for a command. The best we could do is profile the time taken in ctx->xfer_done() and that's closest to the command processing time in the application.

[xmos-jmccarthy]

Closed by https://github.com/xmos/xcore_sdk/pull/537