Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
I'm contemplating a project that would require several AVRs talking to each other over a bus. They'd be separated by as much as 6 feet.
It seems like both I2C and SPI can let a series of micros communicate over a bus, but I haven't seen anything talking about how long that would be. Has anyone tried connecting these protocols over distances of several feet?
As others have said, SPI and I2C can be used over long distances as long as the pull-up resistors, clock frequencies and so on.
The main alternatives (which will give better noise immunity) are RS485 and CAN. Both of these use differential lines in order to minimise noise issues and are better suited to this length of data transmission than I2C or SPI. However, I don't think many (any?) AVRs come with built-in CAN peripherals, which make CAN use much easier.
I would say that the most important thing to consider when picking a bus is to ensure that the protocol you use for communicating between devices includes a CRC or equivalent so that you can determine whether a message has been received correctly (CAN has this as part of the packet). Considering this, it's also useful to have an ACK/NACK type response as part of the protocol so that a corrupted message can be re-transmitted.
Several feet shouldn't be problematic, just use twisted wires if you can. SPI is much easier to buffer (if you need to) than I2C since SPI signals are all unidirectional, whereas I2C's signals are on shared lines.
can the AVR microcontrollers handle I2C and SPI slave modes as well as master modes? (you'd need both)
For I2C over long distances you might want to seek out some "I2C bus repeater" solutions. Keep in mind that any maximum distance you might find for I2C or SPI communication is mostly referring to the total bus distance and not the to distance between two nodes in a bus.
You might want to look into RS485 for these kinds of problems. It's a serial bus protocol which communicates over differential lines, so when using twisted wires, the chances of noise are minimized. Very long distances can be reached this way. The downside would be that you would need an extra RS485 encoder IC (like a MAX485 ,not very expensive) in your circuit.
Just an FYI, the interface between the wireless Nintendo Wii remote and its Nunchuck companion uses I2C over a cable that is about 3 feet long. There are also 3-foot extensions cables that extend the total length to about 6 feet. Not exactly the same as your setup (only two devices connected together), but it is an example of I2C over a cable in a widely-used consumer product.
One advantage not yet mentioned of SPI over I2C is that all SPI wires are unidirectional and are always driven high or low. This allows much faster communication than is possible with I2C, reduces susceptibility to noise, and allows simple gates to be used as repeaters. Another useful option is simple async communication (one wire each direction). The only downside I can see to async communication is that it generally requires both sides to be "awake", with a stable clock, to exchange data.
For a project of my own, I used a 3-wire slightly-modified SPI protocol and have found the results satisfactory. I send display bitmap data (where occasional data corruption would be no big deal) at 10mbps and other data at 2.5mbps without difficulty.
While both I2C and SPI are designed for short-distance hauls (a few inches), both can be utilized on longer hauls with proper cable and attention to overall bus capacitance.
While I have little experience with SPI, I2C isn't terribly difficult given that you always need to calculate the proper size for your pull-up resistor. Additionally, there are dedicated, and inexpensive I2C buffers that are quite easy to use. However, you will still have to use a properly-sized pull-up resistor for your network.
I have used I2C to network between two AVRs at a distance of 8 feet, using only pull-up resistors and high-quality, well-shielded, twisted cable.
As many have suggested, I2C and SPI are best used for short distances. While it may be possible to implement a solution with these interfaces, I would higly recommend that you look for a different, "more standard" solution (e.g. Ethernet, RS485, CAN, etc). -- Especially if you're planning to use cables to reach the 6ft distance between microcontrollers.
I worked on a project involving about 80 AVR-based nodes in a star network communicating over I2C. It was a total mess and didn't work in the end. Getting updates to all the nodes took seconds and one faulty connection would throw off the whole network. Last I spoke to the guy who made the nodes, he said he's stopped using I2C for projects like this. Unfortunately I don't know why specifically I2C was inadequate here.
It should be easy with that short distances. What you could do is figure out what those distances and your cabling means in terms of capacitance and line impedance and see what kind of frequencies (rise/fall times) you can get through them. Beyond certain point, it's best to treat them as transmission lines. If it looks bad, you could indeed switch to some other serial line like EIA-232 or 422. That might mean an extra chip at both ends but will stretch far. If you really need to go fast and far, you'll need something more (ethernet, don't count out radio or laser :).
If you can control the clock speed and you don't need high-speed data transfer, you should try to slow the clock down. This will make it less susceptible to noise.
