Pi vs BeagleBone-Black

Hello everybody, newbie here. Well newbie to the Pi/Beagle/Arduino/RT Linux world, not to embedded software engineering generally - cut my teeth on embedded 8086/ASM-86/PLM-86/iRMX systems 25 years ago, have written many a line of heavily multithreaded C/C++ on embedded and server systems, and have enjoyed knocking out the odd dual-6502 system for educational purposes. Ah those were the days, before we all got sucked into PC programming.

But I'm rusty and looking to have some fun with ARM.

So...my 2 cents on this discussion:

Some say you should pick the best hardware/OS for the individual job at hand, and favour using a dedicated CPU for hardware interfaces. 

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, idiosyncrasies and programming/operating environments. I can accept that that will sometimes mean shoe-horning a square board peg into a round application hole. Nobody has argued that angle.

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

A real contender (albeit at double the cost) seems to be this. I wondered if the dedicated back end microcontroller advocates have seen that and have opinions.

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.  

2) a coprocessor shield, such that either the BBB or shield could be the front end hard RT coprocessor with the other one being the application processor.

As long as said shields cost less than the base BBB board. Given that an RPi Model A (=$25 as is) could do the functionality, that seems like a reasonable ask. An RPi-A shield, anyone?

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.

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.

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

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