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?

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.

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.