Can an Arduino UNO communicate to 4 other UNO's via the I2C buss?
Can an Arduino UNO communicate to 4 other UNO's via the I2C buss?
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).
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
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
Andrew Mathison wrote:
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
There is nothing in the I2C specification from Philips (the originator of the I2C bus) that says it is only for short distances. The fact that it is designed to work
with a 400 pF capacitive load (max.) and that the description in the specification mentions using it for a keyboard interface (keyboard cables are longer that
20 - 30 cm, 8 - 12 inches) says otherwise.
If you go to this website:-
.....you can read the following, which is simply correct and VERY true:-
---------------------------------------------------------------------
The I2C bus was designed by Philips in the early '80s to allow easy communication between components which reside on the same circuit board.
-----------------------------------------------------------------------
So it WAS originally designed for short distances.....they should know even if you don't, don't you agree?
Though there are "trix and chips" that can extend it significantly further....but to get really good distances, you need other technology generally speaking.
Just saying that I2C can go long distances, with no qualification that its only with the help of other technology, will generally cause people to heavily question the speaker's knowledge....
Regards
Andy
Andrew Mathison wrote:
If you go to this website:-
.....you can read the following, which is simply correct and VERY true:-
---------------------------------------------------------------------
I2C-Bus: What's that?
The I2C bus was designed by Philips in the early '80s to allow easy communication between components which reside on the same circuit board.
-----------------------------------------------------------------------
So it WAS originally designed for short distances.....they should know even if you don't, don't you agree?
Though there are "trix and chips" that can extend it significantly further....but to get really good distances, you need other technology generally speaking.
Just saying that I2C can go long distances, with no qualification that its only with the help of other technology, will generally cause people to heavily question the speaker's knowledge....
Regards
Andy
Again, that is not what is said in the Philips (the originator of the I2C bus) I2C specification in their data books. Of course there is a trade off between the number of I2C devices
you are connecting to and the distance allowed between them. The original post was for three I2C devices at a conservative ~ 25 pF/device which allows for a lot of leeway
for distance.
Edited to include this:
Philips always promoted the I2C bus as a multi-purpose digital communications bus that could fill several roles including connecting one or more devices on a PCB
or between one or more devices over a cable. A good example of the latter is its use in late gereration VGA monitors (over several feet of cable I might add) that
allowed the computer to download timing and other information from the monitor so it could automatically configure the video card to work with it. It should also be
noted that the SMB bus which is a slight variation of the I2C bus is used on PC motherboards to communicate with hardware monitors, memory modules, and
anything else connected to it and that it is sometimes available for external devices via a connector on the motherboard. Finally a lot of video camera modules
have another slight variation of the I2C bus which is used to set a long list of parameters in the image sensor.
If anyone interested in defining "distance" problems would like to check I believe page 60 of the most recent I2C manual "UM10204", has a note with regards to bus lengths above 10 cm requiring careful & correct planning:-
if the length of the bus lines on a PCB or ribbon cable exceeds 10 cm and includes the VDD and VSS lines, the wiring pattern should be.......
There is a note further if only the Vss line will be carried.
It also mentions that the problems lie with the sensitivity of the signal lines to interference, NOT JUST CAPACITY AS MANY BELIEVE, which is of course important as well, both must be considered when designing and building. Capacitance is not the whole story:-.
The bus lines are most susceptible to crosstalk and interference at the HIGH level because of the relatively high impedance of the pull-up devices.
Plus, there is no need for a "war" about this subject as someone else correctly mentioned, but these facts are easily found in the "Bible" fron NXP, so anyone can check for himself as needed.
If anyone would like to download a copy of the I2C manual, from the original designer, I found probably the most recent one (Rev. 5 — 9 October 2012) here:-
http://www.nxp.com/documents/user_manual/UM10204.pdf
I personally believe that if we are to assist anyone new to this bus, he should understand a) where all the necessary documentation can be found and b) have information given in a friendly and free manner with regard to what many might regard as oddities for example.
Others here have already correctly mentioned that there are several other methods around to increase the signal path distance, often with other types of technology that are relatively easy to implement if and when required.
It is probably true to say that a "dyed in the wool" I2C expert can get longer lengths of bus up and running, but that is not really the place to start for a probable beginner, furthermore, the needed equipment to fault find and fix faults if the occur may be outside the budget of many people....
By the way, www.NXP.com is the "follow-on" from Phillips, so this is a fully official manual that could help many
I also like the Wiki page:- http://en.wikipedia.org/wiki/I2c#Limitations
as it has many useful links including I2C tutorials if required.
Regards to all and best of luck.
Andy
Andrew Mathison wrote:
If anyone interested in defining "distance" problems would like to check I believe page 60 of the most recent I2C manual "UM10204", has a note with regards to bus lengths above 10 cm requiring careful & correct planning:-
if the length of the bus lines on a PCB or ribbon cable exceeds 10 cm and includes the VDD and VSS lines, the wiring pattern should be.......
There is a note further if only the Vss line will be carried.
It also mentions that the problems lie with the sensitivity of the signal lines to interference, NOT JUST CAPACITY AS MANY BELIEVE, which is of course important as well, both must be considered when designing and building. Capacitance is not the whole story:-.
The bus lines are most susceptible to crosstalk and interference at the HIGH level because of the relatively high impedance of the pull-up devices.
Plus, there is no need for a "war" about this subject as someone else correctly mentioned, but these facts are easily found in the "Bible" fron NXP, so anyone can check for himself as needed.
If anyone would like to download a copy of the I2C manual, from the original designer, I found probably the most recent one (Rev. 5 — 9 October 2012) here:-
http://www.nxp.com/documents/user_manual/UM10204.pdf
I personally believe that if we are to assist anyone new to this bus, he should understand a) where all the necessary documentation can be found and b) have information given in a friendly and free manner with regard to what many might regard as oddities for example.
Others here have already correctly mentioned that there are several other methods around to increase the signal path distance, often with other types of technology that are relatively easy to implement if and when required.
It is probably true to say that a "dyed in the wool" I2C expert can get longer lengths of bus up and running, but that is not really the place to start for a probable beginner, furthermore, the needed equipment to fault find and fix faults if the occur may be outside the budget of many people....
By the way, www.NXP.com is the "follow-on" from Phillips, so this is a fully official manual that could help many
I also like the Wiki page:- http://en.wikipedia.org/wiki/I2c#Limitations
as it has many useful links including I2C tutorials if required.
Regards to all and best of luck.
Andy
The document you talk about does not include the "careful and correct planning" phrase. It does specify the order of signals on the cable to minimize noise and
crosstalk on cables over 10 cm which is not hard to follow. In the case of connecting three Arduinos together there is no need to supply Vdd to the far end as it
already has its own power supply but Vss will need to be connected.
If you read my previous posts you would see that I also mention that it is susceptible to noise, and that I give a couple of useful tips on how to check out and
work around this without using any specialized equipment other than the Arduinos themselves, a little test software using existing Arduino libraries, and maybe
shielded cable. Using the correct cable layout will definitely help. If you read the spec. you reference you should notice that the capacitance of the signal lines
(cable or otherwise) is by far the most frequently mentioned factor in limiting the ability to use the bus both at speed and over distance due to the specified
current sinking capacity of the drivers, hence the high value pull-up resistors. This has not changed from the original specification. The newer specification
does include driver changes required by the high speed and Ultra-high speed versions.
As mentioned in my previous post I2C was used by many brands of VGA monitors over several feet (6' to 9') of cable accompanied by some high speed analog
signals in the same cable. At these distances some tweaking of the pull up resistors would probably be required but the amount of tweaking is still limited by
the current sinking capacity of the drivers themselves. Tweaking these resistors for such distances can still be done, albeit more slowly, with no special
equipment other than the eqiupment mentiond previuosly, some resistors, and a soldering iron assuming soldering is included in a beginners skill set of
course. From the original posters description I did not expect to need that kind of distance anyway so I'm not sure why any special extension drivers would
be needed.
While the official bus specification is by far the best source of information on the I2C bus, I would be very surprised if a beginner as you put it could make heads
or tails of most what it says. Clearly such a document requires much more than just a beginners knowledge of AC and DC electronics. That is why these forums
exist. However, sometimes the information on the forums is less than useful ("over 10 - 12 cm, start worrying"), and when someone else steps in with better
advice it is perceived as hostile. OOOKAAA.
There was no war of words, only an ongoing attempt to reply to some less than useful opinion with slightly more useful information.
It's good points. I must admit I did get curious to do the math, and even at these low frequencies (400kHz) 100pF has an impedance of around 4k. So the crosstalk would be bad as you say, no matter how hard one can (practically) pull up the open drains. 400pF would be pretty severe. Nowadays people run I2C at (say) 3.3V too, making the problem worse.