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

  • Engineering is about making decisions. If you intend to make 10000+ pieces of something, real time linux might be the way to go as it will reduce hardware and manufacturing costs. If you only need to make 5, the extra time you will need to learn about real time linux and it's possibilities divided by 5 likely will make your product more expensive. If I have experience with a microcontroller and if I already have tested libraries to make it do several tasks, I will likely develop faster using that instead of a PRU or a real time kernel.

    If for wathever reason the system will reboot, my microcontroller will be on track again within a second while my real time embedded linux will need 15 seconds to reboot. Every situation is different and therefore has a different approach which is best.

    So, an attendfull reader might have noticed that I have more designs that fall in the range 5 or less than I have designs that will be produced 1000+

Reply

  • Engineering is about making decisions. If you intend to make 10000+ pieces of something, real time linux might be the way to go as it will reduce hardware and manufacturing costs. If you only need to make 5, the extra time you will need to learn about real time linux and it's possibilities divided by 5 likely will make your product more expensive. If I have experience with a microcontroller and if I already have tested libraries to make it do several tasks, I will likely develop faster using that instead of a PRU or a real time kernel.

    If for wathever reason the system will reboot, my microcontroller will be on track again within a second while my real time embedded linux will need 15 seconds to reboot. Every situation is different and therefore has a different approach which is best.

    So, an attendfull reader might have noticed that I have more designs that fall in the range 5 or less than I have designs that will be produced 1000+

Children
  • in reply to Former Member

    Luc Cool wrote:

     

    Engineering is about making decisions. If you intend to make 10000+ pieces of something, real time linux might be the way to go as it will reduce hardware and manufacturing costs. If you only need to make 5, the extra time you will need to learn about real time linux and it's possibilities divided by 5 likely will make your product more expensive. If I have experience with a microcontroller and if I already have tested libraries to make it do several tasks, I will likely develop faster using that instead of a PRU or a real time kernel.

    If for wathever reason the system will reboot, my microcontroller will be on track again within a second while my real time embedded linux will need 15 seconds to reboot. Every situation is different and therefore has a different approach which is best.

    So, an attendfull reader might have noticed that I have more designs that fall in the range 5 or less than I have designs that will be produced 1000+

     

    I have already explained my position on this. However, just in case the short version is if you need a full fledged RTOS, you need a full fledged RTOS. If you

    need a bare bones RTOS, you need a bare bone RTOS. If you don't need and RTOS, well I think you get the point.

     

    The 10000+ is a totally arbitrary number, I'm sure there are smaller ones that it would also work well with. Your 1000+ number is probably one of the larger

    ones.

     

    The POSIX real time API is fairly common for free and commercial RTOS's so it would not be a Linux only learning experience and that may make it more

    worth the effort (just in case the day comes when you do need and RTOS).

     

    But if the PRU is already there and it will do the job why not make use of the resources you have instead of adding on parts and cost to every board you

    sell.

     

    There are several versions of Linux that boot in well under 5 seconds (1.2 sec. on embedded hardware is the fastest one I know of).