Programming with Rust

Do hardware hackers need a new programming language? Your first answer might be no, but hold off a bit until you hear about a new language called Rust before you decide for sure.

We all know real hackers use assembly language to program CPUs directly, right? Well, most of us don’t do as much assembly language as we used to do. Languages like C can generate tight, predictable code and are easier to manage.

Although some people use more abstract languages in some embedded systems, it is no secret that for real-time systems, device driver development, and other similar tasks, you want a language that doesn’t obscure underlying details or generate code that’s difficult to reason about (like, for example, garbage collection). It is possible to use special techniques (like the Real-Time Java Specification) to help languages, but in the general case a lean language is still what most programmers reach for when you have to program bare metal.

Even C++, which is very popular, obscures some details if you use things like virtual functions (a controversial subject) although it is workable. It is attractive to get the benefit of modern programming tools even if it does conceal some of the underlying code more than straight C.

About Rust

That’s where Rust comes in. I could describe what Rust attempts to achieve, but it is probably easier to just quote the first part of the Rust documentation:

Rust is a systems programming language focused on three goals: safety, speed, and concurrency. It maintains these goals without having a garbage collector, making it a useful language for a number of use cases other languages aren’t good at: embedding in other languages, programs with specific space and time requirements, and writing low-level code, like device drivers and operating systems. It improves on current languages targeting this space by having a number of compile-time safety checks that produce no runtime overhead, while eliminating all data races. Rust also aims to achieve ‘zero-cost abstractions’ even though some of these abstractions feel like those of a high-level language. Even then, Rust still allows precise control like a low-level language would.

Continue reading “Programming with Rust”

Hackaday Links: October 25, 2015

There are dozens of different 3D printable cases out there for the Raspberry Pi, but the BeagleBone Black, as useful as it is, doesn’t have as many options. The folks at 3D hubs thought they could solve this with a portable electronics lab for the BBB. It opens like a book, fits a half-size breadboard inside, and looks very cool.

The guy who 3D printed his lawnmower has a very, very large 3D printer. He now added a hammock to it, just so he could hang out during the very long prints.

There’s a box somewhere in your attic, basement, or garage filled with IDE cables. Wouldn’t they be useful for projects? Yep, only not all the wires work; some are grounds tied together, some are not wired straight through, and some are missing. [esot.eric] has the definitive guide for 80-wire IDE cables.

Like case mods? Here’s a golden apple, made out of walnut. Yes, there are better woods he could have used. It’s a wooden replica of a Mac 128 with a Mac Mini and LCD stuffed inside. Want a video? Here you go.

If you have a 3D printer, you’re probably familiar with PEEK. It’s the plastic used as a thermal break in non-all-metal hotends. Now it’s a filament. An extraordinarily expensive filament at €900 per kilogram. Printing temperature is 370°C, so you’ll need an all-metal hotend.

It’s the Kickstarter that just keeps going and going and going. That’s not a bad thing, though: there really isn’t much of a market for new Amiga 1200 cases. We’ve featured this project before, but the last time was unsuccessful. Now, with seven days left and just over $14k to go, it might make it this time.

Autodesk Open Sources Ember 3D Printer

