Comparing BeagleBone Black & Raspberry Pi

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.

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.

Shabaz wrote:

and as we know it can run to a highly impressive 200MHz on some of the pins.

If you are talking about PRU I/O (I've seen you make this claim before) then the best you can do is output a 100 MHz square wave (inline code taking two instructions, 5 ns to output 1, 5 ns to output 0, 10 ns cycle time)

for a limited time (up to ~102 uS) depending on how much code space you want to use doing it and it can maintain this only as long as it is the only thing the PRU is doing during this output and you don't care about it

affecting any other I/O pins. Congratulations you have just turned a 200 MHz PRU into a non-continuous 100 MHz oscillator. With all these limitations I don't see this as being particularly useful. Any useful I/O will probably

be limited to 50 MHz or less by  the time the simplest logic is applied to use some input to decide what value to output and again it can maintain this only if it is the only thing you are doing with the PRU and you don't care

about affecting other I/O pins. At this point you have turned a 200 MHz PRU into a logic gate or maybe all the way up to a comparator.

Despite previous assertions by others in other E14 forums that the BeagleBoard Black has faster memory, the Raspberry Pi has twice the memory bandwidth available, 3.2 GB/s max vs. 1.6 GB/s max. To put this in some

perspective displaying video at 1920 x 1080p60 takes about 31% of the BeagleBoard Black's memory bandwidth just to keep the screen refreshed. For some reason this clear design limitation does not get much attention

as I seem to be the only one to bring it up (twice now) so far.

I still see the BeagleBoard Black as clearly being more useful for most embedded applications (depending on video and I/O needs) and engineering students. After all, unlike the Raspberry Pi (and others assertions about

the Pi to the contrary)  that is what it was designed for. There is some

Actually, I've mentioned in other posts that it should be possible to generate waveforms of the order of 50MHz or so.

Why would one want to turn a PRU into a 100MHz oscillator? However, others may be interested in triggering an output within 5nsec, 10nsec, 15nsec or even 50nsec or 500nsec -  it is determinate, unlike a Linux app. This means that I can use it for serial and parallel protocols that run to high speed.

An example: I recently needed an adjustable pulse generator, and as a quick hack I was able to use a PRU to generate pulses in increments of 5nsec. It was fantastic. As a suggestion, if anyone has time, it is possible to load PRU code on the fly, so it is possible to create the code for (say) a 5nsec, 10nsec, 15nsec etc.. pulse to any arbitrary limit, assemble from within the Linux executable if required! load it into the PRU and execute. Before this, I would have had to program a CPLD for the task. I don't keep my programmable logic toolchain and test tools on my day-to-day laptop, so it was an inconvenience if I'm traveling (which I was).

Currently I'm investigating high-speed parallel capture (to around 30MHz, but I'm using an external oscillator - for my use-case it would be very poor form to rely on an internal oscillator for this.

By the way, for data capture, it is possible to use a serial mode which can clock in at 200MHz apparently (i.e. I have not tried it to confirm it or not), but I'm very happy if I can achieve a rate of the order of tens of Mbytes per sec of data in (parallel mode). This is non-trivial without a FIFO and CPLD or FPGA, and is great that it is possible with such a board.

Gary Stewart wrote:

 

I still see the BeagleBoard Black as clearly being more useful for most embedded applications (depending on video and I/O needs) and engineering students. After all, unlike the Raspberry Pi (and others assertions about the Pi to the contrary)  that is what it was designed for.

I agree on most of this. I'm not interested in running a desktop with the BBB, but that's me, it doesn't matter. Not all schoolchildren have access to a desktop (nor Internet at home, for that matter), so I'm very happy if the RPI can help their education. I don't think many dispute that aspect. The RPI has it's flaws, and as an Engineer I can't help but point them out. The BBB has it's flaws too - for example currently some image restrictions are hampering me.

By the way, regarding your memory comment - I'm not sure this is true - see here. I believe Wikipedia's entry to be wrong on the matter. Perhaps we can ask Jason Kridner to confirm or not, he frequents the forum.

Shabaz wrote:

Actually, I've mentioned in other posts that it should be possible to generate waveforms of the order of 50MHz or so.

It says 200 MHz here (and in several other posts) which is what I am responding to and is clearly not obtainable on the outputs at least.

Shabaz wrote:

Why would one want to turn a PRU into a 100MHz oscillator?

Or a logic gate ? Next time I'll put up a sarcasm alert.

Shabaz wrote:

By the way, regarding your memory comment - I'm not sure this is true - see here. I believe Wikipedia's entry to be wrong on the matter. Perhaps we can ask Jason Kridner to confirm or not, he frequents the forum.

The bandwidth is quoted directly from the latest version of the BeagleBone Black reference manual which states that the memory is running at DDR400 (800 MT/s) for 1.6 GB/s. It is impossible to

determine the speed of the memory used on my BBB because it is marked with a "generic" 4 Gb SDRAM part number (I have the data sheet it references) that does not include the speed grade.

Actually the lowest speed grade according to the data sheet is DDR533 so some overclocking may be possible. For now I'll go by what Beagleboard.org says.

Gary Stewart wrote:

 

 

Or a logic gate ? Next time I'll put up a sarcasm alert.

 

You know I hope what they say about sarcasm.. Are you saying that I thought better of you than I should have :-)

Or, one could use their imagination and explore what can be done beyond an oscillator or single logic gate - such as a 5nsec granularity adjustable pulse generator which I mentioned, and worked rather well.

Gary Stewart wrote:

 

 

Or a logic gate ? Next time I'll put up a sarcasm alert.

 

You know I hope what they say about sarcasm.. Are you saying that I thought better of you than I should have :-)

Or, one could use their imagination and explore what can be done beyond an oscillator or single logic gate - such as a 5nsec granularity adjustable pulse generator which I mentioned, and worked rather well.