-bulletproof- multiple SPI bus devices?

OK not a lot of data on running multiple SPI devices, a few at AVRFreaks, random Googling, even a couple exist here. (like [u]Arduino + Ethernet Shield + Another SPI device[/u] and [u]SPI with multiple slaves (why is pin 10 only ss)[/u]). I'm having trouble doing the prerequisite research, especially in forcing misbehaving SPI devices to play nice with others. I'm guessing by the lack of documentation, if it doesn't work, people give up quickly.

Multiple modes and multiple speeds and multiple delays, oh my! Like, a certain 8-digit 16-seg LED driver only supports mode 0 @ 3.4MHz max, but an SD card all modes at much faster than an ATmega can drive, and an SRAM chip that has no specs so I guess you just try everything? Next, since I'll need a pin to pull CS low for each, is that my cap? Or is it bus congestion / contention / etc. And apparently certain devices are a PITA, like the Ethernet shield, for sharing the bus? Any way to tell from looking at an IC's datasheet if it's going to be an "SPI troublemaker" or is it down to implementation?

Further, is there a way to calculate latency timings semi-accurately in a shared bus scenario? I need multiple LED + opto pairs to have around 500uS max triggering latency, and I want to drive the opto LEDs via free pins on the LED plexer IC, which should be easy - it's combined input+propagation+transition is 150nS and since LEDs can be single-digit nS reactive they won't contribute delays. But life rarely matches datasheets and I'm guessing it's down to loops and interrupts, so this is a guess.

I know the best way to find out is get all the parts and just get to it. The multiple modes is probably key; if that works I'm sure changing speeds when you change mode is no hassle.

Anyway, anyone with 3+ device SPI experience on Arduino? Does it "just work" or :^) ? Any multiple-SPI devices related bookmarks to share?


since I'll need a pin to pull CS low for each, is that my cap?

Yes on some SPI devices, mind you you can always have extra through a port expender or shift register. On other SPI devices there is an address structure, like the MCP23S17 which allows 8 devices to be connected to a single bus with single enable.

Or is it bus congestion / contention / etc.


Any way to tell from looking at an IC's datasheet if it's going to be an "SPI troublemaker"

Yes - look for what it wants and see if it will be trouble with the other devices you plan to use.

But life rarely matches datasheets

No in electronics life is defined by the data sheet, if the data sheet says it then (errors not included) it is true. Errors although not unknown are rare in reputable manufacturer's products.

Most SPI will work at lower speeds, it is just the upper speed than can be variable device to device.

No in electronics life is defined by the data sheet

What I meant to convey is that every manufacturer thinks their product is the One and True and the rest of the circuit should be designed around this fact, which is why we end up with conflicts in the first place even where there's a clearly defined specification to comply to.

re: the multiple like devices on one CS line, yes, the LED driver above daisy-chains 8 I think off one, but this only works if you wire between them so I guess this will rarely happen with different parts, and never happen with different manufacturers.

You didn't come in with a "don't get me started!" so I'm guessing it will go better than I hoped! :^D

Over the years I have worked with SPI devices from a number of "Major" manufacturers (TI/Dallas Semi, Maxim, Philips/NXP, etc.) and I have never encountered problems using production parts in SPI port implementations on a number of embedded processor projects, using processors with built-in SPI hardware: Renesas, Intel, Atmel, Microchip, etc., etc., etc.

Maybe I'm just lucky? Note that I just about never try operating at absolutely maximum speed, so there may have been some subtle (or not-so-subtle) timing problems that other people encountered, but that I never saw.

The only one that I have seen with problems is the Wiznet '5100 used on the Arduino Ethernet Shields (not my design, and obviously the bug was not known by the designers before releasing the first Ethernet Shield) . The Wiznet SPI problem (the chip pollutes the MISO line when the chip is not selected) is documented in an application note that you can get from the Wiznet web site, but I couldn't find anything marked "Errata."

