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

  • in reply to rdolson

    Robert Olson wrote:

     

    Do you have a recommendation for a real-time linux that works on the Pi?

     

    At this time I do not know of any real-time distributions specifically made for the Raspberry Pi which somewhat surprises me. I have just begun to contemplate building one myself but I do not

    know if or where I will find the time. First I need to check out http://www.xenomai.org to see how much effort it will take. I do know that real-time versions of Linux exists for ARM processors.

  • in reply to gdstew

    Gary Stewart wrote:

     

    The main purpose of the PRUs is to provide support for industrial real time communications protocols. Luckily they decided not to limit them to that purpose.

     

    ...

     

    I would also like to know if there are any assembly library functions to implement at least a rudimentary RTOS API available for use by the public. Given the status of the

    assembler itself at this time I assume the answer is no.

    I don't know how much RTOS you can fit into a PRU Core, which has only 8KB of program memory (2K instructions).

     

    You're right about the comm protocols.  An obvious application for PRUSS is some of the strange SCADA protocols used by some legacy units -- things like async with 32-bit words.  It's a PITA to implement some of these protocols in the main CPU, so PRUSS is a very attractive way to do it.

  • 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+

  • in reply to johnbeetem

    John Beetem wrote:

     

    Gary Stewart wrote:

     

    The main purpose of the PRUs is to provide support for industrial real time communications protocols. Luckily they decided not to limit them to that purpose.

     

    ...

     

    I would also like to know if there are any assembly library functions to implement at least a rudimentary RTOS API available for use by the public. Given the status of the

    assembler itself at this time I assume the answer is no.

    I don't know how much RTOS you can fit into a PRU Core, which has only 8KB of program memory (2K instructions).

     

    You're right about the comm protocols.  An obvious application for PRUSS is some of the strange SCADA protocols used by some legacy units -- things like async with 32-bit words.  It's a PITA to implement some of these protocols in the main CPU, so PRUSS is a very attractive way to do it.

     

    I don't know how much RTOS you can fit into a PRU Core, which has only 8KB of program memory (2K instructions).

     

    Yea, I know. I was hoping that would be covered under rudimentary. How about very rudimentary ? image They have to use something for the communications processing to handle the

    real time aspects but you're right it can't be much.

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

  • Using the PRU will limit your design to just one family of SOC's.

    If tomorrow a new SOC comes out with twice the speed for half the price of the TI chip, you won't be able to use it.

    Fine tuning Linux boot behavor to decrease startup times is again a very time consuming and fustrating job.

    Yes, 10000+ is a totally arbitrary number, but if the knowledge how to use a real time linux or posix kernel isn't available, it's hard to predict how long it will take to create a design with that technology, and I rather play on safe and avoid the risk.

    We probably both are right in our descisions based upon the products we create.

  • in reply to gdstew

    Gary Stewart wrote:

     

    You really need to get better acquainted with real time Linux.

     

    And you really need to stop attacking other forum members with personal remarks like this that don't advance the argument. Focus on the message, not the person delivering it.

  • in reply to shabaz

    shabaz wrote:

     

    You can achieve 20-50usec latency or less even with (say) 16MHz clock speed ancient

    CPU targetted OS's, so 100usec with Linux =  not so amazing latency figure to use as an example.

     

    Let's say you want to implement and test a new motor control algorithm for a

    DC motor - the 100usec latency you quoted won't help, wherease 20usec becomes actually quite useful.

    This is hardly an exotic example that I have chosen.

     

    I agree, 100us is pretty poor response latency for most realtime requirements, and the jitter isn't even quantified.

     

    Here's an interesting quantitive study comparing the performance of ordinary SuSE with realtime SuSE.  It highlights well how the realtime version can eliminate the very bad outliers beyond 400us, yet does nothing for response jitter which is still very noisy without the outlier spikes.  It also shows how the average response latency is increased in the realtime kernel compared to the average of a normal kernel's non-outlier responses.  It's just the high latency outliers caused by scheduler task switching that the realtime kernel eliminates.

     

    Hard realtime response doesn't just seek to reduce response latency, but also its jitter.  What's more, a common goal is to reduce jitter to effectively zero ("effectively zero" in this case typically meaning sub-clock period) by using edge detection on input and running a fixed set of instructions to deliver a fixed-latency response.

     

    Full operating systems can rarely achieve such high-quality realtime behavior, and realtime Linux certainly doesn't, whereas even a 50-cent microcontroller does it with ease.  The way to go is pretty clear if one's realtime application has any kind of strong realtime requirement.

     

    Morgaine.

  • in reply to Former Member

    Luc Cool wrote:

     

    Fine tuning Linux boot behavor to decrease startup times is again a very time consuming and fustrating job.

    It's not really so bad. You just need to start with the assumption that for something embedded you really don't want a full blown desktop distro on there. Once you're happy with making that decision you can get rid of a load of crap in the startup that's simply not necessary.

  • in reply to Former Member

    Regarding startup times, it's interesting to ponder that an AM3359 could in principle be made to initialize and preload its PRUs on startup even before commencing the Linux boot process.  This would give such an embedded system a near instant-start for many interfacing applications, delaying only the higher level processing until Linux has come up fully.