Wow thanks for that Glen. Stacks of useful info. Given me a bit more to think about.
I wasnt intending to run the PIs too far apart. At the moment i have them in cases but i was hoping to throw them into an enclosure like a blade system (minus the hot-swapability) or like the Pi clusters you see where they are mounted close together, and I was hoping to daisy chain the gpio headers but if additional logic components are going to be needed then my approach might not work so well. might do some looking into REST over CoAP and see where that takes me. Thanks again! On Mon, Jun 3, 2013 at 10:26 AM, Glen Turner <[email protected]> wrote: > > On 02/06/2013, at 9:31 AM, Chris Barnes wrote: > > > yeah. > > > > come to think of it. the whole master/slave process of I2C would probably > > make it terribly difficult to implement tcp/ip since each device would > have > > to be able to switch from slave to master to be able to send broadcasts > > like arp requests, netbios name requests, etc. Otherwise the slaves can > > only send data in response to a request from the master. > > I2C slave support depends on the particular I2C driver. It isn't very > common and won't be in a mainstream kernel. As for the master/slave issue, > that's easily solved if designed in from the start as I2C is a multi master > system so you give those particular nodes both master and slave functions. > Of course the RPi has only one I2C port. > > There's not much call for IP over I2C as the I2C bus has a maximum > capacitance of 400pF. That's a couple of metres. Also, the value of the > pull-up resistors will vary with the capacitance (ie, cable length), and in > this high capacitance environment you'll want to use an active I2C > terminator. This is all easy enough to arrange on a PCB, but gets > problematic when using cabling and you're starting to talk daughterboards > to hold all of this additional logic, not just connecting one RPi to > another. > > What you'll often find on PCBs is I2C used for simple devices and a USB > hub used for complex devices. For example the RPi itself uses USB to attach > its ethernet port. USB brings device enumeration, peer operation at the > protocol level, device profiles and so on. > > The RPi is a mobile phone CPU. So its I2C is really focussed at firmware > downloads to the radio devices, a simple power-on self test (enumerate that > the devices which should be reachable are in fact reachable), and > commanding FPGAs and devices (such as bringing the transmit amplifier > online) > > ----- > > IPv4 works fine on broadcast-less media, that was it's original use. In > this case you'd hardcode the I2C link layer address and it's corresponding > IPv4 address. In the GPIO case you don't care about the address at the > other end of a point-to-point link, stuff which is addressed for your > subnet but which is not the null address or your address needs to be > transmitted. In the USB case there's an adaption protocol (CDC or RNDIS). > > IPv6 is simpler, you'd just include the i2c address in the lower bits of > the IPv6 address. > > What you usually do isn't to run IP cover I2C, but to run IP to > lightweight controller software, which then bangs the I2C bus. There's a > special web-like protocol: REST over CoAP over IPv6 which is focussed on > being easily proxied from a full REST/HTTP/TCP/IP. -- Kind Regards, Christopher Barnes e. [email protected] -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
