The Most Minimal WS2812B Driver

Whether you call them individually controllable RGB LEDs, WS2812, or NeoPixels, there’s no denying they are extremely popular and a staple of every glowey and blinkey project. Fresh off the reel, they’re nearly useless – you need a controller, and that has led to many people coming up with many different solutions to the same problem. Here’s another solution, notable because it’s the most minimal WS2812 driver we’ve ever seen.

The critical component in this build is NXP’s LPC810, an ARM Cortex M0+ in an 8-pin DIP package. Yes, it’s the only ARM in a DIP-8, but still able to run at 30MHz, and hold a 4kB program.

JeeLabs is using the SPI bus on the LPC810 to clock out data at the rate required by the LEDs. The only hardware required is a small LED to drop the voltage from 5V to 3.3V and a decoupling capacitor. Yes, you could easily get away with this as a one-component build.

The build consists of a ring of sixty WS2812b RGB LEDs, and the chip dutifully clocking out bits at the correct rate. It’s the perfect start to an LED clock project, an Iron Man arc reactor (are we still doing those?), or just random blinkey LEDs stuffed into a wearable.

Thanks [Martyn] for sending this one in.

A 16-voice Homebrew Polyphonic Synth

Homebrew synths – generating a waveform in a microcontroller, adding a MIDI interface, and sending everything out to a speaker – are great projects that will teach you a ton about how much you can do with a tiny, low power uC. [Mark] created what is probably the most powerful homebrew synth we’ve seen, all while using a relatively low-power microcontroller.

The hardware for this project is an LPC1311 ARM Cortex M3 running at 72 MHz. Turning digital audio into something a speaker can understand is handled by a Wolfson WM8762, a stereo 24-bit DAC. Both of these chips can be bought for under one pound in quantity one, something you can’t say about the chips used in olde-tyme synths.

The front panel, shown below, uses 22 pots and two switches to control the waveform, ADSR, filter, volume, and pan. To save pins on the microcontroller, [Mark] used a few analog multiplexers. As far as circuitry goes, it’s a fairly simple setup, with the only truly weird component being the optocoupler for the MIDI input.


The software for the synth is written mostly in assembly. In a previous version where most of the code was written in C, everything was a factor of two slower. Doing all the voice generation in assembly allowed for twice as many simultaneous voices.

It’s a great project, and compared to some of the other synth builds we’ve seen before, [Mark]’s project is at the top of its class. A quick search of the archives says this is probably the most polyphonic homebrew synth we’ve seen, and listening to the sound sample on the project page, it sounds pretty good, to boot.

A Simple Runner’s GPS Logger

[Daniel] received a grant from the University of Minnesota’s ECE Envision Fund and was thus responsible for creating something. He built a runner’s GPS logger, complete with a screen that will show a runner the current distance travelled, the time taken to travel that distance, and nothing else. No start/stop, no pause, nothing. Think of it as a stripped-down GPS logger, a perfect example of a minimum viable product, and a great introduction to getting maps onto a screen with an ARM micro.

The build consists of an LPC1178 ARM Cortex M3 microcontroller, a display, GPS unit, and a battery with not much else stuffed into the CNC milled case. The maps come from OpenStreetMap and are stored on a microSD card. Most of the files are available on GitHub, and the files for the case design will be uploaded shortly.

The CNC machine [Daniel] used to create the enclosure is a work of art unto itself. We featured it last year, and it’s good enough to do PCBs with 10 mil traces. Excellent work, although with that ability, we’re wondering why the PCB for the Runner’s GPS is OSH Park purple.

[Sprite_TM]’s Keyboard Plays Snake

Hackaday Prize judge, hacker extraordinaire, and generally awesome dude [Sprite_TM] spends a lot of time at his computer, and that means a lot of time typing on his keyboard. He recently picked up a board with the latest fad in the world of keyboards, a board with individually addressable LEDs. He took this board to work and a colleague jokingly said, ‘You’ve had this keyboard for 24 hours now, and it has a bunch of LEDs and some arrow keys. I’m disappointed you haven’t got Snake running on it yet.” Thus began the quest to put the one game found on all Nokia phones on a keyboard.

The keyboard in question is a Coolermaster Quickfire Rapid-I, a board that’s marketed as having an ARM Cortex CPU. Pulling apart the board, [Sprite] found a bunch of MX Browns, some LEDs, and a 72MHz ARM Cortex-M3 with 127k of Flash and 32k of RAM. That’s an incredible amount of processing power for a keyboard, and after finding the SWD port, [Sprite] attempted to dump the Flash. The security bit was set. There was another way, however.

Coolermaster is actively working on the firmware, killing bugs, adding lighting modes, and putting all these updates on their website. The firmware updater is distributed as an executable with US and EU versions; the EU version has another key. Figuring the only difference between these versions would be the firmware itself, [Sprite] got his hands on both versions, did a binary diff, and found only one 16k block of data at the end of the file was different. There’s the firmware. It was XOR encrypted, but that’s obvious if you know what to look for.