If you’ve ever been interested in what goes on inside a (roughly) $6000 DLP stereolithography printer, you might want to check out the recent announcement from Autodesk that open sources their electronics and firmware for their Ember 3D printer. The package includes the design files and code for their controller (which is more or less a BeagleBone black with a USB hub, and more memory. It also has two AVR controllers for motor and light control.

Continue reading “Autodesk Open Sources Ember 3D Printer”

BeagleBone Green Hands-On: Lower Price, Same Horsepower

Although the BeagleBone Green was announced at the Bay Area Maker Faire last May, there hasn’t been much said about it on the usual forums and IRC channels. Now, it’s finally out and I got my hands on one of them. Through a cooperation between the BeagleBoard foundation and Seeed Studios, the best small Linux board for doing real work with small Linux boards is now cheaper, a little more modern, and green.

The BeagleBone Green is an update to the venerable BeagleBone Black, the dev board based on a TI ARM Cortex-A8. It’s an extremely capable machine with a few interesting features that make it the perfect device for embedded applications. With the BeagleBone Green, the BB Black gets a small hardware refresh and a drastic reduction in price. If you want to do real work on a Linux board, this is the one to get. Check out the review below for everything that’s been updated, everything that’s the same, and why this is one of the most interesting developments in small Linux boards in recent memory.

Continue reading “BeagleBone Green Hands-On: Lower Price, Same Horsepower”

BeagleBones And Teensies Become KVMs

[pmf], like most of us, I’m sure, spends most of his days on a computer. He also has a smartphone he keeps at his side, but over the years he’s grown accustomed to typing on a real keyboard. He came up with the idea of making a USB switch that would allow his keyboard to control either his computer or his phone, and hit upon a really neat way of doing it. He’s using a BeagleBone Black and a Teensy to switch his keyboard between his computer and his phone with just a press of a button.

This homebrew smart KVM uses a BeagleBone Black for most of the heavy lifting. A keyboard and mouse is connected to the USB host port of the BeagleBone, and the main computer is connected to the device port. The BeagleBone is set up to pass through the USB keyboard and mouse to the computer with the help of what Linux calls a ‘gadget’ driver. This required an update to the Linux 4.0 kernel.

With the BeagleBone capable of being a USB pass through device, the next challenge was sending keypresses to another USB device. For this, a Teensy 2.0 was connected to the UART of the BeagleBone. According to [pmf], this is one of the few examples of the Teensy serving as a composite USB device – sending both keyboard and mouse info.

There are a few neat features for [pmf]’s build: the keyboard and mouse don’t disconnect when switching, and thanks to a slight modification of the USB OTG adapter, this will also charge a phone as well as allow for the use of a keyboard. Because the BeagleBone Black has more than one UART this build can also switch keyboards and mice between more than two computers. For those of us who invest heavily in keyboards, it’s a godsend.

Hackaday Prize Entry: A BeagleBone Logic Analyzer

If you have a BeagleBone, you already have a lot of tools. We’ve seen them used in driving hundreds of LEDs at a very high frame rate, used as a video card for ancient computers, and as a software defined radio. For his entry to The Hackaday Prize, [Kumar] turned his BeagleBone into a 14-channel, 100Msps logic analyzer that’s good enough to debug just about all those hobby electronics projects you’re working on.

The BeagleBone is only able to have this sort of performance as a logic analyzer because of its PRUs, those fancy peripherals that make the Beagle great at blinking pins really, really fast. [Kumar] is using both PRUs in the BeagleBone for this project. PRU1 reads from the input probes, and PRU0 writes all the samples into DDR memory directly. From there, the samples are off to kernel modules and apps, either sigrok, dd, or something you coded up in Python.

Compared to the cheap logic analyzers we have today like the Salae Logic and the DSLogic, [Kumar]’s project is just as good as any commercial offering (provided you can live with 14 channels instead of 16), and because it’s based on a BeagleBone, the software is infinitely expandable.

UPDATE: After this post was written but before it was published, [Kumar] finished up a blog post on how he’s building a logic analyzer with the BeagleBone’s PRUs. It’s a true tutorial, with enough code demos to allow anyone to build their own 8-bit analyzer on a BeagleBone, and there are more updates coming.


The 2015 Hackaday Prize is sponsored by:

1768 LEDs, Because 96 Just Wasn’t Enough

Some people would look at a massive 6’x4′ LED matrix hanging on the wall playing animations and be happy with the outcome. But [Ben] just isn’t one of those people. The original FLED (Fantastic LED thingy) was eight rows of twelve addressable LEDs for a total of 96 pixels. This spring he upped his game and retrofitted the display with 1768 LEDs.

It wasn’t simply an issue of restlessness, the original build suffered from LEDs dying. We actually featured it for that reason as a Fail of the Week.  This is not strictly a hobby project, it’s hanging on the wall in the Supplyframe offices, so pulling it down frequently to fix broken parts is not ideal.

fled-reborn-LED-layoutTo make FLED more reliable [Ben] sourced strips of the new APA102 LEDs which we looked at back in December. They use an SPI bus instead of the bizarre timing scheme of the WS2812. At first glance you’d think this would mean easier assembly compared to soldering both sides of each of the original 96-pixels. These do come in strips, but laying out 52×34 still means soldering to the ends of each row.

A lot of love went into making sure those rows were laid out perfectly. A sheet of white foamed PVC serves as the substrate. There is grounding braid on either end of the rows, one is the voltage bus, the other is ground. It fits the original enclosure which is acrylic and does a great job of diffusing the light. I’ve seen it in person and it looks pretty much perfect!

It’s not just the physical layout of this many pixels that is a challenge. Pushing the data to all of them is much harder than it was with 96. [Ben] transitioned away from RaspberryPi. He considered using a Teensy 3.1 and ESP8266 but the WiFi of these cheap modules is far too slow to push frame information from a remote box. In the end it’s a BeagleBone Black that drives the reborn display. This is a great choice since there’s plenty of power under the hood and a traditional (and much faster) WiFi dongle can be used.

Don’t miss the animation demos found after the break.

Continue reading “1768 LEDs, Because 96 Just Wasn’t Enough”