Interprocess communication between 2 BeagleBones

Hi,

We have two groups using a BeagleBone to acquire some data and do some number crunching. In future these two programs shall exchange data.

What would be the best interface when short latencies are desired. The amount of data is comparably small, so bandwidth is not an issue. The two possibilities I came up with so far would be either SPI or Ethernet. As far as I understand, the SPI-interface would be faster in terms of response time, but I am not sure how I would set up the thing as SPI is a master/slave protocol. Would it be possible for the slave-BB to initiate data transfer to the master-BB?

Regarding the Ethernet, it seems to be straight forward to use a short cross-over cable and open a socket connection, so atm I feel closer to that solution.

Any suggestions are very welcome. Also I could not find much about connecting to embedded (Linux-)boards via SPI, but I am sure that it has been done before, thus I would be thankful for any reference or keywords.

Best regards,

Jan

Not knowing the exact details of what you are trying to do, the data rates, and the acceptable latencies, but my first approach would be to use Ethernet. This gives you scalability (i.e. it is easy to add other i9nterfaces for the ata), as well as a much easier time developing your application (i.e. use any network virtual machine to develop the application and port it to the Beagle once it is fully working. You also have all of the networking capabilities readily available to you (i.e. sockets, RPC, etc.)

Obviously, you could use SPI, but there, it’s harder to expand and may also be harder to develop the protocol and test the software.

Not knowing the exact details of what you are trying to do, the data rates, and the acceptable latencies, but my first approach would be to use Ethernet. This gives you scalability (i.e. it is easy to add other i9nterfaces for the ata), as well as a much easier time developing your application (i.e. use any network virtual machine to develop the application and port it to the Beagle once it is fully working.

I see your point. Do you have any suggestions which protocol would be the most suitable considering a direct connections (<30cm) with a cross-over cable? I haven't worked with sockets yet (only interthread communication an low-level periphery). I only have heard of TCP/IP, but this may be overkill?
I will have to search for a good book about sockets in Linux.

You also have all of the networking capabilities readily available to you (i.e. sockets, RPC, etc.)

Obviously, you could use SPI, but there, it's harder to expand and may also be harder to develop the protocol and test the software.

Just remembered that also UART could be a very simple option. Problem would be that I would need to create my own protocol in order to recognize transmit errors. Sockets already guarantee that the data I send from BB1 is received at BB2?

Not knowing the exact details of what you are trying to do, the data
rates, and the acceptable latencies, but my first approach would be to use
Ethernet. This gives you scalability (i.e. it is easy to add other
i9nterfaces for the ata), as well as a much easier time developing your
application (i.e. use any network virtual machine to develop the application
and port it to the Beagle once it is fully working.

I see your point. Do you have any suggestions which protocol would be the
most suitable considering a direct connections (<30cm) with a cross-over
cable? I haven't worked with sockets yet (only interthread communication an
low-level periphery). I only have heard of TCP/IP, but this may be overkill?
I will have to search for a good book about sockets in Linux.

In this case you might consider some higher level communication
libraries which will help with tedious and error-prone low-level
socket programming. For example ACE
http://www.cs.wustl.edu/~schmidt/ACE.html , Boost ASIO
Boost.Asio - 1.53.0 or POCO
http://pocoproject.org/documentation/index.html just to name some. In
our project we were using ICE http://zeroc.com and are very happy with
it.

Regards,
Andrey.

web: http://veterobot.org
twitter: @veterobot

I am somewhat new to BB, but did a fair amount or Arduino in the past. I nearly always used serial IO at TTL levels between boards for small amounts of data. Just make sure they have a common ground. You would have to write your own protocol from scratch, but that is not that difficult (examples are easy to find). At that distance, the error rate for serial data at fairly high speeds is extremely low and since you say the amount of data is small and bandwidth isn’t an issue, sending it at 115k or even 38.4k to be really rock solid would probably meet your needs.

If a wireless solution works better for you Xbee radios are pretty simple. I’m considering make up capes for these, but you can do this pretty easily with proto cape and an Xbee adapter to go to correct pin spacing. Several libraries are available for this too.

Not knowing the exact details of what you are trying to do, the data
rates, and the acceptable latencies, but my first approach would be to use
Ethernet. This gives you scalability (i.e. it is easy to add other
i9nterfaces for the ata), as well as a much easier time developing your
application (i.e. use any network virtual machine to develop the application
and port it to the Beagle once it is fully working.

I see your point. Do you have any suggestions which protocol would be the
most suitable considering a direct connections (<30cm) with a cross-over
cable? I haven't worked with sockets yet (only interthread communication an
low-level periphery). I only have heard of TCP/IP, but this may be overkill?
I will have to search for a good book about sockets in Linux.

In this case you might consider some higher level communication
libraries which will help with tedious and error-prone low-level
socket programming. For example ACE
http://www.cs.wustl.edu/~schmidt/ACE.html , Boost ASIO
Boost.Asio - 1.53.0 or POCO
http://pocoproject.org/documentation/index.html just to name some. In
our project we were using ICE http://zeroc.com and are very happy with
it.

Another option to consider can be USB.
Its a loss less standard and Beagle supports OTG mode - so one board
is host and other is device.
So the host sees the device as a say mass storage :slight_smile:

Is it possible to do with current beagle, i am not sure since it has
some FTDI chip attached the only otg port - but a board mod can get
you this configuration pretty easy.

These frameworks look very interesting, especially as some are also offering nice APIs for multithreading. I think I will be busy the next days digging through the documentation.
Thank you very much for ruining my weekend ;-).

Best regards,

    Jan

I think a wireless solution is not feasible. Besides the fact that we need to buy two adapters, I assume it will introduce more latencies than a cable based solution. To me it would also look a bit to geeky to use a wireless connection for two BB less than 20 cm apart ;-D

Best regards,

    Jan

Fair enough. Didn’t know how much distance you had between devices. Definitely ethernet or SPI sounds better for your case.

These frameworks look very interesting, especially as some are also offering
nice APIs for multithreading. I think I will be busy the next days digging
through the documentation.
Thank you very much for ruining my weekend ;-).

Ha-ha :slight_smile: Just to finally kill your weekend, I want to mention that
actually all of them are offering threading API. ASIO as part of boost
could benefit from
Chapter 30. Thread 4.0.0 - 1.53.0 and all the
other mentioned frameworks have their own portable threading API.

Regards,
Andrey.