flashdata The firmware wasn’t complete, though; there were jumps to places outside the code [Sprite] had and a large block looked corrupted. There’s another thing you can do with an executable file: run it. With USBPcap running in the background while executing the firmware updater, [Sprite] could read exactly what was happening when the keyboard was updating. With a small executable that gets around the weirdness of the updater, [Sprite] had a backup copy of the keyboard’s firmware. Even if he bricked the keyboard, he could always bring it back to a stock state. It was time to program Snake.

The first part of writing new firmware was finding a place that had some Flash and RAM to store the new code. This wasn’t hard; there was 64k of Flash free and 28K of unused RAM. The calls to the Snake routine were modified from the variables the original firmware had. If, for example, the original keyboard had a call to change the PWM, [Sprite] could change that to the Snake routine.

Snake is fun, but with a huge, powerful ARM in a device that people will just plug into their keyboard, there’s a lot more you can do with a hacked keyboard. Keyloggers and a BadUSB are extremely possible, especially with firmware that can be updated from a computer. To counter that, [Sprite] added the requirement for a physical condition in order to enter Flash mode. Now, the firmware will only update for about 10 seconds after pressing the fn+f key combination.

There’s more to playing Snake on a keyboard; Sprite has also written a new lighting mode, a fluid simulation thingy that will surely annoy anyone who can’t touch type. You can see the videos of that below.

Continue reading “[Sprite_TM]’s Keyboard Plays Snake”

Down the Rabbit Hole of STM32 Clock Options

Once you venture beyond the tame, comfortable walls of the 8-bit microcontroller world it can feel like you’re stuck in the jungle with a lot of unknown and oft scary hazards jut waiting to pounce. But the truth is that your horizons have expanded exponentially with the acceptable trade-off of increased complexity. That’s a pretty nice problem to have; the limitation becomes how much can you learn.

Here’s a great chance to expand your knowledge of the STM32 by learning more about the system clock options available. We’ve been working with STM32 chips for a few years now and still managed to find some interesting tidbits — like the fact that the High Speed External clock source accepts not just square waves but sine and triangle waves as well, and an interesting ‘gotcha’ about avoiding accidental overclocking. [Shawon M. Shahryiar] even covers one of our favorite subjects: watchdog timers (of which there are two different varieties on this chip). Even if this is not your go-to 32-bit chip family, most chips have similar clock source features so this reading will help give you a foothold when reading other datasheets.

There is a clock diagram at the top of that post which is small enough to be unreadable. You can get a better look at the diagram on page 12 of this datasheet. Oh, and just to save you the hassle of commenting on it, the chip shown above is not an f103… but it just happened to be sitting on our desk when we started writing.

100% DIY Intervalometer is 100% Awesome

It’s easy to tell from this process documentary that [Nagyizee] is not one to settle for prefabricated anything. He could have just bought some off-the-shelf DSLR intervalometer, but that would mean interfacing with someone else’s design through cold, soulless plastic.

[Nagyizee] wanted a one-of-a-kind tool built from the ground up. In addition to a timer, he was in the market for a light sensor and sound detection. He chose an STM32F100 ARM Cortex M3 running at 8MHz in the name of power efficiency and started designing the UI and firmware. A custom graphic library for the OLED display streamlines it even further. Once the schematic was finalized, [Nagyizee] devised a stylish and ergonomic wooden case to be milled with a tiny Proxxon F70.

With the enclosure decisions out of the way, he etched and drilled the PCB and placed the components. The light sensor needed a lens and a prism, so he made one from a 10mm LED body. Not one to miss a detail, [Nagyizee] also turned some buttons, hand painted them, and made a scroll wheel. He ends the video with a demonstration that proves it is quite capable. In addition to standard cable release mode, it handles long exposure times, sequential shooting, and capture on light, shadow, or sound. But wait, there’s more: [Nagyizee]’s creation combines modes with ease and grace.

Continue reading “100% DIY Intervalometer is 100% Awesome”

Arietta G25 Has Us Wondering Where ARM Boards are Going


This tidy little ARM board is the Arietta G25. It’s based around an AT91SAM9G25 which is an ARM9 chip running at 400MHz. Paired with the DDR2 RAM (in 128 or 256 meg options) to the left, the board runs Linux and runs it well. After the break you can see the obligatory running of Doom. But in this case it doesn’t just run a demo, but is playable from momentary push buttons on a breadboard (props to the Arietta team for using wire wrap for that setup).

See the vertical row of pads between the processor and the SD card slot? That’s a breakout header designed to accept a WiFi module. In at €20-30 based on your RAM choice and just €7 for the WiFi module this board is certainly a contender for any embedded Linux projects. But it does have us wondering, should be thinking of these as ARM boards, or forget the low-level development and just think of them as a Linux machines with plenty of GPIO available?

The 20×2 pin header breaks out a lot of the SAM9’s features. We really like the interactive pinout posted for this device. For instance, there are three sets of USB host lines available. But you’ll want to click on each to see that one set is in use for the SD card, and another is used by the WiFi module. The documentation that has been posted for the Arietta G25 is one of its strongest point. Nice work there!

Continue reading “Arietta G25 Has Us Wondering Where ARM Boards are Going”