Taking BeagleBone Black for a walk
Linux powered single-board computers (SBCs) are not quite a dime a dozen, although the price is dropping rapidly enough that such a milestone is not entirely out of the question. While the news in this space over the past two years has been dominated by the Raspberry Pi, there are plenty of other choices. One of the more popular options is the BeagleBone Black, which is more than a match for the Pi in terms of hardware power, and offers a software selection worth exploring, too. Determining which system is right for which task depends on weighing a lot of factors.
Getting around the dog
The BeagleBone Black is the fourth generation SBC from the BeagleBoard project. The first and second devices were called "BeagleBoards;" the BeagleBone moniker referenced the significantly smaller physical dimensions of the third generation product. The BeagleBone Black uses the same form factor as the preceding model. But it also includes updated components and a lower price: $45.
The basic makeup of the board is straightforward. It is powered by a Sitara AM3358 System-on-Chip (SoC) from Texas Instruments (TI), which is built around a Cortex-A8 CPU from the ARMv7 line. There is 512MB of DDR3 RAM on board, plus 2 GB of built-in flash storage and a slot for an additional microSD card. Connectivity includes a wired Ethernet port, one mini USB client port, one full-sized USB host port, and a micro HDMI connector that outputs both audio and video.
But in these modern times, of course, single-board computers need to provide hardware expansion capabilities. This is where the BeagleBone Black first begins to differentiate itself. The long sides of the board include a full spread of pin headers, right up to where the PCB mounting holes get in the way. In grand total there are 92 pins available, which is considerably more than most competing boards. 65 of those pins are available for digital I/O; eight of the 65 can serve as pulse-width modulators (PWMs) for analog output, and four can be configured to serve as timers. Various subsets of these digital pins can also be configured to provide two I2C ports, two SPI ports, and two serial ports (there is also a separate serial debugging header that cannot be used for general purposes).
In addition to the digital I/O pins, there are seven analog input pins, plus an assortment of 3.3V, 5V, and ground pins. If that is not enough, there is also a pad on the back of the board where enterprising users can solder on a JTAG debugging header. Other nice touches include a 5.5mm DC power connector (the device can run off of power supplied by the USB Client port, but having two options is more convenient), hardware power and reset switches, and a built-in array of four programmable LEDs.
The onboard flash storage come pre-loaded with the Ångström distribution—and numerous tools to get started. When the system boots up, it starts a web server running on 192.168.7.2:80 (either over Ethernet or using Linux's USB Gadget API to provide networking if the board is connected to a host computer via USB). This server provides access to the board's documentation (the same documentation and tutorials available at BeagleBoard.org), and there is also a Cloud9-based IDE running on port 3000. The IDE comes preconfigured to make use of BoneScript, a JavaScript library tailored to provide access to the board's hardware expansion features.
Of course, BoneScript is not the only option. One can also SSH into the board and explore it from a terminal like any other Linux system or hook up USB peripherals and an HDMI monitor and use Ångström's lightweight graphical environment. Out of the box, the BeagleBone Black I tested (revision A5C, for the record) runs kernel 3.8.13. Access to the array of expansion pin headers is simple, using sysfs. The traditional first project is to blink an external LED; to do this one should attach the LED's anode to a GPIO pin header, the cathode to a nearby ground header, and export the GPIO pin:
echo 60 > /sys/class/gpio/export
brings up pin number "12" on the left-side expansion header, so that it is accessible as /sys/class/gpio/gpio60 (the GPIO number for the pin has to be looked up in the documentation). Set it as an output pin with:
echo out > /sys/class/gpio/gpio60/direction
and the LED can be flashed on and off by echoing 1 or 0 to /sys/class/gpio/gpio60/value. The only real tricky part of the process is figuring out the correct GPIO number; the numbers on the expansion header do not map cleanly to the various GPIO numbers because of all the positive voltage, ground, and other assorted pins mixed in—and because the board tries to spread the pins around evenly to provide some flexibility when attaching components. The reference manual PDF has a table that provides the correct numbers.
Kicking it up a notch
As exhilarating as flashing an LED can be, eventually one needs more from one's hardware, which is where BeagleBone capes come into play. Capes are the equivalent of Arduino shields: pin-compatible circuit boards that fit into the expansion headers on the BeagleBone itself. Most capes have expansion headers on top to match the pins on the bottom that fit into the BeagleBone's headers; that way multiple capes can be stacked, and the pin compatibility means a +5V location on one board does not get turned into a ground pin by a board in between.
Currently the crop of BeagleBone Black capes is somewhat limited because the "Black" model introduced some variations over the original BeagleBone (which was white in color, although it is usually just referred to as "BeagleBone"). The eLinux wiki includes an up-to-date page of available capes, with those that are compatible with the BeagleBone Black marked as such. The simpler capes (such as those providing a breadboard or through-hole prototyping board) are compatible with both models; there are also Black-compatible capes available for attaching small LCD screens, serial ports, GPS receivers, electrical relays, and camera modules.
More specialized capes are slowly appearing, too; there is a CAN Bus cape (for automotive usage), an unmanned aerial vehicle (UAV) altitude-and-orientation cape, and a cape designed to run a RepRap 3D printer. As with Arduino, most of the capes are community-design products, so what is available depends mostly on what itches need scratching. However, CircuitCo (who manufactures the BeagleBone original and Black) has been systematically taking Creative Commons–licensed capes from the original BeagleBone and updating the design to match the Black model's pinout, so in many cases a refreshed cape is on the way if it is not already available. Since the original BeagleBone is no longer being manufactured (and was twice the price of the Black), the old capes will probably disappear from production anyway.
On the software side, updates to the Ångström release on the board are available from the beagleboard.org site. Separate kernel sources are available on GitHub for those who cannot wait for a new release, although only minor 3.8 updates are available now. The kernel used is the mainline Linux kernel, but it may be simpler to recompile for the device when starting from the exact sources and configuration used in the official build; the official kernel is also updated periodically with support for new capes.
Perhaps more interesting is the array of other Linux distributions available. Ubuntu, Debian, Arch, Gentoo, Sabayon, and Fedora releases are all available. Although the board is not an officially-supported platform for these distributions, the relatively recent ARM revision and simple hardware of the BeagleBone evidently make an ARM distribution relatively easy to get running, either by overwriting Ångström on the internal storage or by installing an image on the microSD card slot (which is faster to experiment with, since overwriting the onboard storage can take close to an hour). For the more adventurous, there is also an Android port available (from TI), as well as QNX and FreeBSD releases.
One reason installing outside distributions is comparatively simple is that the BeagleBone Black uses standard distribution components like the U-Boot bootloader, and that it does not require binary blobs to boot. The graphics chip is a PowerVR GPU that does come with a binary-only OpenGL ES firmware blob, but the board will run non-OpenGL applications fine without it.
Comparing apples and raspberries
The binary blob issue is one of the more frequently cited issues where BeagleBone supporters feel their hardware has an advantage over the Raspberry Pi, which by size and price is the nearest competitor (and one which gets noticeably more news attention). The Pi, of course, uses a Broadcom BCM2835 SoC with an open source user-space component that speaks to a proprietary firmware blob. More importantly, though, the Pi uses a non-standard boot sequence that actually starts up the board's VideoCore GPU first, and the binary VideoCore OS subsequently loads the Linux operating system.
There are other differences as well, starting with the fact that the Pi uses a generation-older ARMv6 core at a lower clock speed. The Pi also includes expansion headers, but fewer of them than the BeagleBone Black, and some of them can be difficult to access. From a practical standpoint, the BeagleBone Black's DC power plug is another nice touch, since the Pi can only be powered over its micro USB connector. The Pi also lacks a hardware reset switch, which is inconvenient. In addition, although both boards are roughly the same size as an Altoid mint tin (which in recent years has become the standard international unit for circuit-board size), the BeagleBone is an exact fit, while the Pi's slightly larger size and sharp corners make it a mismatch. Finally, BeagleBone capes are designed to be stackable, while Pi expansion boards are generally not stackable due to the asymmetry of the expansion headers (on a side note, it is also odd that Pi expansion boards do not have an official nickname akin to "capes" or "shields;" "toppings" or "meringues" would seem to be the obvious choice).
On the other hand, Pi supporters will be quick to point out that the Pi has nice features of its own, such as a dedicated camera module connector using the standard Camera Serial Interface (CSI), built-in support for Display Serial Interface (DSI) output, full-size HDMI, RCA video out, 3.5mm audio out, and the availability of hardware multimedia decoding.
It is definitely true that the Pi offers an easier multimedia experience than the BeagleBone Black. The Pi has more connector options, and its GPU is capable of handling 1080p video—capable enough that there are several active media center distribution options for the Pi.
That is why it always comes down to matching the product with the project. The BeagleBone Black will likely not be useful as an XBMC or video gaming front end for the home theater, while the Pi is considerably more limited in how many sensors, servos, and hardware relays it can control. For free software advocates, the BeagleBone Black product is not quite devoid of binary blobs, but it is possible to boot and run it with free software.
Not everyone cares about the presence or absence of binary blobs, of course. And no doubt the Raspberry Pi Foundation has already heard a lot about this subject; it seems plausible that in the virtually inevitable Pi follow-up, the result will have less reliance on proprietary firmware. The BeagleBone Black can exert some market pressure on the Pi in that area, demonstrating that an almost-totally-free software SBC system is possible to make today.
That is fair play, though, since the success of Pi clearly pushed
the reduction in size and price seen in the Black as compared to
earlier BeagleBoard/BeagleBone revisions. Earlier BeagleBoards were
noticeably bigger than the Pi, and the first BeagleBone retailed at
$89. At $45, the Black is a little more expensive than the Pi, but
not by much. There is also a gray area between the "hobbyist" uses
targeted by the BeagleBone Black and the "educational" projects
envisioned by the Pi, of course. But any cheap Linux-powered SBC is
an educational opportunity, which can quickly turn into a
hobby—or more.
Posted Dec 12, 2013 2:25 UTC (Thu)
by michaelkjohnson (subscriber, #41438)
[Link] (3 responses)
Posted Dec 12, 2013 18:14 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
You could use something like that for managing fuel injection system in a automobile, for example.
Have some big perl or python script analyzing sensor data and making adjustments to the fuel mixtures while the the PRU do the actual firing of injectors and ignition.
Just 50 bucks for something like this is amazing.
Posted Dec 14, 2013 19:50 UTC (Sat)
by jhoblitt (subscriber, #77733)
[Link] (1 responses)
Posted Dec 17, 2013 21:10 UTC (Tue)
by andreasb (guest, #80258)
[Link]
https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXi...
Posted Dec 12, 2013 3:17 UTC (Thu)
by ncm (guest, #165)
[Link] (1 responses)
The major differences include price (<$50, ~$100, >$150) and complement of i/o interfaces. The cheapest may turn out less so when you add the i/o you need. None have GPUs with free-software drivers, but the Vivante and Mali GPU designs are the targets of active development efforts (Entaviv and LIMA, respectively) nearing maturity. For others, you are likely to be stuck on an old kernel that the binary blob driver was built against.
If you are not certain what you might do with it, more i/o interfaces built in can fuel inspiration. The less usual such include S/PDIF optical audio, IrDA, Bluetooth, Wifi, and camera connectors. Only a few sport A9-or-newer processors. A second MicroSD slot can make a remarkable difference in convenience. What you hear most about is likely not to be the best choice; but for the less self-reliant, the frisson of the user community may trump all else.
Speeds of the microSD cards you will boot from vary enormously. Sandisk's only fast variety is called "Ultra", rarely found on store shelves. Although it advertises "up to 50MB/s" write speed, I only got 10 on a big image transfer. I don't know of any that perform up to claims.
Posted Dec 13, 2013 13:32 UTC (Fri)
by robclark (subscriber, #74945)
[Link]
Note that you can use freedreno on dragonboard/apq8074 (possibly too expensive to count), or ifc6410/apq8064 ($150 and very good hw specs) and bstem/apq8060a (not sure price yet). Any of those gives you pretty usable open source graphics.
Downside: kernel is, at the moment, pretty far from upstream. (Something w/ vivanti/etnaviv, like say an iMX6, is probably the first thing that will have upstream kernel + open src gpu.)
There is active upstream work on apq8074. And there is ongoing upstream work on msm8960 which seems to be close enough to apq8064 that with some community effort we might also be able to get an upstream kernel on the ifc6410, despite qcom. Anyone interested in helping me with that, come hang out in #freedreno and ##linux-msm ;-)
Posted Dec 12, 2013 7:14 UTC (Thu)
by tnoo (subscriber, #20427)
[Link] (2 responses)
Posted Dec 12, 2013 8:00 UTC (Thu)
by dlang (guest, #313)
[Link]
what accessories are connected, what workload is running, what network traffic is being generated?
all of these are low power compared to a typical x86 desktop, but they are all power hogs compared to a phone or tablet
Posted Dec 12, 2013 16:12 UTC (Thu)
by rriggs (guest, #11598)
[Link]
These development boards are not typically designed for maximum power efficiency. Instead they are designed for maximum flexibility when prototyping. You are unlikely to need every peripheral provided. (Do you need HDMI or USB for a remotely deployed device?) And the power (voltage regulation) circuitry is probably not the most efficient for battery/solar use.
If you are that worried about power consumption, you probably ought to look at custom hardware. Use these boards to prototype, then design and build a custom board that meets the specific need.
If you goal is to use COTS hardware (because it is a one-off project or a kit that others will build), start with the least capable, most efficient device that meets your needs. An MSP430 Launchpad might do the trick. Or an Arduino Nano. Maybe you need a Beaglebone or a Pi. Then determine what peripherals are not needed and find out if they can be powered down.
Posted Dec 12, 2013 10:25 UTC (Thu)
by ebirdie (guest, #512)
[Link] (9 responses)
"Not everyone cares about the presence or absence of binary blobs, of course." Maybe this blog article helps a couple non caring to decide. The article has a very down to earth presentation about experimenting to hack a very common hard drive controller (not SATA controller but the controller, which drives hard drive mechanics and, for one, SMART operations).
Posted Dec 12, 2013 11:02 UTC (Thu)
by colo (guest, #45564)
[Link]
Posted Dec 12, 2013 14:36 UTC (Thu)
by geertj (guest, #4116)
[Link] (4 responses)
Case in point: I own both a Raspberry Pi, and a Beaglebone Black. The BBB nicely runs an up to date Fedora 20 beta, while the RPi is stuck on a semi maintained fork called Pidora which is based off Fedora 18.
Posted Dec 12, 2013 20:28 UTC (Thu)
by linuxjacques (subscriber, #45768)
[Link] (2 responses)
How's the BBB video support on F20beta?
If it works, I know what I'm loading on mine tonight.
Posted Dec 13, 2013 7:25 UTC (Fri)
by geertj (guest, #4116)
[Link] (1 responses)
http://uk.rs-online.com/web/p/interface-development-kits/...
For me it's fine because I only use the BBB over the network. FWIW, I believe USB will be fixed in 3.13. In a sence, it's the price to pay for a distribution that has an upstream first policy. Fedora is pushing the envelope here becasue they are the first distro providing a single kernel that works on multiple boards (using devicetrees).
Posted Dec 16, 2013 14:33 UTC (Mon)
by wookey (guest, #5501)
[Link]
This makes life _so_ much easier for distros generally, and should greatly improve the set of supported boards because so long as you can find a device tree and bootloader and a mainline kernel works, the distro doesn't have to do anything specific to support the hardware.
Posted Dec 13, 2013 2:59 UTC (Fri)
by dlang (guest, #313)
[Link]
Posted Dec 12, 2013 15:19 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (1 responses)
This is a great illustration on the number of independent computers which make up a modern computer system. I don't think anyone alive can fully comprehend everything which is going on in a modern system or even be aware of it, the complexity is just too high. This all reminds me very much of the character Pham Nuwen in A Deepness in the Sky where you can use technology every day but barely plumb the depths of it.
Posted Dec 14, 2013 18:40 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Dec 12, 2013 23:30 UTC (Thu)
by giraffedata (guest, #1954)
[Link]
Posted Dec 13, 2013 2:24 UTC (Fri)
by plugwash (subscriber, #29694)
[Link]
The real reason the BBB is easy and the Pi is hard is that before the Pi was released all the major linux distros chose armv7 as the baseline for their hard float ports. So getting a distro running on the BBB is usually just a matter of combining a BBB kernel/bootloader with a rootfs from your OS of choice while on the Pi you are facing a complete rebuild of the entire distro. Rebuilding a full-featured linux distro is not a small task.
Be aware that a lot of the pins on the BBBs expansion headers conflict with the onboard HDMI and EMMC, something to bear in mind when planning your project. The graphics is also much weaker than a Pi both in terms of processing capabilities and output capabilities with only 16 bit color, can't output 1080p60 (though it can now do 1080p24)
Note that while the BBBs CPU is faster than the PIs CPU at integer and has neon for fast (but not fully IEEE compliant) single precision floating point it is actually slower than the CPU in the Pi at regular vfp floating point.
Overall which is better out of the BBB and the Pi depends very much on your application.
Posted Dec 17, 2013 12:16 UTC (Tue)
by giggls (subscriber, #48434)
[Link]
What I would like to have a comparison Table of Raspberry Pi, pcduino and Beaglebone Black for is the following:
* Kernel GPIO support via sysfs
Unfortunately the last is not supported on Raspberry Pi. So one can not write portable code supporting io-buttons on gpio which is capable of running on a generic PC as well.
Any Info for the other two platforms?
Sven
Posted Dec 19, 2013 10:43 UTC (Thu)
by ajmacleod (guest, #1729)
[Link] (1 responses)
I know I'd rather have the device a few pennies cheaper and have a nice regular rectangular board than some weirdly shaped thing designed to fit into a metal tin really quite unsuitable for the purpose...
This aside, it's great to see such a range of low(ish) cost single board computers available - it really is amazing how easily one can put together a project which would have been a major task requiring an awful lot of electronics knowledge just a few years ago. The ease of purchasing all types of components very cheaply directly from China has also been a big change.
Posted Dec 19, 2013 11:03 UTC (Thu)
by hummassa (subscriber, #307)
[Link]
As a curiosity, the Brasilian equivalent to the Altoids tin can is the cheap plastic closed soap dish (with the advantage of being isolating, and the disadvantage that you can't use it for ground.)
A random example photo from the internets:
https://lh3.ggpht.com/-R5dE5foxBPs/UJxkLdbBXlI/AAAAAAAAAL...
Another, in an Altoids tin can:
One of the interesting (but infrequently mentioned) features of the BeagleBone Black is the set of two PRUs — Programmable Realtime Units — that let you run one or two dedicated realtime tasks at 200Mhz full time, independently of the main CPU.
BeagleBone Black PRU
BeagleBone Black PRU
BeagleBone Black PRU
BeagleBone Black PRU
Wikipedia offers a more-or-less complete list. Actually, two:
List of... and Comparison of..., with some overlap.
Many choices
Many choices
Power consumption
Power consumption
Power consumption
Taking BeagleBone Black for a walk
Taking BeagleBone Black for a walk
Taking BeagleBone Black for a walk
Taking BeagleBone Black for a walk
Taking BeagleBone Black for a walk
Taking BeagleBone Black for a walk
Taking BeagleBone Black for a walk
Taking BeagleBone Black for a walk
Taking BeagleBone Black for a walk
I read the article. What lesson do you see in it that would help someone decide whether or not to care about binary blobs?
Taking BeagleBone Black for a walk
Taking BeagleBone Black for a walk
I think this has very little if anything to do with it.
State of GPIO-support (Software Hardware)
* GPIO Interrupt support on sysfs via select/poll
* GPIO support for /dev/input/evdev support
Altoids
Altoids
