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. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
