High rate serial data communication question

If I had two BBB devices sitting right next to each other, what would be the fastest way to send data from one to the other–excluding Ethernet?

Specifically, I’d like to be able to:

  1. Read data in from one BBB Ethernet port, send the data (unidirectionally) from one BBB to the other.

  2. Examine the data on the receiving BBB, looking for key words and deleting them.

  3. And then send the modified data back out via the Ethernet port on the second/receiving BBB.

To keep up with the 100Mb/s Ethernet pipe, I’d like to see data rates in the 8MByte/s range.

I’d love to hear even the most bizarre suggestions…

VR/John

I would use Ethernet. UDP packets if you don't care about losses.

On Sat, 9 Apr 2016 19:23:45 -0700 (PDT),
john.weed@triangleexperience.com declaimed the
following:

To keep up with the 100Mb/s Ethernet pipe, I'd like to see data rates in
the 8MByte/s range.

  Without special hardware? Oh, and do you really expect the Ethernet to
be fully saturated? If it is more burst-mode then having a sustained
inter-board transfer rate much lower may be feasible

  The 200MHz PRUs would only have time for two instructions per bit
transferred. The main processor likely has no chance if using the /sysfs
access method.

indicates that even the memory-mapped IO scheme only gets up to about
2.8MHz, which is still nowhere near the potential PRU rate (I'd think one
could get around 66MHz just toggling a pin in a tight [3 instruction] loop
-- faster if the assembly can do it in two instructions).

discusses using the SPI peripheral. And the problems in sustaining large
transfers.

  I was about to make some joke about using a pair of TIVA TM4C1294
launchpads configured for CAN, and letting the BBB sit there flashing
pretty lights (maybe wired up to the TIVA reset pins?); but CAN maxes out
at around 1Mbps.

high speed I2C : 3,2 Mbit/s

SPI UP TO 10 Mbps

UART SERIAL 921600 <--- I think the highest serial rate

So it looks like SPI is your highest data rate other than ethernet.

I Am not so sure that the BBB can keep with both interfaces saturated.

But only further testing will see if that is the case

I cant see any way to get 8MB on any of the other interfaces.

Maybe raw parallel data between the BBBs using GPIO pins.

The fastest interface would be McASP which can clock at 50MHz and with four channels channels will give you just under 200Mbps.

Regards,
John

Oh, and SPI can run up to 48Mbps.

Regards,
John

That's still only 1/2 of what he wants.

raw parallel data not faster ?

Well my guru friend on the BBB software side said that the best way
would be USB to USB on 2 beagle bones

seems its as fast as the ethernet connection

Running Ethernet over USB

He also told me there is no slave driver for spi in the Linux kernel so
thats a no go.

#1 SPI has no slave mode driver in the kernel, so SPI( including mcSPI ) is out of the question.

#2 McSPI is limited to 16Mhz in the current kernel config, So one would have to figure out how to modify that.

#3 I’ve read, and I can not remember where that the McSPI interface is actually far faster than 48Mhz.

#4 3Mbit is max speed for the UART if I recall correctly.

In terms of raw speed, the USB interface can be about 10% faster than ethernet when used as an ethernet gadget interface.

In terms of raw speed, the USB interface can be about 10% faster than ethernet when used as an ethernet gadget interface.

Also if I remember correctly, There is a post floating around on this group where I posted some iperf data concerning the USB g_ether driver. I seem to recall reads where ~116Mbit, and write were about 96Mbit. But thats going by pure memory on a subject I posted a long time ago.

Given that USB2 is 480Mbps, this might be the fastest interface, but given the overhead of the USB protocol, you might get 100Mbps if you are lucky.

Yep, you are correct, but if you do not use the SPI framework, it is pretty simple to create a slave SPI driver using DMA. A few days ago, I had a discussion with another developer who said he managed to modify the McSPI driver to support SPI slave mode using callbacks.

Regards,
John

#1 SPI has no slave mode driver in the kernel, so SPI( including mcSPI ) is out of the question.

See my previous answer on supporting McSPI slave mode.

#2 McSPI is limited to 16Mhz in the current kernel config, So one would have to figure out how to modify that.

I take your word for this as I haven’t looked into this. Not sure why the limit, because McASP driver does use DMA.

#3 I’ve read, and I can not remember where that the McSPI interface is actually far faster than 48Mhz.

I think you are correct, because I believe the AM3358 can support more than one data line, which is what the MMC uses.

On Sun, 10 Apr 2016 09:23:13 -0700, evilwulfie
<evilwulfie@gmail.com> declaimed the
following:

Maybe raw parallel data between the BBBs using GPIO pins.

  I hadn't visualized that, but for one-way traffic... If a PRU can get
access to 17 GPIOs, 16 of them adjacent, loading the adjacent 16 of them
with two bytes of data, then toggling the 17th as a data strobe, might be
feasible. Say a 50MHz net rate for loading 16-bit data and setting strobe
(~4 PRU instructions), end rate 800Mbps. Highly dependent on being able to
transfer 16-bit from memory to GPIO without needing to shift left/right...

Well, wiring 8 parallel bits from one PRU to the other PRU on the other Bone, plus a ready line and a strobe line, all using the dedicated PRU pins, I think you could probably get to 20 - 30 MBYTES/second, assuming some reasonable overhead in the PRUs. Not clear the ARMs could keep up, but that depends on how complex their task was.

Jon

Nope, they do not have 17 fast GPIOs out of one PRU or into another PRU. They do give you 8, however, which OUGHT to be enough. You could clock 8 bits across at insane rates. Probably 40 MHz is not unreasonable. Just give a clock cycle to allow data to settle, sample it and send acknowledge to the sender.

Jon

Well the fastest “interface” on the board is probably the GPMC which I’ve been told can achieve 40MB/s + BUT that’s not dealing with the external world as it were, which is what the OP needs.

The OP only needs around 8-9MB/s so, the best solution is probably using the USB interface, and one of the gadget drivers. Another option I had not considered before was using g_mass_storage. If one created a tmpfs file, this could potentially be the best options. But I’d have to talk with the OP at length to see what exactly the criteria calls for.