Comparison of Raspberry Pi vs Beaglebone Black vs Banana Pi

Update (2015-2): I'll update the below when I get more info on the new BCM2836 chip used in the Raspberry Pi Generation 2 model B. It CPU performance should jump up by about six, the RAM has doubled, but the GPU is the same as is everything else. RAM performance will be the same, no clocking improvement, just size. The quad core CPU (ARMv7) does now have NEON support so SIMD, should improve data processing ability. But the real bottleneck to the RPi is getting data into and out of the CPU from the real world, it is like a giant head sitting on a straw.

CPU

From each of the /proc/cpuinfo files shown below, in theory if an application is single threaded the Banana Pi should win, and if it is multithreaded the Banana Pi should still win. I have not run any direct benchmark, just looking at the BogoMIPS and the Features supported by each ARM chip.

Raspberry Pi (Model A,B,B+,A+ all have the same ARM1176JZF-S)
------------
Processor       : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 000f

BeagleBone Black
----------------
processor    : 0
model name    : ARMv7 Processor rev 2 (v7l)
BogoMIPS    : 990.68
Features    : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls
CPU implementer    : 0x41
CPU architecture: 7
CPU variant    : 0x3
CPU part    : 0xc08
CPU revision    : 2

Hardware    : Generic AM33XX (Flattened Device Tree)
Revision    : 0000
Serial        : 0000000000000000


Banana Pi (The Banana Pro has the same Allwinner A20)
---------
Processor       : ARMv7 Processor rev 4 (v7l)
processor       : 0
BogoMIPS        : 2004.17

processor       : 1
BogoMIPS        : 2011.05

Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 4

Hardware        : sun7i
Revision        : 0000

Video/GPU

Raspberry Pi:  Broadcom VideoCore IV (Graphics and compute) 24 GFLOPS
Beaglebone Black: PowerVR SGX530 (200 MHz) (Graphics, video encoding, decoding only) 1.6 GFLOPS
 Banana Pi: ARM Mali400MP2 dual GPU core (Grahpics, video encoding, decoding only) 6.3 GFLOPS 

RAM

Raspberry Pi ( A, A+, B rev 1): 256MiB DDR
Raspberry Pi (B rev 2, B+): 512MiB DDR
BeagleBone Black: 512MiB DDR3L
Banana Pi: 1024MiB DDR3

[DDR3 is 1.35 volt and DDR3L 1.25 volt (lower power = less heat = longer life)]

 

USB

Raspberry Pi A: 1 x Standard A host port (direct).
Raspberry Pi B: 2 x Standard A host port (via hub with Ethernet).
Raspberry Pi A+: 1 x Standard A host port (direct).
Raspberry Pi B+: 4 x Standard A host port (via hub with Ethernet).
Beaglebone Black: 1 x Standard A host port (direct) 1x mini B device port (direct)
Banana Pi: 2 x Standard A host port (direct) 1x mini AB OTG port (direct)
 

Ethernet

Raspberry Pi (B, B+): 10/100Mbps (shared USB)
Beaglebone Black: 10/100Mbps
Banana Pi: 10/100/1000Mbps

Storage

SD/microSD

Raspberry Pi A,B: SD card
Raspberry Pi A+, B+:  microSD card
Beaglebone Black:  microSD card
Banana Pi:  SD card

8-bit eMMC 

