SPI buses, speed?

I'm interested in an application which would use Arduino as SPI master, to drive multiple Arduino SPI slaves. I understand the wiring aspect-- all devices share the communication lines (SCLK,MOSI,MISO), the master has to "select" clients (SS1,SS2,SS3,...), and each client needs to watch their own select line to listen or ignore the comms.

I guess my question would be just a general "any experiences, problems, surprises" call. If I have one SPI slave that just logs data to an SD card, and another two SPI slaves that collect data from sensors (reporting last-known-value whenever asked), how easy and fast will the master run with all this? How would you change the design if I2C is too slow but you want to increase the number of slaves?

Because SPI transmits at the same time as it receives, it is always a challenge to be 1 byte ahead as a slave. That is, when you get an interrupt telling you an SPI byte was received (as a slave), you had better already have written the byte you want to send out. Not a big deal, but easy to get wrong.

Beware of slaves that are SPI-compatible but in fact are always driving the MISO lines (e.g., I've seen a WizNet chip do this).

I don't think "easy" will be a problem but "fast" entirely depends on the details.

If I2C is too slow then SPI is the next logical choice I suppose.

Hi halley,
the biggest problem is probably to write the client software for the SPI-slaves. I have seen many attempts to write such a client but haven't seen any working (library-)code yet.

I2C is the much simpler solution, because the Wire library already provides the neccessary infrastructure for communication using callbacks functions with the client.

Maybe you could get by with simply running the I²C-bus at a faster speed?
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1241668644
Eberhard

Hm, good find, wayoda. The 400kHz I2C option looks interesting. I will time it with the faster clock and see what the throughput is. Saves a LOT of connectors if I can use I2C.