Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 39 replies
  • Subscribers 709 subscribers
  • Views 8787 views
  • Users 0 members are here
Related

Combining BeagleBone and Raspberry Pi

morgaine

Well I finally couldn't wait any longer for an ARM Linux board (my Pi isn't due until the end of June), so I bought a BeagleBone. image

 

(This post is about technology.  I am not interested in "A is better than B" arguments.  Horses for courses.)

 

It's a very nice board, much more like an Arduino in concept than a Pi -- the two rows of female headers give it that feel.  Farnell provided their usual (in my experience so far) perfect quality of service and delivered it the very next day --- http://uk.farnell.com/circuitco/bb-bone-000/kit-dev-beaglebone-cortex-a8/dp/2063627

 

The power design is particularly noteworthy, given our recent discussions about polyfuses.  The BeagleBone uses a TPS65217B power management IC (PMIC) to generate stable supply voltages regardless of input power, which can come from a barrel connector or from the mini-USB.

 

The mini-USB itself deserves a mention, as it's impressively multi-functional.  In addition to being an alternative source of power, it provides a front-end two-port USB client-side hub --- this is entirely unrelated to the separate host-mode USB type A socket which is also available.  One port of this hub goes directly to the TI AM3359 SoC, while the other port connects to a dual-port FT2232H USB-to-serial converter to provide user-host communications (Linux console by default) and JTAG debugging simultaneously.

 

The SoC USB connection to the front-end hub works in one of two modes which can be toggled at will at any time:  it either presents the SD card as a mountable USB storage device to the host, or it provides an Ethernet-over-USB networking interface which yields an extremely simple quick-start.  (This is additional to the BeagleBone's normal 10/100 Ethernet interface, which is directly implemented in the SoC rather than hanging off USB.)  It all worked immediately using my Gentoo machine as host, providing full IPv4 and IPv6 connectivity out of the box.

 

Which brings me to BeagleBone and Raspberry Pi.  These two devices are very different, enjoying different strengths and suffering different weaknesses, and their most appropriate applications would naturally fall in different areas because of these differences.  I'm interested in how the best features of each could be combined to provide better functionality than either does alone.

 

I already have one idea in this area.

 

The BeagleBone doesn't provide an on-board graphics interface (despite its SoC containing a PowerVR GPU), and as a result, if you want direct graphics you have to buy a "DVI-D cape" containing the interface circuitry ("cape" == BeagleBone daughterboard).  The trouble is, that cape costs more than a Pi Model B!!!! imageimageimageimage

 

Which of course provides an ideal opportunity to combine BeagleBone and Pi, since the Pi could handle the graphics side while the BeagleBone does most of the computing which suits its Cortex-A8 nicely.  I'm currently thinking what the best way to achieve this might be, but one simple way is available out of the box since X11 is inherently a networked protocol.

 

This is obviously just the beginning, and I'm quite excited to see where this combination might lead. image

 

Morgaine.

  • in reply to pholynyk

    Thanks for posting that NYT link, I got a kick out of it:

    "Altoids have always been what we call a curiously strong lifestyle accessory," Mr. Peddy said.

    Also, interesting to see a young Ladyada without dyed hair.

  • in reply to fustini

    @Drew: I don't know.  Creating per-product groups is somewhat instinctive, but part of me worries about it because so much of what we do is to combine products and interoperate between them.  That's how we achieve the best functionality.

     

    Plus, individual groups tends to feed the fanbois ... you can imagine how discussing the BeagleBone would go down on the Raspberry Pi forums.  In fact, one of the RPF admins threatened to lock a thread in which we had mentioned the Allwinner A10 .... go figure.  Fanbois live on a different planet to engineers.  And power corrupts, so when fanbois are also admins, balanced engineering discussion doesn't even get in through the door.

     

    Not an issue on Element 14, thank the FSM. image  Engineering FTW.

     

    There is also the fact that the BeagleBone community is a bit ill-disposed to new forums --- see https://groups.google.com/forum/?fromgroups#!topic/beagleboard/j_rybEhIRY8  .  I'm not too sure why, but it's probably that the community is small enough that fragmentation is actually a real issue.  Grrrr ... I wish the BeagleBone cost $35 so there would be millions of them around. image

     

    Morgaine.

  • Back to the original topic for a bit... I think if you want to use the RasPi and BB as coprocessors you will need a fairly high bandwidth message passing connection. I think that will mean using the Ethernet rather than I2C or SPI, even with all the E'net overhead. You'd really like a parallel bus, (memory bus?) but then you could just implement QNX as an Asymmetrical MultiProcessor OS image (I love QNX, a great synchronus message passing micro-kernel OS).

     

    So using the RasPi as an X-display is a really quick and dirty approach that should probably work right out of the shipping box(envelope?). And I don't even need a BeagleBone to test it - I can make my TV a remote display for my desktop Linux box. Lean back and relax, ahhh!

     

    I'm not familiar with OpenCL, so I don't know how much data needs to be passed to make good things happen. I guess I should go off and Google it...

  • in reply to morgaine

    @Phil: Haha, a curiously informative article from NYT --- thanks! image

  • in reply to morgaine

    Ah, thanks for the google group tip - just signed up.  I can see your points, so I'll hold off for now.  I think I'd likely post in my blog about BeagleBone progress and discuss, when not related to the Pi at all, in Embedded Linux or Open Source Hardware

  • in reply to pholynyk

    @Phil: As the engineering mantra says,

     

    • "What you don''t measure, you don't really know, even when you think you do."

     

    So my approach would be to first implement coprocessor interfaces using existing pathways, be they SPI, I2C, Ethernet or USB, then to instrument those pathways, and finally to let the numbers speak and tell us where the bottlenecks are.  Then we'll know whether there is any point in optimizing the data paths, and where.

     

    If there is a major comms bottleneck for common workloads then that's not too hard to solve with dual-ported RAM sitting at the coprocessor boundary, or more ambitiously with scatter-gather controllers on each side to avoid copying data altogether.  Not rocket science, but admittedly a lot of work. image

     

    Morgaine.

  • This client-mode USB port and hub on the front-end of the BeagleBone is really an exceptional idea, makes the board amazingly flexible as I described in the opening post.

     

    It makes me wonder whether some ambitious Pi hacker could route the unconnected pins of the Pi's micro-USB power socket through level translators to the Pi's GPIO header, and bit-bang up a client-mode USB interface for the Pi. image

  • in reply to fustini

    BTW, what do you think of adding a BeagleBone group?  I've wanted to post about it before but wasn't sure what was the best fit.  Embedded Linux or Open Source Hardware are probably the closest.  I have one on the way so will be posting more, and it sounds like you have some interesting ideas, too.

    I'd avoid an element14 BeagleBone group at this time... there doesn't seem to be enough of a critical mass, and Google's BeagleBoard group (which includes BeagleBone) is a good place for general Beagle questions.  I've been a member since August 2008.  Most of the software questions with BeagleBoard are also relevant to BeagleBone, and I expect a lot of members have both.

     

    I'd keep posting BeagleBone related things here with some sort of real or made-up connection to RasPi.  If somebody complains, revisit.

     

    If you're new to BeagleBone, there's an interesting and sometimes amusing thread there about competition between RasPi and Beagle: "Can TI compete with Raspberry Pi?"  Here's a link to the thread, centered at a classic joke I adapted to the RasPi availability situation.  One nasty feature of Google Groups threads: if 60 days pass without a post, the thread can no longer be updated.

  • in reply to morgaine

    This client-mode USB port and hub on the front-end of the BeagleBone is really an exceptional idea, makes the board amazingly flexible as I described in the opening post.

     

    It makes me wonder whether some ambitious Pi hacker could route the unconnected pins of the Pi's micro-USB power socket through level translators to the Pi's GPIO header, and bit-bang up a client-mode USB interface for the Pi. image

    Looking at the hardware alone, it seems to me that the best way for RasPi to talk to BeagleBone (or BeagleBoard) is to use one of RasPi's host ports to talk to Beagle through its USB device (or OTG) port.  With Ethernet you're going through the USB-to-Ethernet conversion in the RasPi's LAN9512.  If you use USB directly you've eliminated the middleman and can use full USB bandwidth.  (Peak USB 2.0 data rate = 480 Mb/s.  "Peak data rate is a guarantee from the manufacturer that you won't go faster than this.")

     

    The difficulty, of course, is the software.  I don't know how difficult it is to write suitable host and device USB interface code.  My 1-2 year plan includes learning how to write my own USB software, in user space code and/or bare metal embedded.  The plan does not include becoming a Linux kernel guru.

  • in reply to morgaine

    Morgaine Dinova wrote:

     

    Isolating your circuit from the metal is indeed one issue, but another stems from the fact that tin is not an easily workable metal.  Radio amateurs love metal for shielding of course, but even they rarely use commercial tins because tin is so hard to work compared to aluminium, and commercial tins are always thin and flexy, and the thinness actually makes them harder to modify.  Flexible thin sheet metal is just plain annoying.

    BeagleBoard and BeagleBone have mounting holes, so you can isolate using stand-offs.  Regarding thin metal, I'm told that the best way to work it is with a very sharp awl or strong needle.  You make a series of very closely spaced pin holes and then you can break off the scrap metal.  Much more reliable than drilling.