Comparing BeagleBone Black & Raspberry Pi

Cool.  I'd also like to see how the pcDuino fits in there.

Drew Fustini wrote:

 

BBB $45 vs RPi Model B $35: BBB includes 2GB built-in flash & can run off

computer USB port [<500mA] so that would make up the cost

difference if one has to buy SD card and power supply for Pi.

I didn't like the onboard eMMC idea at first, and I'm still somewhat undecided. The 'everything you need to get started is in the box' idea is a stroke of genius though and removes all the faffing about with inexperienced users and win32diskimager.

Also, when you start thinking about integrating a BBB into your own 'internet-of-things' device it's actually an incredibly good idea too as you get a tested and known compatible storage device to boot from - at zero additional cost.

For tinkering, trying different distros etc, I still think that the eMMC is a roadblock. The current 45mins to reflash it needs to improve by orders of magnitude.

I believe media center is the best use case for RPi model B over the BBB.

... is the only use case for the RPi over the BBB...

We know from elsewhere that the BBB is technically capable of 1920x1080p60 without sound, or 1920x1080p30 with sound but that in these early days of BBB some driver development may be needed to make those easily available. So the only RPi advantage is the capable video decode hardware.

Actually maybe I'm a bit hasty on the use of 'only' there.  I think the RPi may have a bright future as a very cheap megapixel IP security camera type of device too with the addition of the camera board.

BBB has the ARM v7 instruction set so there is a wider range of distros

Like it or not, the trend certainly seems to be that ARMv7+NEON is going the be the minimum that distros are targeting nowadays. You'll probably be able to get soft float debian for some time to come, but even Debian isn't going to support the slightly unusual combination used in the broadcom device on the Pi.  Hindsight is wonderful, but you can't help thinking that if they'd put at least a cortex A8 into that particular SoC it would have taken a lot longer for someone to catch up with the Pi.

BeagleBoard.org and the BeagleBone leaders are passionate about getting

everything in the mainline kernel. They work with Linux kernel

maintainers to get their patches accepted upstream. I've been told they

hope to have everything in the mainline by sometime this year.

I think it's unlikely it'll happen this year, there's quite a lot of stuff in the beagleboard tree on github that would need to be ready pretty much right now. We're likely only a week or two away from 3.10, so if it's not already in the Arm maintainers tree it's almost certainly missed 3.11. That leaves 3.12 at the tail end of the year, but getting there assumes that everything is ready for the arm maintainers to pull now and the bigger the patchset the longer it'll take to review and it all assumes no issues are found and no changes are requested upstream.

I was quite surprised that one of the interviews with Jason Kridner quoted him as saying they were skipping 3.9 & 3.10 regardless - it would seem to make sense to have spent that time slowly pushing stuff upstream rather than seemingly aiming for a huge code drop in a later merge window.

BBB was a big jump forward from BB White as they went from Linux 3.2 to Linux 3.8

*and* the shift to Device Tree for configuration of peripherals.

The upstream kernel is very much a moving target though, 3.8 is already marked EOL. The only way to keep up is to get over that last hurdle of actually getting the code into mainline.

On the devicetree side, take a look at the thread linked to from this post http://www.element14.com/community/thread/25063?tstart=0 there's certainly some argument there that devicetree may not really be the answer and it certainly gives the impression that BBB could end up being one of the only systems that embraces devicetree fully.

There's been a lot of churn in the Arm parts of the kernel over the last year due to devicetree, BBB could end up being the one that proves it's workable, or could be left out in the cold if another solution eventually wins. I think it could be too early to tell how this will play out.

There's a very long discussion about this here: http://www.element14.com/community/thread/23575?tstart=0

I'll quote from my first comment at that thread, since it makes IMO a good "elevator speech" summary:

I don't think BBone Black will displace RasPi, because RasPi is still cheaper (especially the Model A) and has a very effective community.  BBone has higher CPU performance, but RasPi probably has better media performance since that's what the BCM2835 was designed for, so people who just want a media engine will prefer it.  But BBone has much better I/O capabilities (clearly now a better choice for geeks*) and has rounded corners so it actually fits in an Altoids tin   And BBone has a full Technical Reference manual.

 

* I use the definition of "geek" that requires hardware expertise: "you can't spell geek without EE".

I'll also add that all the BBone parts are fully documented, except for GPU internals.  I'll also add that BBone has a fully-capable USB controller (RasPi is still flaky in that regard) and has Ethernet built into the chip instead of via USB.  RasPi's SoC is a media engine.  BBone's SoC is a serious industrial compute and I/O engine with things like hardware support for IEEE 1588 Precision Time Protocol.

Also:

Better for mobile applications:

BBB is way more ideal than RPI for portable applications: it has built-in battery charging capability and power management (including automatic power-down) and a switch for power-up, so making it portable costs nothing except the cost of a Li-Ion cell. I believe with the RPI you need additional hardware, which some people are charging a lot of money for. It makes the BBB  cheaper for mobile apps. An RTC costs 1$. Plus, power consumption has been measured to be lower than RPI model B, so it runs cooler (typically 1.1 to 1.5W), and down to uA when it shuts down.

