Re: [SLUG] TCP/IP over I2C

[David Lyon]

On Wed, Jun 5, 2013 at 9:39 AM, Glen Turner  wrote:

>
> The lack of two I2C ports on the RPi would be a practical reason. The sense
> of master and slave carries electrical implications, so a port can't change
> from one to the other without restarting the bus and all of its devices.
>
>
Actually the Raspberry-Pi does have two I2C ports. It's on the second GPIO
interface but doesn't have the pin header soldered in. It's available
providing
you don't mind doing a small amount of soldering.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[Glen Turner]

David Lyon wrote:
> 
> It's interesting that I2C is a actually a multi-master master/slave system.
> So there doesn't appear any theoretical reason as to why it wouldn't work.

The lack of two I2C ports on the RPi would be a practical reason. The sense
of master and slave carries electrical implications, so a port can't change
from one to the other without restarting the bus and all of its devices.

-glen
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[Kevin Shackleton]

Wouldn't Modbus be a more suitable framework for out-of-band management?
It's normally used over RS-485 "networks" - a single pair multi-drop
configuration with a single master.  It would have far lower overhead than
TCP/IP.  You might start at www.modbus.org/tech.php
.

Cheers,

Kevin.


On 4 June 2013 08:04, David Lyon  wrote:

> On Sat, Jun 1, 2013 at 5:30 PM, Chris Barnes  >wrote:
>
> > This one might be impossible but does anyone have any clues for running
> > TCP/IP over the I2C bus?
> >
> > I have a few Raspberry PIs and I'd like to create an Out Of Band network
> on
> > them by linking them all by I2C and then running TCP/IP over it.
> >
> >
> > Any suggestions?
> >
>
> It's interesting that I2C is a actually a multi-master master/slave system.
>
> So there doesn't appear any theoretical reason as to why it wouldn't work.
>
>
> Let us know the results if you get it working.
> --
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
>
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[David Lyon]

On Sat, Jun 1, 2013 at 5:30 PM, Chris Barnes wrote:

> This one might be impossible but does anyone have any clues for running
> TCP/IP over the I2C bus?
>
> I have a few Raspberry PIs and I'd like to create an Out Of Band network on
> them by linking them all by I2C and then running TCP/IP over it.
>
>
> Any suggestions?
>

It's interesting that I2C is a actually a multi-master master/slave system.

So there doesn't appear any theoretical reason as to why it wouldn't work.


Let us know the results if you get it working.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[Glen Turner]

On 03/06/2013, at 10:15 AM, Chris Barnes wrote:

> Wow thanks for that Glen.
> 
> Stacks of useful info. Given me a bit more to think about.

Personally, if I were building a cluster of RPis I'd use the serial
console for remote management. The main reason for that is that crash
information gets printed to the console.

I'd pull the RS-232 console pins back to a board, terminate them on the
Prolific RS-232/USB chips, connect those chips using a cascade of USB
hub chips, and present that to the management console (say, the USB port
of another RPi). It would see a /dev/ttyUSB__ per RPi. All this is low
speed stuff, so you could breadboard it.

You'd make all that sensible by using conserver .
Configure conserver to
 - record seen messages from each RPi to syslog.
 - enable the "console ..." command to allow you to connect to a particular
   RPi's console.

You can even set up sshd so that if you SSH to a particular service, then sshd
executes conserver's "console " command, allowing you to SSH
directly to the console of a particular RPi without touching the command line
of the management computer. In fact if you use IPv6 you can give each console
SSH its own IPv6 address.

That in turn means you could use one of the "parallel" SSH clients to issue
commands simultaneously to the consoles of all of the RPis. I wouldn't usually
manage the cluster like using ssh -- that's what Puppet is for -- but it is
very useful all of the same.

The other software you need to know about is collectd. This is how the 
management
platform does capacity planning for all of the machines in the cluster.

In your prototype of the cluster simply use retail parts rather than build a 
board:
 - a RS-232/USB dongle, with the RS-232 interface being 3.3V. For example
 

 - a powered USB hub, one from the list at
  

