i2c physical interface?

The I2C spec was for on_board communication. Trace distance was considered to be short.

So, anything you want to do is all right with Phillips. They wrote the spec.

I did a project where the calibration parameters needed to be loaded with the probe installed into an instrument.

I added 2 extra lines in a connector and read/wrote an eeprom from there. Total distance was about 3 inches from the cpu ( board, wires and connector).

Donald

Hmmm...I'm designing my rover in multiple, independent modules (odometry, range finding, motor control, intelligent power supply)...I was only planning on going 12" max (star distribution). Is there another interface I should be look at? I hadn't planned to build everything on one board.

Thanks

This is not a new problem or difficult solution.

RS-485 is one that is cheap, fast buad rates and can go 1000's of feet !! Its a 8-pin chip that communicate over two wires. TI, Dallas Semi, Analog Devices and many others make this chip. Each manufacture has data sheets and app notes on how to connect them up.

If you do a google search for rs-485 and robots you will find lots of projects using this as a communication medium.

The I2c uses only a single master.

You can use the asyn serial ports of any processor and one direction bit to control direction of message traffic.

You can roll your own comm protocol or use one of the many "standard" protocols. Modbus comes to mind. If you use Modbus you will find all kinds of devices that use it as well. So you don't need to develop everything your self. Unless of course this is a hobby, so you might want to.

Good Luck and let us know what you decide to do.

Donald

I would not have thought that 12" is a problem. IIRC I2C runs at 100K bits / second and 400K bits / second. This is actually quite slow. Look at RS232 running at 115K b/s on a 2 meter cable.

Also, if you are driving the I2C yourself through software (rather than a hardware peripheral on an MCU) you can drive it as slow as you like provided you stick to the protocol.

I2C actually allows multiple masters on the same bus.

Regards Sergio Masci

- optimising PIC compiler FREE for personal non-commercial use

.

Yes, this is true. A newbe will have enough fun with a single master let alone two+. The code is not fun and always full of bugs. I have yet to get it right, but I only have had three devices to worry about.

I have found using I2C for other then peripheral devices is a waste of time, code space and RAM.

Donald

Mark Haase wrote in news: snipped-for-privacy@news1.east.earthlink.net:

Hers is a good paper on I2C:

There is a chart therein that shows cable length up to 2 meters, up to

100 meters with buffering.

Joe

The difference between I2C and RS232 is that the latter has active drivers and a larger dynamic voltage range with much higher noise-margin, while the former relies on a "passive" pull-up R on the Sdat line. Given the spec, this R should be no lower than about 1.7K or so, based on the devices being able to pull minimum 3 mA to gnd at 5v.

This means the capacitance on the line will limit the risetimes on Sdat. A rough calculation indicates this C should be no more than about

1000 pF for 100Khz timing. From F = 1/(2*pi*R*C), or C = 1/(2*pi*R*F), plug in the values given.

The longer the cable, the more the capacitance, and the worse the risetimes, until it doesn't work any longer. Also, if the pull-up R is larger, eg 2.7K or 4.7K, then maximum allowable cable C is lower, 600 or 330 pF.

- dan michaels

=========================

JFTHOI, thought I'd toss this in ....

This isn't necessarily true. At speeds over 400khz, I've gone as low as

1k pulups over short distances, and using an active pullup, I've taken the gross capacitance to ~3000pf over 4 meters. The active pullup circuits are all voer the web, and they're basically all the same.

As for 12 icnhes of cable, it shouldn't be much of a problem up to

400khz with a lower value pullup, say 1.5k to 2.5k. I do it all the time and dont have any issues.

--Andy P

dan michaels wrote:

Yes, as indicated, I was giving rough numbers, based upon the general spec. Using < 1.7K or so violates the 3 mA spec, but is probably ok for most gates today.

Active pullups are another matter. I assume those ckts can drive heavy currents into capacitive loads, but are also compatible with I2C devices that can sink only 3 mA. Eg, a PNP pullup transistor ckt may be able to source 100 mA or so dynamically, but the collector will saturate in the steady-state with just the 3 mA gate as load. Best of both worlds, I think.

Either way, a 12" throw shouldn't be too much of a problem, although I think I would put a scope on the line and actually measure the risetimes, especially when lengthening the line or tacking on more loads. It may take a bit of fiddling for best performance.

- dan ===========

Well I wasn't even planning on going to 400Khz. My bandwidth needs are pretty small. By 12", I was referring to the longest "point to point" connection. My plan was to take an i2c bus from my master (a JStamp) into the power supply, which will have a star distribution bus that has

