I want a RPi to act as a SPI master and be able to communicate with 24 SPI slaves. The SPI connection is full-duplex. The SPI slaves are about 50 cm away from the master (SPI runs on wires to an other PCB board not considered here). The 24 slaves will be Blue Pill STM32 boards, I have to use DMA on the SPI slave (CPU is very busy).

I have successfully communicated using SPI with 50 cm unshielded cables with a reasonable enough baud-rate for my application (9 MHz).

I'm pretty sure (though I have not tested) I will run into problems because of the multiple SPI slaves and long wires so I designed a schematic and I would like you to tell me what may work and what may not. There is also probably room for simplifications.


  • I plan to use 3 daisy-chained 74HC595 shift registers to generate 24 outputs that will determine to which SPI slave the RPi will be connected to.
  • I plan to use CD54HC125 quad tri-state buffers to isolate the other SPI slaves when connected to one, these would be driven by the shift registers outputs.

Raspberry Pi

Raspberry Pi

  • SER, SRCLK and RCLK drive the shift registers
  • SPI_CS, SPI_MISO, SPI_MOSI and SPI_SCLK drive the SPI communication (RPi is the master)

Shift registers

Shift registers

  • SER, SRCLK and RCLK driven by the RPi
  • Daisy chained
  • Each SPI_x output will drive a tri-state buffer

Tri-state SPI buffers

Tri-state SPI buffers

  • There are 24 similar blocks like this, only the SPI_x changes
  • Each 01x04 male connector leads to one SPI slave
  • Output enable is driven by one of the shift register output (here SPI_0)
  • SPI_MISO is inverted because it is an output pin of the slave

This is my first KiCAD design, review and comments would be much appreciated before I buy components and try to test on a breadboard! After that I plan to layout the PCB and get it manufactured.

Edit ( July 2018): Real world test

I have just tested the communication between one Raspberry Pi (master) and 6 blue pill (STM32) boards, full-duplex.

RPi and Blue-Pill test

Without any additional device and despite the poor wiring the communication works at 10 MHz reliably; 99.6% over 12 000 messages (checked with a Flechter sum)

Whether this scales up to 24 device or not remains a question :)

  • \$\begingroup\$ Those buffers are inefficient. You just need one. \$\endgroup\$
    – Long Pham
    Commented May 6, 2018 at 17:25
  • 1
    \$\begingroup\$ Are the slaves working on different voltages ? They can be daisy-chained, if you don't mind losing the speed. \$\endgroup\$
    – Long Pham
    Commented May 6, 2018 at 17:34
  • 4
    \$\begingroup\$ Why do think it's necessary for you to be isolating & buffering MISO/MOSI/SCK individually for each slave? Why don't you just use your x595's to drive individual CS to each slave and wire all of the other SPI signals together? A properly implemented SPI slave should be completely passive on the bus if its CS is inactive. \$\endgroup\$
    – brhans
    Commented May 6, 2018 at 17:39
  • \$\begingroup\$ I didn't know that the hardware managing the SPI would switch the pins (all except CS?) to high impedance when not asserted through CS! I'll check it is the case with the STM32F1 \$\endgroup\$ Commented May 6, 2018 at 18:57

1 Answer 1


Why would you "isolate the other SPI slaves when connected to one"? The whole point of using SPI is that CS line activates only one slave at a time.

Is it to deal with fan-out load on SCK and MOSI lines? A simple buffer driving signal "bus" would be sufficient for this.

Or is it to multiplex SCK signal as well? I don't think you need to do this. Instead of using shift registers to multiplex signals, you can use them to directly drive CS pins of the slaves. If your software does not output clock signal until correct slave selected there is absolutely no harm in "activating" them one by one without actual transmission.

I think the limiting factor in your design is line capacitance, which will grow regardless of what you connect to RPi outputs, buffers or slaves.

So, use shift registers to activate CS pins on slaves and use simple line buffers on SCK and MOSI.


I was digging around for other stuff and found this chip that I think fits perfectly into your application. ADG731 is 32 channel SPI controlled multiplexer/demultiplexer. So, you can put it on the same SPI channel as your slaves to switch CS line between them (the mux CS will be separate, of course).

This would work even better than switching CS with shift registers as I suggested above, since
a) you would not be activating slaves right away while switching,
b) you can target any slave in any order, and
c) you will free 2 of the I/O lines used to control shift registers

Add tiny dual buffer for SCK and MOSI and you have faster directly-addressable 2-chip solution instead of 27 chips with address shifting.

  • \$\begingroup\$ My understanding is that with CMOS logic the fan-out is easily very high (> 1000) so not relevant in my case. I'm not sure what a "simple line buffer" is, an example would be appreciated \$\endgroup\$ Commented May 6, 2018 at 18:59
  • \$\begingroup\$ I did not mean anything fancy, only that you don't need chip with 4 independent 3-state buffers. Something like this or high speed this would be sufficient for your application. Of course if you already have HC125 or VHC125 buffers they should work just fine. \$\endgroup\$
    – Maple
    Commented May 6, 2018 at 21:19
  • \$\begingroup\$ "The ADG731 switches one of 32 inputs (S1–S32) to a common output"... don't you need the opposite to drive 32 CS/ lines instead? \$\endgroup\$
    – Eric
    Commented Feb 12, 2019 at 23:41
  • \$\begingroup\$ @Eric just couple paragraphs down from that you can find "These parts can operate equally well as either multiplexers or demultiplexers" \$\endgroup\$
    – Maple
    Commented Feb 14, 2019 at 2:38
  • \$\begingroup\$ Thanks @Maple I didn't see that. It's odd they don't write it at the top of the datasheet. It's a pretty important piece of information. \$\endgroup\$
    – Eric
    Commented Feb 15, 2019 at 9:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.