Raspberry pi as a SPI slave

https://github.com/anetczuk/SpiSlave

https://offis.github.io/raspi-directhw/group__spisl.html

I've used 2 ESP32-S3's as slave SPI devices (could have supported more), with the second core dedicated to comms with a master (Started with rPi4, moved to another ESP32-S3, may move the STM32 as I also need LoRa communications.  My findings were using any of these boards, I had to optomise the comms using the multi-core design to allow high speed communications on the SPi bus.  This did require locking to insure writes/memory updates were protected.  Initially my alternate comms was BT 5 (20-30 receptions/sec), but looking to longer distance and LoRa is next attempt.  I could not find any completed code, and had to "roll my own".  Getting the shared memory comms between cores was the real key to stability.  My SPI devices were parallel LCD displays, ideally I could have more than 2.

Looks like these are the only options available, as in software driven spi slave mode.

Looking at the Broadcom BCM2711 data sheet, it shows that only SPI master is the only hardware driver provided.

SPI slave is just an unusual interface configuration for such a system, so the options will have limitations (which you might or might not be able to live with), as you can see from the links Doug found for you. Just curious, what's the actual application?

If you're looking for high-speed ways of interfacing, then there are interfaces like PCIe, or more longer-distant options like Ethernet or WiFi, very convenient since every Pi has a network interface of some sort.

If you don't care for high throughout then there's UART. One SBC that could certainly do SPI slave (and do it with high performance) is BeagleBone Black with it's special hardware called PRU. But Pi doesn't have that.

If the Raspberry PI cannot easily be configured as a SPI slave module, you might be able to flip the scenario around and the Raspberry PIs repeatedly poll the master with a request for information, so that they can learn what the master wants and then do that.  I have had some success in this approach in the past (not related to the Raspberry Pi).

I believe the hardware supports SPI Slave, as the SPI Slave DMA DREQ is documented on the BCM2711 data sheet: https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf 
The older BCM2835 goes into more details: https://datasheets.raspberrypi.com/bcm2835/bcm2835-peripherals.pdf

I suggest trying the SPI slave registers on bare metal, with DMA. The closest starting point I'm aware of is the DMA driven SPIMaster in the Circle Bare Metal framework: https://github.com/rsta2/circle/blob/master/lib/spimasterdma.cpp  and to look at https://github.com/torvalds/linux/blob/23956900041d968f9ad0f30db6dede4daccd7aa9/drivers/spi/spi-bcm2835.c and finally https://github.com/hendric-git/bsc-slave

Interesting find. It's all quite ambiguous in the docs, the BCM2711 doesn't list it in the overview, but mentions some peripherals are missing from the list if they are controlled by the GPU.

Then in BCM2835, the list changes and specifically mentions SPI slave, but the reference to SPI master disappears off the list. (EDIT - I misread; it's there, on the next line, as SPI0-SPI2).

The result might be horribly device-specific and would need to be tested on different Pi versions I guess. 

I'm now curious what the end application is, because if no-one's written a decent driver for Linux for SPI slave (apart from the workaround ones which have limitations) there could be other options which people have resorted to. Currently it's unknown though, just what throughput is required, and if regular polling as a master could be an option or not.

 OriolPascual care to shed some light on your actual use-case?

Sure.

Firstly, a huge thanks to everyone for the incredible assistance provided on this forum.

The application integrates edge computing with high-speed and high-precision ADC for industrial purposes. For the ADC component, we're considering the AD7768 paired with the CM4. This combination offers both computing power, digitalitzation capacity and the flexibility to utilize networking via Ethernet cable or Wi-Fi.

Ideally, I would like to eliminate the necessity of a middleman serving as a data buffer, allowing both components to function as masters. However, if no other alternatives exist, I may have to resort to this approach.

Regarding the communication protocol for the AD7768 (AD7768/AD7768-4 (Rev. C) (analog.com)).

Dataready (DRDY) indicates a conversion is ready to be streamed, i plan to connect this to the CS, clock, and two data outputs, which will then be linked to the Master Output Slave Input (MOSI). While I acknowledge that this implementation may not be optimal, my intention is to avoid hardcoding the interface entirely.

Said that, what is your opinion, and what would you di given the case?

Huge thanks to all of you for the help provided!

I've used the AD7768 and I very much doubt that you will ever get good performance with it directly connected to a micro. Few micros support SPI with multiple data lines and even those that do are aiming at memories rather than the AD7768's interface.

The ADC requires a low jitter clock - usually at some frequency other than normal frequencies at which the micro operates. So you need to buffer the data and move it carefully between clock domains.

High speed data transfer into a micro using SPI in slave mode requires the use of DMA and interrupts (or precision polling) and this will be very hard to achieve on a linux based OS.

I would suggest that you use an FPGA between the processor and the ADC - this will allow you to operate the ADC. You don't need a monster FPGA, an Intel MAX10 or Efinix Trion (much cheaper) will do. A Lattice iCE40 part might do but may be too slow.

This picture shows the AD7768 and the Intel(Altera) Max10 FPGA ( and  a lot of analogue signal processing). If I did the design today I would use an Efinix FPGA (less than half the price in small numbers).

MK

michaelkellett said:

Few micros support SPI with multiple data lines and even those that do are aiming at memories rather than the AD7768's interface.

one of the outliers: the TI Hercules family. Their SPIs support 4 data lines, and buffering, and DMA (and redundancy for your safety) . Not focusing on memory.

I've used it to drive a colour LCD display.