>> The issue though, is that I2C has a limited distance, though I
>> understand that at lower speeds, I can get more distance.
...
>I doubt that I2C will work at those distances. The main problems
>will be noise, and the capacitance of the lines (I don't have the
>I2C spec. handy so I can't tell you what the max capacitance is.)
>Don't expect I2C to work for more that a couple of meters. I have
>seen it work at upto three meters before.

There is no reason you couldn't run an I2C bus real slow (1KHz clock rate or
slower if you wanted), but I agree that there are various other items about
the spec that would probably make it less than ideal for this application.

>Olin's suggestion of using the CAN bus is a good one. I've only
>read about it, but it seems to do what you want.

That was my immediate thought too when I saw the request. The only potential
problem I see with it is that the message length is limited to 8 bytes per
block, so you need some way of concatenating blocks for a longer message.
However from the OP description I get the impression this would not be a
problem. Also has the advantage that you don't have a master device as such,
and you have priorities and broadcast capabilities.

>Myself, I would use RS-485 since I'm familiar with it. If you go the
>RS-485 route, look at the ltc1482 transceiver chip. It seems to be
>about the only transceiver that has a carrier detect function; this
>simplifies things a great deal.

Only disadvantage I see is that the handshake/priority handling is done in
software, where it is in the interface hardware for CAN, but you can have
longer messages.

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist