element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      • Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Raspberry Pi
  • Products
  • More
Raspberry Pi
Raspberry Pi Forum Combining BeagleBone and Raspberry Pi
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Raspberry Pi to participate - click to join for free!
Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 39 replies
  • Subscribers 678 subscribers
  • Views 7101 views
  • Users 0 members are here
  • raspberry_pi
Related

Combining BeagleBone and Raspberry Pi

morgaine
morgaine over 13 years ago

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.

  • Sign in to reply
  • Cancel
Parents
  • pholynyk
    pholynyk over 13 years ago

    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...

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • morgaine
    morgaine over 13 years ago 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.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Reply
  • morgaine
    morgaine over 13 years ago 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.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube