Pi vs BeagleBone-Black

In my personal opinion, the Raspberry Pi is better if you are going to be using GPIO a lot, however if you want a miniature computer to power your next project, I would go with the Beaglebone Black.

I have a Raspberry Pi, but I am interested in getting my hands on a Beaglebone Black.

Cheers

Hi Chris,

By video, do you mean still images, or video playback (i.e. H.264 and other codecs), or 3D rendering (e.g. computer animation)? For stills the BBB I think can achieve full HD (the 1024x1028 is a software limitation in some images - the BBB is still a very new product). For video playback, it's hard to say - I've not seen good performance with Youtube (I see many frames dropped) but possibly the libraries are not making use of the acceleration features today. H.264 ought to be possible. For 3D rendering, I've not had a chance to try out the 3D processor built-in (it's not something that currently interests me). But, I think I agree that overall for full HD, the RPI is more suited.

However, embedded apps may not require full HD.

For embedded apps with video, it is also possible to connect to LCD panels directly (the parallel video bus is brought out to pins on the connector) with the BBB. It allows cheap LCDs from handheld games/smartphones to be used.

For desktop apps, RPI is preferable, since it has full HD capability today - with the caveat that performance is low for running performance intensive apps. Still, it could be useful for kiosk style uses.

Regarding the Udoo device that you mention - I'm pretty familiar with some of the Atmel SAM family members (and I like them), however they do run at a slower speed than the PRU devices, and therefore you may end up still requiring additional hardware like a CPLD anyway. The PRUs are simpler than the SAM devices, and are useful for high speed interfacing (and there are two of them), but they also integrate extremely well to the main processor - no need for an API, so you get high-speed interfacing using shared memory. Apparently there is work going on to create an API too.

For battery-powered use-cases (likely in many embedded apps) the BBB is ideal too - it has a built in Li-Ion battery charger.

If the requirement is small, there are lots of lower cost Atmel boards, or a FRDM board, and for more powerful use-cases I'm currently using the BBB. For other use-cases I'm currently using servers :-)

The Udoo looks great too, but I'm just not ready for it - if I needed the additional capability of a SAM co-processor, I would personally add it using a tiny daughter card, at very low cost. There are also CPLD add-ons for the RPI for example (See Guzunty Pi). Also, at the cost of the Udoo, I couldn't have them in some applications.

Hi Joshua,

If you are using GPIO a lot, then the BBB is the better choice, due to the fact that

(a) there is more GPIO on the BBB

(b) there is faster GPIO (way faster - up to 200MHz) on the BBB

Chris Melville wrote:

 

However I prefer to pick one (reasonably priced) board for all the projects I have in mind. I don't want to have to learn and support multiple board personalities, idiosyncracies and programming/operating environments. Nobody has argued that angle.

I very much agree with that. Standardising on one board has all sorts of advantages. However, at this point if whatever board you choose has at least a Cortex A7 then a much wider range of options are available and your environment can be largely identical across different boards.

In my search for such a board I've discounted RPi (weak ISA, too many idiosynchracies) and, sadly, also BBB due to its pathetic video (apparently it isnt considered 'cool' here to have media/video applications in mind, but I do).

I'd argue that we're just a bunch of engineers who don't place so much value on 'cheap media center' capabilities as others do, and we've seen the focus on media capabilities continually distract the likes of the RPF from other areas.

I could settle for BBB if there were ever likely to be:

 

1) a "proper HDMI" shield, ie. providing 1080p with h/w acceleration for H264 etc.  

doubtful, you're essentially talking about an add-on video card / GPU. Don't know that the am3359 has an appropriate high bandwidth interface for that, or that the BBB makes it available on an expansion header.

The BBB can do 1080p30 with sound, or seemingly 1080p60 without sound. The limitation is the hardware 125MHz pixel clock plus some driver development to allow selecting modes without sound.  It's on-chip GPU doesn't have the hardware to do h264 decode though.

As for UDOO, it looks like it could be interesting, but too little detail so far.  Until it's released and available to buy locally I'd find it hard to bet on it being the one.  There have been several instances where the choice of distributors mean that a headline US$100 price tag in one country translates to US$300 in a different country. So even if the hardware is perfect, at what point do you decide it's not economic.

As you've said, you could get what you want from a BBB+RPi combo, so why not a Sabre-Lite+Arduino Due ?  Or Arduino Due+RPi ? Lots of ways to come to a result that meets your requirements.

There's a fair bit of info available on the i.MX6 on the UDOO as other boards using it have been abailable for some time.  As with anything it's worth doing some research there, especially if media uses are important to you - it seems that the kernel with the appropriate GPU drivers is stuck at 3.0.x and that appears unlikely to change anytime soon, so you need to decide if things like that are important to you or not.

A good place for i.MX6 info is the boundary devices blog http://boundarydevices.com/blog/ the top entry is currently "GPU Acceleration on Freescale Ubuntu" with some details of how acceleration wasn't working..  The comment to the post is interesting too with everyone moving to hard-float and the closed source libraries required for acceleration still being soft-float.

To be fair, video/gpu acceleration is always going to be a difficult issue due to their mostly proprietary and closed nature. So if video is important to you, be sure to verify that you'll actually be able to use it and what limitations it may impose on your environment.

You're almost tempting me into creating a huge table with boards on columns and  features required by specific applications on rows.  It should be enough to use 0-9 as rough estimates of degree of support provided by each board, coresponding cell colouring from red for 0 to green for 9 (low saturation to keep the numbers visible), and a final expandible row and column for board notes and app notes respectively.

App areas and features are more numerous than embedded boards with application processors, so this is probably the right way around.

shabaz wrote:

 

possibly the libraries are not making use of the acceleration features today. H.264 ought to be possible.

Well we know that the 'gpu' on the BBB is pretty basic and that it has virtually no acceleration features. So H264 in software on the Arm then ?

Vastly more capable and more power hungry processors have struggled with software h264 implementations, so I'd not expect Arm to fare any better and if it did you'd expect that to be a significant marketing point.

Horses for courses, really.  I'd tend to use Pi for media applications, BBB for hardware interfacing and basic networking, and neither of them if the application would perform better with gigabit networking or high speed disk access using SATA.

Trying to force a board to perform well in an application for which it isn't naturally suited is not the best approach, and being wedded to just one board or one manufacturer means that one can't take advantage of the wide range of choices available.  This is one reason why I quite regularly try to combat fanboism --- it prevents fair assessment of alternatives from being made.

Alternatives are good.

I'd read that there were some NEON instruction optimised libraries for H.264, but unfortunately I'm not familiar with them. Possibly they could just be for some standard-definition or smaller sizes of video. But your point stands - for much typical video playback use, the BBB is not appropriate.

Regarding the GPU, is there much information on it? I've not known how good/bad it is (I was going to try compiling some demos to try it out but it's been a low priority - I'm more interested in simple 2D for GUIs, which doesn't need high performance).

@Morgaine

The "instant gratification" referred to the use of Linux on the host application processor, not to the programming of its embedded cores

Must have been the at the same time part. As you yourself explain they must be programmed to use them with the "instant gratification" Linux part. And the "instant gratification" Linux part must be

programmed too. None of this programming happens in an instant.

I wrote:

Very tight real time response is not always needed so why would you waste hardware (and money) to get something you don't need ? Your one size "use hardware, don't compromise" fits all is the epitome

of bad engineering. Sometimes RT Linux will work, sometimes it won't. Why, in the face of lots of evidence to the contrary (it's being used every day in real world research and commercial applications,

even NASA uses it) do you keep insisting that it won't ?

No rant or irrelevancy here, just facts. Why won't you answer the questions (rhetorical) ? There was only one "attack" and it was on your failure on several occasions past and present to simply acknowledge that

there are applications where RT Linux does work instead of "just say no". As always when you get questions you would rather not answer your response is to attack the message and the messanger. Fine.

@ shabaz

I wrote:

Sometimes RT Linux will work, sometimes it won't.

This is not an opinion and I have always framed my arguments around that. You always respond with cases where it won't. They do not in any way negate cases where it will.

 

Gary Stewart wrote:

 

This is not an opinion

I didn't say it was. I said the link was to your opinion - and in fact your first sentence at that link is

"You really need to get better acquainted with real time Linux." - That's your opinion.

Gary Stewart wrote:

 

You always respond with cases where it won't. They do not in any way negate cases where it will.

I think you're right; because these are precisely the cases I'm hitting. If you're hitting cases that you can solve with 100usec latency, then this is great too.