Skip to main content

What's next for Beagleboard.org and the Beaglebone Black?

Beaglebone Black
The Beaglebone Black, Raspberry Pi, and other low cost SBCs have altered the embedded computing landscape with high end capabilities and low price points. It has been amazing to watch the shift from systems like the Arduino in 2005 (16MHz cpu, 2k of ram), to the Pi in 2012 (700MHz cpu, 256MB of ram). I've been working with the Beaglebone Black (BBB) for a few years now, almost since it was released in 2013.

While the Raspberry Pi is the volume leader by far, and has been around for longer, since 2012, the Pi uses a Broadcom SoC that isn't available through low volume distribution channels. The BBB on the other hand uses the TI Sitara AM335x which can be had through common enough places as DigiKey. This availability means that the BBB can be an ideal prototype platform for both hobby and commercial use. You can begin with the off the shelf BBB and then build a custom board around the AM335x SoC or, because the design files for the BBB are open, customize the BBB's design.

Since the release of the BBB the field of low cost SBCs has been expanding in capabilities. Here is a table with some of the SBCs that have features similar to the BBB. The selection of comparative features is arbitrary, there are a wide range of particular differences between each of these boards. Wikipedia has a page dedicated to comparing single board computers. This list is just focused on what is most interesting to me.


Released Board CPU Ram Storage on-board External storage Video output Network Cost
Apr 2013 BBB Single 1GHz ARM Cortex-A8 512MB 4GB emmc microSD mini hdmi, 24bit lcd on headers ethernet $45USD
~Sep 2015 Beagleboard x15 Dual 1.5GHz ARM Cortex-A15 2GB 4GB emmc eSATA, microSD, expansion headers hdmi 2x ethernet ~$100USD
Feb 2015 Pi2 Quad 900MHz ARM Cortex-A7 1GB None MicroSDHC hdmi ethernet $35USD
Dec 2014(?) Odroid C1 Quad 1.5GHz ARM Cortex-A5 1GB None microSD/emmc adapter (8GB - $25USD) micro hdmi ethernet $35USD


Some of the reasons I like the BBB:
  • TI AM335x SoC is available if you wanted to build a custom board, unlike Pi2's SoC
  • Mainline Linux kernel support for the AM335x. TI's support for Linux isn't great, their kernels are typically far behind mainline and contain patches that won't be accepted upstream, but they are more open than Allwinner (the maker of the quad chip on the Odroid) who has had a history of gpl violations.
  • On-board emmc, 4GB, means less concern about mechanical attachment for high vibration uses, unlike the Odroid emmc adapter board.
  • Expansion headers are symmetric and at the board edge so any expansion boards, called 'capes' for the BBB, are mechanically well supported. The Pi/Pi2 and Odroid have a single set of headers on one side of the board.
  • Expansion headers have enough pins to make cape attachment mechanically secure, but the BBB has holes in it in case you'd like to screw the cape to the board.
  • 24bit LCD is available on the expansion headers. This is perfect for directly driving a small LCD screen. Pi/Pi2 and Odroid C1 don't expose lcd output on their expansion headers.

That being said, the Odroid C1 has a bit in common with the BBB in terms of processor, ram, and price. A custom version of the Odroid C1 could certainly be a replacement for our use of the BBB. Sourcing for the Allwinner SoC here in the US isn't obvious from a few google searches although I haven't looked very hard. Most users are probably aren't concerned about emmc mechanical attachment and others might be looking to make a custom board. Many users may also be using hdmi for their displays and not need the BBBs lcd output. The Odroid C1 has hdmi output.

The BBB has a few advantages beyond simply specifications and cost. There is an active organization supporting the board, Beagleboard.org, an active community on Google groups and a wide range of available capes. These are some areas where the BBB seems ahead of the Odroid and several other SBCs that didn't make it on the above list.

After being out for a few years the BBB is now towards the low end of performance when compared to similar SBCs. People have been raising the question of an updated version on the beaglebone groups.

The next board in the Beagleboard line appears to be coming in the form of the Beagleboard-x15. The x15 isn't intended as a replacement for the BBB though.

Beagleboard.org, the BBB, and its designers are all affiliated with or work for TI. An advantage would be direct access to engineering resources, daily familiarity with the chips and systems etc. A downside is that it looks like Beagleboard.org is sticking with TI processors.

In one discussion Gerald Coley, the designer of the BBB and the x15 , mentioned that:

"BeagleBone Black at this point has no processor future due to TI's dead end road map."

If the AM335x line isn't expanding to multi-cores that would mean the SoC on the BBBv2 would have to differ from that on the BBB. It may have been a stretch to maintain cape compatibility between a single and a quad core AM335x, switching processor families means almost certain incompatibility with existing capes and just as likely a completely new board and system design. If the alternate SoC families from TI are more expensive, as the AM5728 on the x15 appears to be, that cost could put the board outside of the low cost range of the C1, Pi2 and others.

What's next?

There are several SBCs that have the potential to fill the gap left by the Beaglebone Black. The question is what might be next for beagleboard.org and the strong community built around the BBB. The BBB will stay relevant for some time. Its performance and cost are still good, there are a wide range of capes available, and the existing community and software support will continue to make it attractive for some time. How long will its performance and cost be good enough? A year? Two? Does beagleboard.org have something coming that hasn't been announced yet? I hope so.

Comments

Popular posts from this blog

Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3. Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language. Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register). BusFault status register bits The definition for imprecise and precise bits is: [2] IMPRECISERR Imprecise data bus error: 0 = no imprecise data bus error 1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current pr

Graco Swing By Me - Battery to AC wall adapter modification

If you have one of these Graco battery powered swings you are probably familiar with the cost of C batteries! The swing takes four of them and they only last a handful of days. I'm not sure if the newer models support being plugged into the wall but ours didn't. If you are a little familiar with electronics and soldering, here is a rough guide on how you can modify yours to plug in! I wasn't sure how exactly to disassemble the swing side where the batteries were. I was able to open up the clamshell a bit but throughout this mod I was unable to determine how to fully separate the pieces. I suspect that there is some kind of a slip plate on the moving arm portion. The two parts of the plastic are assembled and the moving arm portion with the slip plate is slid onto the shaft. Because of the tension in that slip plate it doesn't want to back away, and because of the mechanicals that portion of the assembly doesn't appear accessible in order to free it. I was

Memory efficient queuing of variable length elements

In embedded environments memory can be a critical driver of the design of data structures and containers. Computing resources have been expanding steadily each year but there are still a wide range of systems with far less than a megabyte of memory. On systems with tens of kilobytes of memory, structures are often designed to be compact to maximize data density. Rather than splurging on memory aligned elements that would be faster for the processor to access, a developer will typically use types with minimal sizes based on the known range of values that the element is intending to hold. Fixed sized buffers At my day job a fixed size pool of messages was implemented to hold message data. While this achieved one design goal of using statically allocated buffers, avoiding dynamic allocations that might fail at runtime, it isn't efficient if there is a wide range of message sizes. It isn't efficient because each message uses a message buffer. With small message sizes the buff