Density-wise, I'd see you building the rack by using a bespoke 2RU shelf
holding 46 RPis, each shelf including a 48 port 10/100 ethernet switch
with 1Gbps uplink. At the top of the rack you'd lose 3RU for the 5V
rectifier (which you'd drop down the rack using Cable TV power cable
and vampire taps into the power bus of each shelf); 1RU for a 24 port
1000 ethernet switch with four 10Gbps ports; 1RU for the management
platform (Intel server with 10GE interface) and its disks. That means
the 45RU rack hold 20 shelves of 46 RPi each, giving a cluster of 920
RPis per rack. Power draw would be about 6,500W per rack. The result
would be about 644,000 BogoMIPS.

For comparison the Supermicro FatTwin and a 10GE switch consumes 5RU,
2,000W for 896,000 BogoMIPS, and that includes 48 spinning disks.

-glen
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[Chris Barnes]

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

Re: [SLUG] TCP/IP over I2C

[Glen Turner]

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

Re: [SLUG] TCP/IP over I2C

[Jeremy Visser]

On 02/06/13 21:52, Chris Barnes wrote:
> Token ring would work.
> 
> Now, i wonder if anyone has already implemented token ring over i2c
> under linux.

Just for clarity, I meant ‘token ring *type* approach’, not token ring
itself. Perhaps ‘round robin’ would have been clearer.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[Chris Barnes]

Token ring would work.

Now, i wonder if anyone has already implemented token ring over i2c under
linux.
 On 02/06/13 10:01, Chris Barnes wrote:
> 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.

On the other hand, a token ring based approach may work here. You would
have one “master” that continually polls every I2C “slave” asking
whether it has any packets to send (and also delivering any packets
addressed thus).

Not an unfamiliar nor unsolved problem we’re talking about here.

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[Jeremy Visser]

On 02/06/13 10:01, Chris Barnes wrote:
> 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.

On the other hand, a token ring based approach may work here. You would
have one “master” that continually polls every I2C “slave” asking
whether it has any packets to send (and also delivering any packets
addressed thus).

Not an unfamiliar nor unsolved problem we’re talking about here.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[Chris Barnes]

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.


oh well, never mind.



On Sun, Jun 2, 2013 at 9:51 AM, David Lyon
wrote:

> The only issue that I can see is that I2C is a bus/master protocol. I know
> the Linux drivers support being the Master but I'don't know if it supports
> being a slave.
>
> So I'm not even sure if you could easily accomplish it without using extra
> hardware such as PIC/AVRs.
>  On 01/06/2013 11:11 PM, "Jake Anderson"  wrote:
>
>> Question 0 is do you really need tcp/ip?
>>
>> If you did I'd be looking to see if you can bind an i2c endpoint to a
>> serial port then running some sort of ppp server on it.
>>
>> On 01/06/13 17:30, Chris Barnes wrote:
>>
>>> This one might be impossible but does anyone have any clues for running
>>> TCP/IP over the I2C bus?
>>>
>>> I have a few Raspberry PIs and I'd like to create an Out Of Band network
>>> on
>>> them by linking them all by I2C and then running TCP/IP over it.
>>>
>>>
>>> Any suggestions?
>>>
>>>
>>>
>> --
>> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
>> Subscription info and FAQs: 
>> http://slug.org.au/faq/**mailinglists.html
>>
>


-- 
Kind Regards,

Christopher Barnes

e. chris.p.bar...@gmail.com
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[David Lyon]

The only issue that I can see is that I2C is a bus/master protocol. I know
the Linux drivers support being the Master but I'don't know if it supports
being a slave.

So I'm not even sure if you could easily accomplish it without using extra
hardware such as PIC/AVRs.
 On 01/06/2013 11:11 PM, "Jake Anderson"  wrote:

