While the BeagleBone is usually compared to the Raspberry Pi, there are a few features that make the ‘Bone a vastly more capable single board computer. There is a small difference in the capabilities of the processor, but the real power of the BeagleBone comes from the PRUs available: two small cores that give the BeagleBone the hardware equivalent of bitbanging pins. [Texane] has put up two great tutorials for using the PRU in the BeagleBone that should be required reading for every BeagleBone owner.
[Texane] used this C compiler to rehash the earlier, assembly only PRU program, making development significantly easier. There’s still a bit of inline assembly, and the inline assembly support isn’t as advanced as in GCC, but it’s still much easier than the assembly only variant.
While [Texane] is using the PRU in his BeagleBone to develop something at a synchrotron facility, three are a few things where really fast hardware bitbanging comes in handy: it can be used to make a video card for a vintage mac, or any sort of VGA video card, really. Very cool stuff, especially now that you can write something in C.
The BeagleBone Black has a powerful featureset: decent clock speed, analog inputs, multiple UART, SPI and I2C channels and on-board memory, to name a few. One missing feature seems to be the lack of support for the two on-board Programmable Real-time Units (PRU’s). Each of these 32-bit processors run independently of the main processor, but are able to interface with the main processor through the use of shared RAM and some interrupts. Unfortunately, PRU’s are not supported and in the absence of information, difficult to program. Enabling the PRU’s will allow them direct access to external sensors via the GPIO pins, for example. Perhaps most enticing is the idea that the PRU’s add real-time processing capability to the BBB.
[Thomas Freiherr] is working on the libpruio project to allow PRU support on the BBB. It is “designed for easy configuration and data handling at high speed. libpruio software runs on the host (ARM) and in parallel on a Programmable Realtime Unit SubSystem (= PRUSS or just PRU) and controls the subsystems”. Additional information about the project is available on the libpruio wiki, and files can be downloaded from here (German Page).
This paper presented at inter.noise2014 (PDF) a couple of months ago has a nice comparison of various small computer/controller boards and outlines the advantages of the BBB once its PRUs are enabled. If readers come across applications of the BBB with PRUs enabled, let us know in the comments. If you want to work your way into the world of the PRU we highly recommend this tutorial series.
It’s understood that 3D printers and CNC machines need to control motors, but there are a few other niceties that are always good to have. It would be great if the controller board ran Linux, had support for a nice display, and had some sort of networking. The usual way of going about this is either driving a CNC machine from a desktop, or by adding a Raspberry Pi to a 3D printer.
The best solution to this problem is to just drive everything from a BeagleBone. This will give you Linux, and with a few motor drivers you can have access to the fancy PRUs in the BeagleBone giving you fast precise control. For the last few years, the Replicape has been the board you need to plug a BeagleBone into a few motors. Now, there’s a better, cheaper solution. At the Midwest RepRap Festival this weekend, [Elias Bakken] has unveiled the Revolve, a single board that combines Octavo Systems’ OSD3358 ‘BeagleBone On A Chip’ with silent TMC2130 motor drivers from Trinamic. It’s an all-in-one 3D printer controller board that runs Linux.
The specs for the Revolve are more or less exactly what you would expect for a BeagleBone with a 3D printer controller. The main chip is the Octavo Systems OSB3358, there are six TMC2130 stepper drivers from Trinamic connected directly to the PRUs, 4 GB of eMMC, 4 USB host ports, 10/100 Ethernet, 1080p HDMI out, and enough headers for all the weird and wonderful 3D printers out there. The software is based on Redeem, a daemon that simply turns G-code into spinning motors and switching MOSFETs.
The price hasn’t been set, but [Elias] expects it to be somewhere north of $100, and a bit south of $150. That’s not bad for a board that effectively does everything from online printer monitoring to real-time motion control. There’s no date for the release of this board, but as with most things involving 3D printer, the best place to check for updates is Google+.
The BeagleBone is a very popular single board computer, best applied to real-time applications where you need to blink LEDs really, really fast. Over the years, the BeagleBone has been used for stand-alone CNC controllers, the brains behind very large LED installations, and on rare occasions has been used to drive CRTs. If you just want a small Linux board, get a Pi. If you want to do something interesting with hardware, get a BeagleBone.
The BeagleBone ecosystem has grown a lot in the last year, from the wireless and Grove connector equipped BeagleBone Green, the robotics-focused BeagleBone Blue, the Zoolander-inspired Blue Steel. Now there’s a new BeagleBone, built around a very interesting System on Module introduced earlier this year.
The new board is called the BeagleBone Black Wireless, and it brings to the table all you know and love about the BeagleBone. There’s a 1GHz ARM355x with two 32-bit 200MHz PRUs for the real-time pin toggling. RAM is set at 512MB, with 4GB of eMMC Flash and Debian pre-installed, and a microSD card for larger storage options. The new feature is wireless connectivity: a TI WiFi and Bluetooth module with provisions for 802.11s replaces the old Ethernet connector.
Taken at face value, the new BeagleBone Black Wireless deserves a mention — it’s a BeagleBone with wireless — but isn’t particularly noteworthy. But when you get to the gigantic brick of resin dropped squarely in the middle of the board does the latest device in the BeagleBone family become very, very interesting. The System on Module for this version of the BeagleBone is the BeagleBone On A Chip released a few months ago. The Octavo Systems OSD335x is, quite literally, a BeagleBone on a chip. It’s a BGA with big balls, making it solderable with hand-applied solder paste and a toaster oven reflow conversion. In fact, the BeagleBone Wireless was designed by [Jason Kridner] in Eagle as a 6-layer board. It’s still a bit beyond the standard capabilities of OSHPark, but the design can still be cut down, and shows how this BeagleBone on a Chip can be applied to other Open Hardware projects.
[Jason Holt] wrote in to tell about of the release of his PRUDAQ project. It’s a dual-channel 10-bit ADC cape that ties into the BeagleBone’s Programmable Realtime Units (PRUs) to shuttle through up to as much as 20 megasamples per second for each channel. That’s a lot of bandwidth!
The trick is reading the ADC out with the PRUs, which are essentially a little bit of programmable logic that’s built on to the board. With a bit of PRU code, the data can be shuttled out of the ADC and into the BeagleBone’s memory about as fast as you could wish. Indeed, it’s too fast for the demo code that [Jason] wrote, which can’t even access the RAM that fast. Instead, you’ll want to use custom kernel drivers from the BeagleLogic project (that we’ve covered here before).
But even then, if you don’t want to process the data onboard, you’ve got to get it out somehow. 100 mbit Ethernet gets you 11.2 megabytes per second, and a cherry-picked flash drive can save something like 14-18 megabytes per second. But the two 10-bit ADCs, running full-bore at 20 megasamples per second each, produces something like 50-80 megabytes per second. Point is, PRUDAQ is producing a ton of data.
So what is this cape useful for? It’s limited to the two-volt input range of the ADCs — you’ll need to precondition signals for use as a general-purpose oscilloscope. You can also multiplex the ADCs, allowing for eight inputs, but of course not at exactly the same time. But two channels at high bandwidth would make a great backend for a custom SDR setup, for instance. Getting this much ADC bandwidth into a single-board computer is an awesome trick that used to cost thousands of dollars.
We asked [Jason] why he built it, and he said he can’t tell us. It’s a Google Research project, so let the wild conjecture-fest begin!
Over the past few years, the BeagleBone ecosystem has grown from the original BeagleBone White, followed two years later by the BeagleBone Black. The Black was the killer board of the BeagleBone family, and for a time wasn’t available anywhere at any price. TI has been kind to the SoC used in the BeagleBone, leading to last year’s release of the BeagleBone Green, The robotics-focused BeagleBone Blue, and the very recent announcement of a BeagleBone on a chip. All these boards have about the same capabilities, targeted towards different use cases; the BeagleBone on a Chip is a single module that can be dropped into an Eagle schematic. The BeagleBone Green is meant to be the low-cost that plays nicely with Seeed Studio’s Grove connectors. They’re all variations on a theme, and until now, wireless hasn’t been a built-in option.
This weekend at Maker Faire, Seeed Studio is showing off their latest edition of the BeagleBone Green. It’s the BeagleBone Green Wireless, and includes 802.11 b/g/n, and Bluetooth 4.1 LE.
Benchmarks often get criticized for their inability to perfectly model the real-world situations that we’d like them to. So take what follows in the limited scope that it’s intended, and don’t read too much into it. [Joonas Pihlajamaa]’s experiments with toggling a hardware pin as fast as possible on different single-board computers can still show us something.
The take-home result won’t surprise anyone who’s worked with a single-board computer: the higher-level interfaces are simply slow compared to direct memory-mapped GPIO access. But really slow. We’re talking around 5 kHz from Python or any of the file-based interfaces to the pins versus 3 MHz for direct access. Worse, as you’d expect when a non-realtime operating system is in the middle, there are glitches on the order of ten milliseconds with all the file-based methods.
This test only tells us so much, though, and it’s not really taking advantage of the BeagleBone Black’s ace in the hole, the PRUs — onboard hardware processors that bring real-time IO capabilities to the system. We’d like to see a re-write of the code to take advantage of libpruio, for instance. A 20 MHz square wave is a piece of cake with the PRUs.
Of course, it’s not interacting, which is probably in the spirit of the benchmark as written. But if raw hardware speed on a BeagleBone is the goal, it’s likely that the PRUs are going to feature prominently in the solution.