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.
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
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.
The only irony missed here is that you still seem to think that "start to worry" is informative in any context.
No the protocol is not the physical interface. A physical interface is the electrical specification for sending/recieving data across some physical
medium, RS-232RS-232 vs RS-485 as an example. The protocol determines how the data is sent across the physical interface - addressing, byte order,
error detection/correction (which can be done in hardware or software) etc. and it resides in one or more layers above the physical interface.
For a hobbiest, which is what this is aimed for, 10 to 20 minutes will tell you if it is working with reasonable reliability. A 20 minute test at
100 KB/s will have sent/recieved ~ 100,000,000 bits. If you need better reliablity, run the test for a longer time.
You are right about one thing, this conversation has become a waste of time.
Running for "DAYS" may seem like a good alternative, but its not really, its just mostly a waste of time. It only tests one setup, in one place, one time.
The right way to do it is to build in error correction, so that if your "tested for days system with no errors", suddenly starts getting errors due to sudden circumstances beyond your control like a thunderstorm or simply something has been placed near your cables, or taken away, or a big motor is started or stopped within a mile of where it is, of just ANYTHING, the error correction just cuts in and fixes the poroblems.
To get error correction to work, you also need to actually find out that an error has occurred, so you may need to understand how parity works, plus longitudal error detection as parity will not find a double error always, but its a start.......
I have read all the posts and actually, they all seem to be trying to help the OP, and they also demonstrate to me at least to have more understanding than some here...
Do please remember that someone asked a question, killing the messenger is not helpful or friendly....try to be slightly more forgiving please to those trying to help who maybe did not appear to be "helpful enough" in YOUR eyes.....OK?
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....
I agree with you that a very long test may not be that informative but there are also (reasonably common) cases when error detection does little to help. If, for example, the system timing is marginal it may got from an error rate of less than 1 bit in 1E9 to 1 bit in 1E2 as the temeperature changes from 20C to 30C. Error detection folowed by re-transmission probably won't save you. It's still a very good idea to have it because it's a big step on the way to measuring and ultimately dealing with the source of the problem.
I would expect a professional designer to check the bus timings/waveforms with a scope but of course this may not be possible for many hobby engineers. The answer there is to be careful to work well within specs, try to conform with common good practice (short spans and error correction) and be perapred to be innovative in your debugging.
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.
I agree with you that a very long test may not be that informative but there are also (reasonably common) cases when error detection does little to help. If, for example, the system timing is marginal it may got from an error rate of less than 1 bit in 1E9 to 1 bit in 1E2 as the temeperature changes from 20C to 30C. Error detection folowed by re-transmission probably won't save you. It's still a very good idea to have it because it's a big step on the way to measuring and ultimately dealing with the source of the problem.
I would expect a professional designer to check the bus timings/waveforms with a scope but of course this may not be possible for many hobby engineers. The answer there is to be careful to work well within specs, try to conform with common good practice (short spans and error correction) and be perapred to be innovative in your debugging.
MK
If the error occurs frequently, error checking and retransmission may not help and will certainly slow down communications which could cause other problems. If it is only occasional, then it will help
and in both cases it will alert you to the fact that there is a problem.
A scope is really the only way to know what is really going on and is 2nd on my list of must have tools for serious hobbiest, the multimeter being first. 20 MHz scopes (works with I2C and probably
most Arduino debugging) are fairly inexpensive but knowing how to use them does require at least some knowledge of AC and digital waveforms.