Well, there is an Errata sheet, but it is not about the SPI bug. Shame on Wiznet! (Unless I'm missing something, which is entirely possible.) It's a BUG, folks. Worthy of listing as Errata, not just in an Application Note!

The workaround is implemented on the New Ethernet Shield referenced on the Arduino site. (I performed non-surgical mods on my old-model Ethernet shields by hot-gluing an inverter chip on the Shield and sky-wiring input to Arduino SS signal and output to Wiznet "SEN" signal line, as shown in the Application note.) Now my Ethernet Shield "plays nice" with my separate SPI-port interface SD card.

Bottom line: There may be other devices with defective SPI interfaces. It would be "nice" if anyone considering a new design had access to a manufacturer's or manufacturer rep's or distributor's FAE to tell the truth about problems. It would be nicer if the manufacturer had an actual list of Errata (instead of some application note or some "specifications update" as Intel used to call them). Regardless of how forthcoming the manufacturer/rep/distributor is, a designer should probably search the web for any reported problems.



There is another, undocumented, Wiznet bug that I discovered when I got my first Ethernet Shield a few weeks ago.

There have been endless reports that the power-on reset (as well as the Arduino auto-reset) doesn't work with the old Ethernet Shields. Some "fixes" work for some people; some work for others. Hanging capacitors across reset lines (or any other lines) trying to fix things just rubs me the wrong way. Really. Also the effectiveness is very erratic according to many reports. (And the extra capacitance tends to interfere withe Arduino auto-reset function on the ATmega chip.)

Well: I think that this the real bug: The he chip is operating on +3.3V .
Although the inputs are specified to be 5 Volt tolerant (and they apparently are: the chip is not destroyed by +5Volt input signals), if the reset is pulled up to +5 volts the power-on reset is erratic and/or non-functional.

So, here's what I did:

I bent the "Reset" pin away from the shield so that it does not make contact with the motherboard when the Shield is plugged in.

I soldered a 10K resistor from the Ethernet chip "Reset" pin to +3.3Volts (This is important: tie it to +3.3V, NOT +5V) and a 10 nF capacitor from the Ethernet chip "Reset" pin to GND. I have never had to manually reset the Shield again. Ever.

Note that neither of my workarounds require surgery (I don't like trace cutting if it's avoidable). They also don't require any software changes or any extra ATmega I/O pins for control.

If they don't work the way that you want, they are easily removed so that the board can be restored to its original (buggy) condition. Maybe you can sell it (with full disclosure, of course) and buy one of the New Ethernet Shields. (I haven't had a chance to get a new one yet. I hope it works, but maybe I will wait to see if others find them acceptable.)

even where there's a clearly defined specification to comply to.

Because that specification has options in it like whether to sample on the rising or falling edge of the clock. It is not an unambiguous standard.

not an unambiguous standard.

I don't think the "standard" is ambiguous for things like that all. From the earliest days, Motorola defined four modes with different clock polarity and bit order. There is no law that every slave device must support every mode, right?

A manufacturer of a slave device simply must tell which mode(s) that device supports. (And, of course, if more than one mode is supported, how to get the device to operate in that mode.)

Other aspects may be a little more "interesting." For example if the devices are connected as a daisy chain rather than individual devices with SCK, MOSI, and MISO in parallel with separate chip enable signals for each device. Properties of each slave device must be carefully studied to determine whether they will "play nice" together.

What is the command/data protocol? What happens when the number of clock pulses is more than required for that device? I don't think there is any "standard" specification for stuff like that.

I don't think that makes the "standard" ambiguous. It just presents "learning opportunities" for applications designers.

Final words (about timing):
Whether you are using hardware or software (bit-banging) SPI control circuitry on your microcontroller you have to take into account individual timing requirements (latency, etc.) for all of the devices you are going to talk to, no matter which mode the individual slaves are operating in.



It just presents "learning opportunities" for applications designers.


I don't think that makes the "standard" ambiguous.

I do
Defined as:-

  1. (of language) Open to more than one interpretation; having a double meaning.

It's not a plug and play standard, it has options, it has two ends, therefore no one can guarantee if a device sticks to the standard it will always be compatible with another device that sticks to the standard.