Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 358 replies
  • Subscribers 675 subscribers
  • Views 40013 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

  • mynameisJim wrote:

     

    Actually that's very much my point, non-compliant devices are routinely given the stamp of approval.  And non-compliant devices are really advertised as such.  The end result is that people plug a USB device into the pi expecting it to work like it should having no knowledge that it's not following the standard and then discussions about them arrise.

     

    You have my total support if a device is not USB-compliant and some people complain that Pi fails to support it.  Such devices fail the tacit agreement to follow specs, and the fewer of them that survive, the better.  Good riddance.

     

    But that uncompromising position on non-compliant devices (may they burn in ignomy) is matched with an equally uncompromising position on hosts that don't work correctly with fully USB-compliant devices, especially class-compliant devices in the most common classes.  Engineering is an iterative and evolving process and some things take time to get right, and that's OK, I can wait, and the devs are heading in the right direction.  But it has to be fixed.

     

    What gets short shrift from me (actually, zero shrift) is some people trying to scupper the very cool and useful engineering process of fixing things by claiming that the problem doesn't exist or doesn't matter.  This does not apply to you, since you acknowledge that there is a problem to fix.  That's the mandatory first step to solving it, and I'm always grateful to see it.  That's engineering.

Reply

  • mynameisJim wrote:

     

    Actually that's very much my point, non-compliant devices are routinely given the stamp of approval.  And non-compliant devices are really advertised as such.  The end result is that people plug a USB device into the pi expecting it to work like it should having no knowledge that it's not following the standard and then discussions about them arrise.

     

    You have my total support if a device is not USB-compliant and some people complain that Pi fails to support it.  Such devices fail the tacit agreement to follow specs, and the fewer of them that survive, the better.  Good riddance.

     

    But that uncompromising position on non-compliant devices (may they burn in ignomy) is matched with an equally uncompromising position on hosts that don't work correctly with fully USB-compliant devices, especially class-compliant devices in the most common classes.  Engineering is an iterative and evolving process and some things take time to get right, and that's OK, I can wait, and the devs are heading in the right direction.  But it has to be fixed.

     

    What gets short shrift from me (actually, zero shrift) is some people trying to scupper the very cool and useful engineering process of fixing things by claiming that the problem doesn't exist or doesn't matter.  This does not apply to you, since you acknowledge that there is a problem to fix.  That's the mandatory first step to solving it, and I'm always grateful to see it.  That's engineering.

Children
No Data