[Tarragon]

SPI requires 3 wires plus a Chip Select for each device on the bus. That 30 device network under discussion suddenly needs 33 pins. That's more pins than any processor I've used in the last couple of years.

I mean I guess we could use an i2c GPIO expander to get extra lines. I bet that would be "fun" to get right.

[guenthert]

You'd be using an address decoder for so many devices unless you have a MCU with an abundance of i/o lines (perhaps a soft-core within a FPGA).

[varispeed]

Many MCUs also don't handle SPI well (via DMA) or have bugs in peripherals. So the only viable way is bit banging and that is difficult to make faster than I2C. I am considering implementing SPI on FPGA to connect with devices and then transmit to/from MCU using "SPI" dialect that works with that MCU.

[rcxdude]

What kind of issues have you found with SPI peripherals? I've rarely found issues with SPI, certainly it's a peripheral which is far less buggy on average than I2C, where there are some absolutely awful implementations.

[Tarragon]

Agreed. I’ve seen plenty of I2C devices with problems. I’ve seen very few SPI devices with problems.

[scoutt]

I've seen much more buggy I2C peripherals than SPI (ST, I'm looking at you).

SPI is usually very stable. Here it's being used to generate VGA signals: https://www.artekit.eu/vga-output-using-a-36-pin-stm32/

[toun]

You can use a demultiplexer to turn e.g. 4 pins into 16 chip select. But the fact that the number of wires has to grow at all to accomodate additional devices is certainly a big downside compared to I2C, and for wired networks that basically makes it impossible to daisy chain devices.

[GeorgeTirebiter]

If you had 30 SPI devices, you'd probably use a small FPGA to address them all (produce all the chip selects as needed). Basically, write an integer (e.g. 5 bits would do for 30 selects) and a strobe and you're good to go. No address conflicts, ever. And very fast.