Also, for portable application user interfaces an LCD controller for standard high-res TFTs is built-in and working today, plus touch screen interface.

For applications that need to run from a cell for a very long time, I suspect it could compete with model A if we examine if we can power off bits (like the PHY and HDMI). Today, it can run for 3.5 hours on a Li-Po that takes no additional volume above the connector pins.

More useful form-factor:

The BBB has a far more usable form-factor: smaller, no sticking-out connectors or SD cards or other bits to break off, and a higher-quality memory slot, and connectors not on all sides. It doesn't need strange-shaped custom cases or PCBs as a result of the design. Plus it has 4 holes intended for mounting. I was really surprised with the zero-hole Pi, and even the 2-hole one. Even the connectors are more usable, I saw an odd photo of a connector at an angle of about 30 degrees on some header holes adjacent to the main header on the RPI. These might individually be little things, but they could be fixed to make the RPI more convenient in a later revision and I don't see why they didn't on the next rev.

Better for high-end portable audio applications

It is far easier to build portable high-end (or low-end) audio playback applications on the BBB, because it has a standard I2S interface capable of 24-bit 192kHz, no need to have hardware to extract this from HDMI.

Better I/O for hardware interfacing and sensors

The BBB has more I/O, and as we know it can run to a highly impressive 200MHz on some of the pins. The BBB has built-in 12-bit ADC - 7 channels accessible to the user,  and two I2C interfaces totally accessible for user hardware at selectable bus speeds (a third I2C is used with built-in hardware on the board) plus the I2C natively supports write-and-read capability and non-standard features that require bit-banging or kernel mods on the RPI - I think!!

Although an AVR-type microcontroller is cheap to add as an attachment to an RPI, it doesn't have good comms to the main CPU, unlike the PRUs which integrate so well.

John Beetem wrote:

 

I use the definition of "geek" that requires hardware expertise: "you can't spell geek without EE".

I'd go further and say that, from an Edu perspective, the strong statement "BBB is a better platform for EE education" is a certainty.

It probably continues to be a certainty even if we replace "EE" with "IT", since most of the educational material that runs on the Pi will run on BBB as well.  The few examples that won't port across because they are specific to Pi hardware have arguably rather more limited educational value.

If I were still teaching computing to EE undergrads, a BBB would be on the recommended purchase list ahead of all but a few essential textbooks.

Morgaine Dinova wrote:

 

The few examples that won't port across because they are specific to Pi hardware have arguably rather more limited educational value.

I'm trying to think of things that won't port across and failing. The only one that comes to mind is the camera.

Other than that you're talking about a pi specific software library, something like wiringpi perhaps? I think that's very similar to saying that an AIX library won't run on Solaris, true but not particularly relevant. In any case the libraries API could be ported if someone felt it was worthwhile.

Maybe GPU related stuff?  But what's the educational value in a closed GPU that you're only likely to encounter on the Pi ?

shabaz wrote:

 

plus the I2C natively supports write-and-read capability and non-standard features that require bit-banging or kernel mods on the RPI - I think!!

I'm not sure that's the case, at least the current BBB I2C driver exposes one less feature than the R-Pi. Non-standard features by their very nature are much less useful anyway

root@beaglebone:~# i2cdetect -F 0

Functionalities implemented by /dev/i2c-0:

I2C                              yes

SMBus Quick Command              no

SMBus Send Byte                  yes

SMBus Receive Byte               yes

SMBus Write Byte                 yes

SMBus Read Byte                  yes

SMBus Write Word                 yes

SMBus Read Word                  yes

SMBus Process Call               yes

SMBus Block Write                yes

SMBus Block Read                 no

SMBus Block Process Call         no

SMBus PEC                        yes

I2C Block Write                  yes

I2C Block Read                   yes

root@rpi:~# i2cdetect -F 0

Functionalities implemented by /dev/i2c-0:

I2C                              yes

SMBus Quick Command              yes

SMBus Send Byte                  yes

SMBus Receive Byte               yes

SMBus Write Byte                 yes

SMBus Read Byte                  yes

SMBus Write Word                 yes

SMBus Read Word                  yes

SMBus Process Call               yes

SMBus Block Write                yes

SMBus Block Read                 no

SMBus Block Process Call         no

SMBus PEC                        yes

I2C Block Write                  yes

I2C Block Read                   yes

The only obvious effect I've found so far is that on the BBB a default 'i2cdetect 0' fails and you need to work out that you need 'i2cdetect -r 0'

I'd also suggest that I2C on the RPi requires a kernel mod just to work as the RPF didn't bother writing a driver for it and one was supplied by the community.

Just linking John's well researched comparison of the state of openness and/or documentation for the two boards here, so that it doesn't get lost.  That thread in the Pi Group is growing like topsy.

Also,

This:

(by the way, it looks like the ticks on the silkscreen near the headers is ideal for counting off 10 pins at a time)

versus this:

Also,

(We could use these images to annotate any mods/changes we make).