Raspberry Pi: None
Beaglebone Black ((Rev B): 2 GB Ångström pre-installed
Beaglebone Black ((Rev C): 4 GB Debian pre-installed
Banana Pi: None

SATA

Raspberry Pi: None
Beaglebone Black: None
Banana Pi: SATA 2.0

Me personally I hate devices with inbuilt flash, 3000-5000 writes per block and the device ready for the bin.

GPIO/Low-level peripherals

Raspberry Pi A, B rev 1: UART, SPI, 2x I²C,MIPI CSI-2, (not yet enabled DSI, CEC)
                                       8-17GPIO pins
Raspberry Pi B rev 2: UART, SPI, 2x I²C,MIPI CSI-2, (not yet enabled DSI, CEC)
                                  12-21GPIO pins

Raspberry Pi A+, B+: UART, SPI, 2x I²C,MIPI CSI-2, (not yet enabled DSI, CEC)
                                   EEPROM ID feature for auto-configuration with add-on "HAT" boards
                                   21-30GPIO pins

Beaglebone Black: 4xUART(1xTX only), 8x PWM, LCD, GPMC, MMC1, 2x SPI, 2x I²C, 7xADC(1.8v), 2x CAN bus, 4 Timers, 25xPRU
                                  65 GPIO pins
Banana Pi:  UART, SPI, I²C, CAN, ADC, PWM
                  CSI (or 21 additional GPIO pins), LCD display LVDS (or 36 additional GPIO pins)
                  7-17 GPIO pins (or 7-74 GPIO pins if CSI and LCD are re-purposed)
                  IR receiver
                  On board microphone

Overall I'd probably pick the Beaglebone Black as having the best GPIO/Low-level peripherals support (and very easy access to the pins).

Power

Raspberry Pi A: 500mA-1000mA
Raspberry Pi B: 700-1000mA
Raspberry Pi A+:  500mA-2000mA
Raspberry Pi B+: 600-2000mA
Beaglebone Black: 300–500 mA @5 V
Banana Pi: 200mA*-2000mA (*requires 700-800mA during boot)

Weight

Raspberry Pi A:  45 g (1.6 oz)
Raspberry Pi B:  45 g (1.6 oz)
Raspberry Pi A+:   23 g (0.81 oz)
Raspberry Pi B+:  45 g (1.6 oz)
Beaglebone Black: 39.68 g (1.400 oz)
Banana Pi:  48 g (1.7 oz)



My conclusion would be if it is light weight I needed, then I'd go with a Pro Trinket (2.6g/0.09oz), unless I needed a 1920x1080HD camera as well then it would be the Raspberry Pi A+ (23g/0.81oz) with a camera module (3g/0.11oz). If it was easily accessible GPIO that I needed, with loads of inputs and outputs I'd pick the Beaglebone Black (It is a great piece of open hardware) 7ADC is nice. And finally if it was shoving large amounts of data about fast, or processing that data, I'd pick the Banana Pi (With SATA 2.0, Gigabit Ethernet and 1GiB of RAM it is an impressive piece of kit) or it's newer incarnation of hardware the Banana Pro (with builtin WiFi).

There are larger communities built up around the Raspberry Pi and Beaglebone Black, than there is around the Banana Pi/Pro hardware.  So if you have a problem, sometimes you may have to solve it yourself rather than looking for a quick fix from someone else in the community  who had the same problem already.

Part One: Time for custom OTP generation hardware ?

I have been looking at how to generate good random numbers and also at the Raspberry Pi's maximum data throughputs rates using wifi (9.9MiB/s), ethernet (11.2MiB/s) and disk (22MiB/s). The Raspberry Pi is good at some things, but it is not very good at moving large amounts of data about really fast. If it was I'd probably look at some way of generating good random numbers and transferring in the data in via the GPIO pins. But even doing this, the GPIO pins have a limit of about 10MHz maybe, some testing would need to be done to see if this could work or if the data rate could be pushed higher (use more pins to transfer more bits in parallel).

I looked into using the BeagleBone Black, but it also only has 10/100 Ethernet (circa 11.2MiB/s). And if I made a custom board with the 324 BGA single core 720MHz-1GHz  Cortex-A8 CPU it probably would not have enough oomph to fully saturate the gigabit built into the TI AM3359 CPU. OK, even if it could generate OTP data at a gigabit per second rates, I could not easily push it to a disk at that rate, so maybe the chip is good enough. It does include a RNG Crypto Hardware Accelerator (/dev/hwrng), but I trust that about as much as I would trust the similar RNG in the Raspberry Pi. The AM3359 does have a 12-bit ADC 200KSPS inbuilt but that would be too slow to sample a noise source for random numbers to generate random numbers at any decent rate. And the chip are a little bit on the expensive side as well:
AM3359ZCZD72  1+ @ €31.47; 15+ @ €29.11; 50+ @ €27.14; 100+ @ €26.45 (April 2014).
AM3359BZCZA80 1+ @ €47.48; 10+ @ €45.20; 25+ @ €42.53; 50+ @ €40.11 (April 2014).
AM3358BZCZ672 1+ @ €39.60; 10+ @ €37.08; 25+ @ €34.98; 50+ @ €31.06 (April 2014).
AM3358BZCZ100 1+ @ €46.84; 10+ @ €44.61; 25+ @ €41.97; 50+ @ €39.59 (April 2014).
AM3357BZCZA80 1+ @ €41.97; 10+ @ €39.97; 25+ @ €37.60; 50+ @ €35.48 (April 2014).
Refer to "8.1.2 Device Nomenclature" in the AM335x datasheet for the exact meaning of the Suffix's.

The Airspy project is using a  LPC4370 ARM CPU which is slow at only 204MHz in comparison to a TI AM3359, but it does have one very nice feature a 12-bit 80MSPS ADC. It also has three ARM  cores a Cortex-M4 and two Cortex-M0's.There is a 100 BGA chip with 3 multiplexed ADC channels or a 256 BGA chip with 6 multiplexed ADC channels.
LPC4370FET100 1+ @ €10.77; 10+ @  €9.46; 25+ @ €8.43 ; 50+ @ €7.19 (April 2014)
LPC4370FET256 1+ @ €14.85; 10+ @ €12.97; 25+ @ €11.58; 50+ @ €9.86 (April 2014)

The airspy project was spawned into existence by the HackRF project which originally used a LPC4330,  well now a LPC4320 (no need to 10/100 Ethernet). This chip has the advantage of not being a BGA device, it is a 144 pin QFP, but the data, in the case of the HackRF One,  is transferred from a separate ADC to the ARM using SGPIO.

LPC4320FBD144,551 1+ @ €8.78; 10+ @ €7.55; 50+ @ €6.19; 100+ @ €4.20 (April 2014)
LPC4330FBD144,551 1+ @ €9.89; 10+ @ €8.50; 50+ @ €6.98; 100+ @ €4.43 (April 2014)


The complexity of using SGPIO and the cost of a separate high speed ADC using a LPC4320, makes the  LPC4370 with its inbuilt 80MSPS ADC look like the best overall cheapest solution for what I want to do.

The fact that the Airspy has a 80dB Spurious-free dynamic range that I could use this to amplify the noise signal from a reverse biased zanier diode or a npn transistor acting as a  germanium diode is nice. Because the noise signal needs about 40dB of gain to be usable. One problem with using the Airspy is that it is only sampling at 20MSPS and not 80MSPS. But as a open software test platform, that could be used to see if making a dedicated board with the LPC4370 BGA chip is feasible or not and it is a good easy first step. The Airspy will have two high speed ADC inputs (using a u.FL connector) for the two spare multiplexed ADC channels on the 100 BGA chip. After the initial tests these ADC ports could be used with a custom firmware to test sampling at 80MSPS, 40MSPS per channel from two shielded secure noise sources.

The main advantage of doing some testing using an Airspy would be not having to design and build a fully custom development board with this 100-256 BGA chip. Ok in the short term it may cost a bit more, but if it does not work I would still have a very useful SDR receiver. Unfortunately there is no way to push more then about 40MiB/sec through USB 2.0. So even though I could be sampling 80MSPS at 12bits (120MiB/sec), I would need to concentrate this entropy by a factor of three. And that is provisional on there being enough spare CPU headroom available to do so before transferring the sampled noise to a PC. The fact that the chip supports SIMD (ARM NEON) may make this just about possible with a good pinch of lateral thinking.