I2C buss

Yes. The other four UNOs would be set up as slave I2C devices as in this example: http://hacknmod.com/hack/how-to-connect-multiple-arduino-microcontrollers-using-i2c/

Also, make sure they are all fairly close to each other; I2C was designed for short distances (more than say 20-30 cm start worrying).

It should be easily possible (it depends more on you than anything else!), but if you have little experience with I2C, I would recommend that you buy a good book on it before starting, lots of great bed time reading that will make your fingers itch to get going......

Maybe there is an I2C forum that could also help, have a look around, but a book is absolutely essential!!!

Regards

Andy

shabaz wrote:

 

Also, make sure they are all fairly close to each other; I2C was designed for short distances (more than say 20-30 cm start worrying).

I can find nothing in the Philips specification that limits I2C to 20 - 30 cm (~ 8 to 12 in.). What I do find is a limit of 400 pF capacitance on the

bus. With IC inputs at a conservative 25 pF each allowing for some stray PCB capacitance, and standard 28 gage ribbon cable at 46 pF/m

(AMP.Ansley catalog) it should allow ten I2C devices (250 pF) to be connected with a maximum cable distance of ~ 3 meters (~ 10 ft., 138 pF).

Using connectors will also add capacitance to the I2C bus and should be added in if used. It should be noted that the design of the I2C bus is

not very tolerant to EMI or other electrical noise so keeping distances as short as possible and routing away from any noise sources is a good

idea. Shielding could be used on the cable although this will increase the capacitance of the cable.

Sigh. I didn't say there was a limit at 20-30cm - I said start worrying.

Gary Stewart wrote:

so keeping distances as short as possible ... is a good

idea.

If you're considering running this over much more than a short distance, you need to start taking additional concerns. You can't just take (any) pair of wires and expect it to work over 3m, nor even a meter (not that I would try - I would pick RS232 for this distance).

From experience, even at distances of around 30-40cm, running at 400bkit/sec with I2C devices from reputable manufacturers, you have to start

taking care (and sizing your pull-up resistors appropriately for a decent waveform).

BTW - I2C is a great protocol - and is therefore the ubiquitous choice for good reason and virtually every electronic item beyond a flashlight probably uses it.

For end product-to-end-product comms (where you may want a distance between them) there are better options.

shabaz wrote:

 

Sigh. I didn't say there was a limit at 20-30cm - I said start worrying.

 

Gary Stewart wrote:

so keeping distances as short as possible ... is a good

idea.

 

If you're considering running this over much more than a short distance, you need to start taking additional concerns. You can't just take (any) pair of wires and expect it to work over 3m, nor even a meter (not that I would try - I would pick RS232 for this distance).

From experience, even at distances of around 30-40cm, running at 400bkit/sec with I2C devices from reputable manufacturers, you have to start

taking care (and sizing your pull-up resistors appropriately for a decent waveform).

BTW - I2C is a great protocol - and is therefore the ubiquitous choice for good reason and virtually every electronic item beyond a flashlight probably uses it.

For end product-to-end-product comms (where you may want a distance between them) there are better options.

Start worrying is not a very informative reply, the follow up is much better.

Gary Stewart wrote:

Start worrying is not a very informative reply, the follow up is much better.

Whilst all the responses so far contributed to the OP's question, I think your response here does not.

I think we have answered to some degree Chris' original post - to summarize, the answer being yes, but take some care over distance - the

point in my very first post. It can be run to greater distances (over a large chassis for example) but some hobbyists with

Arduino devices may not have test tools beyond a multimeter/logic probe. Running over expensive! shielded cables while possibly

feasible, is an odd suggestion.. if you're resorting to that, why not pick an appropriate protocol.

shabaz wrote:

 

Gary Stewart wrote:

Start worrying is not a very informative reply, the follow up is much better.

 

Whilst all the responses so far contributed to the OP's question, I think your response here does not.

 

I think we have answered to some degree Chris' original post - to summarize, the answer being yes, but take some care over distance - the

point in my very first post. It can be run to greater distances (over a large chassis for example) but some hobbyists with

Arduino devices may not have test tools beyond a multimeter/logic probe. Running over expensive! shielded cables while possibly

feasible, is an odd suggestion.. if you're resorting to that, why not pick an appropriate protocol.

You could easily say the same about this reply. Your first post was a poor response to the question since it clearly left a false impression about

what distance I2C could be used (exactly what does start worrying mean to the "typical" Arduino user you describe here ?), or what could be

done to improve it. Basing your response on an assumption of what equipment may or may not be available to that "typical" user does not help either.

A shielded cable is more expensive but not excessively so and using it has more to do with noise than distance as was clearly stated. The protocol

is not the problem, the physical interface is. It was designed to go over 30 - 40 cm with more than a few devices connected to the bus even at

400 KB/s, but it may require some tweeking of the pull up resistors to get there. If you do not have an oscilloscope to verify the signal intergrity

(not really sure how a multimeter/logic probe helps here since multimeters are usually bandwidth limited to about 1 KHz and neither the multimeter

or logic probe in any way tell you if what is on the line is the correct data at any given time) I would suggest writing a sketch for the master that

continuosly sends data to the slaves and a sketch for the slaves that allows the master to read back the data it sent for say 10 to 20 minutes

while counting the number of errors to make sure it is working properly. Adjusting the pull up resistors might be more than a bit of a problem.

Note, I would only use short wires to verify that the sketches work and that there is an Arduino I2C library that makes writing these sketches

fairly easy. See, that actually says something useful.

Well, post #6 (your post) actually had zero "informative" quality for the original question, yet you chose to criticise my post for this exact reason.

Maybe that irony was lost on you.

As for your (self-stated) "useful" post above:

"not really sure how a multimeter/logic probe helps here since multimeters are usually bandwidth limited to about 1 KHz and neither the multimeter or logic probe in any way tell you if what is on the line is the correct data at any given time"

By the way, I didn't suggest using a multimeter or logic probe if that's what you're implying. I stated (fairly clearly, but maybe there is a language problem), that this is all some hobbyists will have.

Also your comment: "The protocol is not the problem, the physical interface is"

The physical layer is a protocol. It defines the voltages that you expect on the lines amongst other parameters. I2C only has two layers.

Finally your comment: "that allows the master to read back the data it sent for say 10 to 20 minutes while counting the number of errors to make sure it is working properly."

Really.. I'd run it constantly for (at the very very least) days non-stop to ensure I got absolutely zero errors, if I really was attempting to run it over cable (shielded or not) over any significant distance - not that I would design like this. 10-20 mins is insignificant. And sure you can build in reliability in your final code too by error detection/correction, but I'd at least start with a reliable hardware design and test it thoroughly. I'm not so sure there is any benefit or pleasure  in discussing this futher with you. Have a good day.

He was right, the concept for I2C was for short distances, and if you are new to the I2C "sport", then start short, get everything working and then extend.

Some manufacturers make special chips to aid in making long runs.

Best of luck