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

Pi vs BeagleBone-Black

Former Member

So, just over a year on from the initial availability of the R-Pi and the new BeagleBone Black is upon us.  They've obviously taken a leaf out of the RPF's playbook and produced a cost reduced version at a price only marginally above the Pi.

 

I find it interesting that the compromises are very different, for example there's a proper PMIC and the ethernet is not troubled by being connected to USB, however the on-board HDMI seems less capable.

 

Other differences are in the documentation, I'm currently viewing the pcb gerbers for the beaglebone..  Have yet to see any sign of those for the R-Pi a year later. There's even an up to date devicetree capable kernel too.

 

Technology has also moved on somewhat, we get a 1GHz Cortex A8 which is better than the Pi, along with various other stuff and lots more GPIO's too.

 

Ok, so it's clear that I like the look of the new beaglebone, and given the price I'm likely to put any further R-Pi plans on hold until I have a chance to play with this. It's also making things like the Olinuxino-maxi I bought recently look very slow/expensive while still being cheaper than the similarly specced Olinuxino-A13

 

Some details of the beaglebone-black here http://circuitco.com/support/index.php?title=BeagleBoneBlack

 

What do the rest of you think ?   I don't expect this to displace the Pi anytime soon, but I expect it to be very attractive to those people who don't simply want to put XBMC on it and duct tape it to the back of the TV..

Parents

  • Morgaine Dinova wrote:

     

    selsinork wrote:

     

    Personally I'm reasonably happy with the line being at the hardware as long as the hardware is documented well enough to allow the software to be written to use the hardware. The flaw in my idea comes when the 'hardware' really isn't hardware but is something implemented in software pretending to be hardware. You now have a blurry grey line instead of a nice crisp one.

     

    It's not a blurry line as long as the following test can be applied to it:  "Is it field-programmable?"

     

    Hardware/software/firmware/donutware are all immaterial in this regard.  The acid test is whether it's possible for the device to be reprogrammed in the field by anyone at all.  If a binary blob can reprogram it, then so can a user if the programming information is available.  This rule is simple, easy to understand, and clear to apply.

    Indeed it is a simple rule, and comes right back to what I've been saying, if the foundation made it such that the GPU was controlled via an EPPROM and could only be updated by flashing it, then by the definition you supplied the Pi would become more open source by becoming less controllable by the end user.  If removing access to features increases how open sourced it is then there is a fatal flaw with the standard.

     

    >No we don't need a "weighted average".  It's either fully open or it's not.  You can't be partially pregnant.

     

    True, but you can be partially through a pregnancy, or to follow through on the concept of openness, a door or a window can be partially open.  Which is why I'm saying we should recognize how open a product is with a weighted average.  Such that a board that had 5 items that were closed could be considered more open than a board that only had one thing that closed provided the 5 things were of lesser importance.  Or to be more direct, if both boards only have the GPU closed, then the board which provides a higher amount of access to the GPU would be the more open one

Reply

  • Morgaine Dinova wrote:

     

    selsinork wrote:

     

    Personally I'm reasonably happy with the line being at the hardware as long as the hardware is documented well enough to allow the software to be written to use the hardware. The flaw in my idea comes when the 'hardware' really isn't hardware but is something implemented in software pretending to be hardware. You now have a blurry grey line instead of a nice crisp one.

     

    It's not a blurry line as long as the following test can be applied to it:  "Is it field-programmable?"

     

    Hardware/software/firmware/donutware are all immaterial in this regard.  The acid test is whether it's possible for the device to be reprogrammed in the field by anyone at all.  If a binary blob can reprogram it, then so can a user if the programming information is available.  This rule is simple, easy to understand, and clear to apply.

    Indeed it is a simple rule, and comes right back to what I've been saying, if the foundation made it such that the GPU was controlled via an EPPROM and could only be updated by flashing it, then by the definition you supplied the Pi would become more open source by becoming less controllable by the end user.  If removing access to features increases how open sourced it is then there is a fatal flaw with the standard.

     

    >No we don't need a "weighted average".  It's either fully open or it's not.  You can't be partially pregnant.

     

    True, but you can be partially through a pregnancy, or to follow through on the concept of openness, a door or a window can be partially open.  Which is why I'm saying we should recognize how open a product is with a weighted average.  Such that a board that had 5 items that were closed could be considered more open than a board that only had one thing that closed provided the 5 things were of lesser importance.  Or to be more direct, if both boards only have the GPU closed, then the board which provides a higher amount of access to the GPU would be the more open one

Children
No Data