To address both items at once:

My past experience with I2C is rather old... and pretty much limited to 
the port-expander and ADC/DAC hardware.  That experience pretty much got 
me thinking along the lines of each device has a hardwired address and 
there isn't much flexibility on most parts as to what addresses are 
available to you.   I've now corrected my thinking in that regards...

As far as how these are connected together...  These are devices which 
are intended to be din-rail (or wall) mounted right next to each other 
with a short, but pin-limited jumper cable between them.  I'm also 
providing power and ground via that jumper.   I figure the jumper will 
likely be a 6p6c or a 8p8c connector.  Right now, I'm toying with the 
idea of using power, ground, and data on a multidrop serial bus, and 
assigning each device a globally-unique serial number at manufacture 
time so that the probed order can be preserved from run to run.  The 
3-wire bus will let me use a 6p6c, but double up each pin so that I can 
use either "reversed" or "straight" 6p6c jumpers.

That said, I'm still open to ideas..

-forrest

Alan B. Pearce wrote:
>>> 5) Slaves should be able to be detected by the master, and should not
>>> have to have addresses set via dip-switches or other means.   Globally
>>> (factory set) unique addresses are ok (aka 1-wire style), dip-switches
>>> are not (aka i2c is not an option).
>> Nothing that you have said actually rules out I2C. If you use the
>> 'general call' address, you can discover the devices on the bus and
>> then dynamically assign an I2C address. In reality it depends almost
>> entirely on how dynamic you little network is, if it is highly
>> dynamic then this may result in a slow start-up each time.
> 
> That is my reaction also. You don't say how these devices are connected into 
> the network, are they in a card cage, separate devices connected by cables, 
> some other scheme? None of this removes the possibility of having an 
> appropriate number of pins on the connection plug that sets the device 
> address for that node, which gets around your dislike of dip switches.
> 
> The other possibility I thought of would be the CAN bus, which has a rather 
> different way of setting who receives what, but does have limited message 
> length, which requires a bit of thinking about to send long messages.
> 

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