5V, Gnd, SDA, and SCL. (I believe this is also called "party line"? My point is I am not intending to daisy-chain peripherals.) So from the JStamp to the farthest peripheral may be around 12-15", but as much as 30" of cabling altogether.

So back to the original question: Is an RJ-11 cable sufficient to connect these peripherals to the i2c hub in the power supply? Each peripheral will be built on PCB and enclosed in a project box, so the connections need to be easy to make and break without disassembling anything.

Also, my JStamp looks like it does SPI as easily/more easily than i2c. Any reason to prefer one over the other? It it seems that AVRs also tend to have SPI hardware built-in more often than i2c hardware. True? Maybe I'm barking up the wrong tree anyway.

Can bus

free implementation

Can is used quite heavily in cars. Also in next gen aircraft as Can over IP.

Can is built-in to quite a lot of micros. Microchip have some cheap 8 pin stand alone controllers MCP2510 which are fairly easy to use.

sell a cheap can kit

?ring=cancontrollerare Alex

I've been running my robot, Groucho, with an I2C network to communicate between my sensor controller (a MAVRIC-IIB) to my various Devantech sensors. I built a simple breakout board to provide the power supply and filtering and then just run cables.

I run a single cable (around 3' long) for the sonar units. Another cable goes out to the TPA.

Yes.

I use screw terminals when possible and AMP .1" IDC connectors when I must.

I have used both. SPI is *much* easier to bit-bang and I2C if you need both.

I use I2C because the Devantech sensors use I2C. Otherwise I would have stuck with the text-based RS-485 protocol I use for the communication to the Mini-ITX motherboard. This is a protocol created by Brian Dean for his own use that I, er..., borrowed. This protocol is called the Mojobus protocol and is very easy to implement and test.

I have no relationship to his business other than helping him test and break things (not physically, but initial firmware versions can do odd things when somebody other than its writer uses it). He produces good stuff.

-- D. Jay Newman

Robotics: Building Smarter Robots_ (soon to be released unto unsuspecting bookstores soon...)

Capacitances add when placed in parallel, so each time you add one of those star branches, the risetimes will slow.

SPI employs active drivers, rather than passive pullups, but it's not really made for party line operation. Namely, each SPI device usually requires its own unique chip-select line, to get it out of passive mode. So, 10 devices would require 13 lines total, Sclk + Sdo + Sdin +

10 CS.

To All involved:

These are great discussions.

The priorities of any project is what needs to done verses what you like to do.

Pushing a technology past its design limits is load of fun.

Getting a project working in a reasonable time is another.

I like KISs, Keep It Simple silly.

Use hardware instead of software, communications I feel should always hardware. Few chips has I2C native in the hardware. AVR is one.

I hope the OP has some good ideas for his project. I also hope the OP will keep us all informed on the status of his project.

Donald

SPI, while taking up more IO's, isn't necessarily a bad thing. If your going to be using, say, 8 spi evices, you can multiplex the CS lines. If your going to be sendingthe same data to identical chips, you can even select them all at once. Only works in the out direction though, and soemtimes thigns can get a bit screwy.

There are two reasons I would choose SPI over I2C. 1) Pretty much anyhing tha'ts made for I2C will hve an SPI version, and it seems theres alot more "goodies" out there that run on SPI than I2C. and 2) SPI is FAST. I've used I2C up to ~1.7mhz, SPI will go to 20mhz or more. If you need to move alot of data fast, SPI iu the way to go. If you want simplified connection, I2C is the way to go.

--andy P

dan michaels wrote:

Most PICs that have SPI also have I2C (using the same pins so it's pretty much one or the other).

Most I2C devices can be run off of a PC motherboard's SMBus.

That being said, I prefer SPI for short-range high-speed communications. However, I prefer RS-485 for inter-module communication.

-- D. Jay Newman _Linux Robotics: Building Smarter Robots_

12" should be no problem, we have a customer who use I2C for 10-150m signal in industrial enviroment. They sell many of them. And they use min. 100Kbit.

-Alex

I agree, if you need a cable longer than a few feet, use RS-485. I2C is fine though if you keep it under a few feet. The thing to remember is the longer the cable, the slower you should configure the I2C clock. Up to 10-20 feet should be fine @100kHz, it probably wouldn't be @400kHz. Also, the wiring is important. Check out the I2C specs: they talk about how to wire the 4 I2C conductors (Vcc, SCL, SDA, GND) on-board or with a cable to minimize cross-talk.