SPI as an RPC link between boards

Home / Uncategorized / SPI as an RPC link between boards

Question:
I want to implement an RPC(remote procedure call) mechanism based on SPI between two ARM SoCs. The two systems which are Cortex A9 and ARM11 respectively run Linux as OS. Currently we use UART as the sole communicating channel for RPC and file transferring (and things like firmware updating).

I am trying to use SPI as an alternative data link for better throughput. So far a nearly working prototype is ready though some flow control issues are still haunting, as only one GPIO pin of the board seems not sufficient for reliable flow control. I use the spidev driver for the master and have written a Linux device driver for the slave. An additional userspace program on top of spidev are required for the protocol handling at the master as well.

My question is, is there any prior art about this usage of SPI? I can find some hardware solutions on the internet like SPI-to-Ethernet modules, but have no idea about the protocol design under the hood.

EDIT: About the flow control issues: The current design of the protocol consists of two commands which are READ and WRITE. The two commands consist of four (half-duplex) transfers. For example,

WRITE:WRITE-SETUP (To slave)
WRITE-SETUP-STATUS (From slave)
WRITE-DATA (To slave)
WRITE-DATA-STATUS (From slave)

READ:READ-SETUP (To slave)
READ-SETUP-STATUS (From slave)
READ-DATA (From slave)
READ-DATA-STATUS (To slave)

I have to inform the slave with a "SETUP" phase because the DMA of the slave needs a known size prior to a transfer. I have to use DMA otherwise it’s difficult to reach the throughput that SPI allows (4.8MHz).

A GPIO pin (input for the master, output for the slave) is dedicated for indicating the availability of the DMA channel. That is, the DMA transfer must be set up before the master can initiate any transfer. The tricky thing is, when the slave assert the pin to indicate that the DMA is ready, the slave has to de-assert pin soon. Otherwise the next transfer would see the asserted state of the last transfer.

Currently, the slave de-assert the pin when the DMA completion handler is called. However, there is always a time gap that the DMA completion is called too late that is later than the next transfer that is attempted by the master! That’s why I have to add the delay after each transfer issued by the master.


Answer:

Read more

Leave a Reply

Your email address will not be published. Required fields are marked *