> Question 0 is do you really need tcp/ip?
>
> If you did I'd be looking to see if you can bind an i2c endpoint to a
> serial port then running some sort of ppp server on it.
>
> On 01/06/13 17:30, Chris Barnes wrote:
>
>> This one might be impossible but does anyone have any clues for running
>> TCP/IP over the I2C bus?
>>
>> I have a few Raspberry PIs and I'd like to create an Out Of Band network
>> on
>> them by linking them all by I2C and then running TCP/IP over it.
>>
>>
>> Any suggestions?
>>
>>
>>
> --
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: 
> http://slug.org.au/faq/**mailinglists.html
>
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[Chris Barnes]

hmm, probably dont NEED tcp/ip. would be handy though. I just thought if
someone has built an implementation i'd be keen to make use of it.



On Sat, Jun 1, 2013 at 11:11 PM, Jake Anderson wrote:

> Question 0 is do you really need tcp/ip?
>
> If you did I'd be looking to see if you can bind an i2c endpoint to a
> serial port then running some sort of ppp server on it.
>
>
> On 01/06/13 17:30, Chris Barnes wrote:
>
>> This one might be impossible but does anyone have any clues for running
>> TCP/IP over the I2C bus?
>>
>> I have a few Raspberry PIs and I'd like to create an Out Of Band network
>> on
>> them by linking them all by I2C and then running TCP/IP over it.
>>
>>
>> Any suggestions?
>>
>>
>>
>


-- 
Kind Regards,

Christopher Barnes

e. chris.p.bar...@gmail.com
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[Jake Anderson]

Question 0 is do you really need tcp/ip?

If you did I'd be looking to see if you can bind an i2c endpoint to a 
serial port then running some sort of ppp server on it.


On 01/06/13 17:30, Chris Barnes wrote:

This one might be impossible but does anyone have any clues for running
TCP/IP over the I2C bus?

I have a few Raspberry PIs and I'd like to create an Out Of Band network on
them by linking them all by I2C and then running TCP/IP over it.


Any suggestions?




--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[Michael Chesterton]

On Sat, Jun 1, 2013 at 5:42 PM, David Lyon
wrote:

>
> It's probably much easier to just use the network port that's already
> available on the Raspberry-Pi.
>

or maybe rs232, then you can use ppp.


>
> You could buy a hub/switch and some RJ45 cable and it would be done in a
> few minutes.
>
> One interesting benefit is that you could run USBIP which is USB sharing
> for Linux over
> TCP/IP. Something I've always wanted to try.


That will come in handy. I've got a dell/samsung(I think) printer connected
to my
odroid, which is arm. Unfortunately it seems to require a binary driver
which is
only available for i386 and amd64.

I tried using qemu to emulate i386, and with debian's multiarch support it
was surprisingly
simple to get going, unfortunately arm qemu is missing a piece of
functionality (futex) that
the binary driver needs. So usbip might be the way to go.

-- 
http://www.linuxsupportsydney.com.au
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[David Lyon]

Here's the link to that project:

 - http://usbip.sourceforge.net/
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] TCP/IP over I2C

[David Lyon]

On Sat, Jun 1, 2013 at 5:30 PM, Chris Barnes wrote:

> This one might be impossible but does anyone have any clues for running
> TCP/IP over the I2C bus?
>
> I have a few Raspberry PIs and I'd like to create an Out Of Band network on
> them by linking them all by I2C and then running TCP/IP over it.
>

It's probably much easier to just use the network port that's already
available on the Raspberry-Pi.

You could buy a hub/switch and some RJ45 cable and it would be done in a
few minutes.

One interesting benefit is that you could run USBIP which is USB sharing
for Linux over
TCP/IP. Something I've always wanted to try.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] TCP/IP over I2C

[Chris Barnes]

This one might be impossible but does anyone have any clues for running
TCP/IP over the I2C bus?

I have a few Raspberry PIs and I'd like to create an Out Of Band network on
them by linking them all by I2C and then running TCP/IP over it.


Any suggestions?


-- 
Kind Regards,

Christopher Barnes

e. chris.p.bar...@gmail.com
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html