ARM Pro Mini

Slowly but surely, the age of 8-bit micros being the first tool anyone picks up is coming to an end, and we’re seeing more and more ARM dev boards in nifty, breadboard-friendly packages. [Zapta] thought he would throw his hat into the ring with the ARM Pro Mini, a tiny little board based on the ARM M0 microcontroller.

The ARM chip on this board is the NXP LPC11 with 64 kB of Flash, 12 kB of RAM, and just enough pins to make the whole endeavor worthwhile. The board itself is extremely simple, with just enough SMD parts to be annoying to hand solder.

All the nifty bonuses of ARM boards are available on the ARM Pro Mini, including drag and drop firmware over the USB port, support for single stepping and debugging, and the IDE is a single install with NXP Eclipse/LPCXpresso. Mbed is also supported, so it’s possible to use this board with no software installs when using the online Mbed IDE.

[Zapta] has put everything you need to build this board up on his Github, and has even done a few simple ‘getting started’ tutorials, including a cool little example with a graphics library and a small OLED.

ZX81 Emulated on an mbed

This is a wonderful example of the phenomenon of “feature creep”. [Gert] was working on getting a VGA output running on an mbed platform without using (hardly) any discrete components. Using only a few resistors, the mbed was connected to a VGA display running at 640×480. But what could he do with something with VGA out? He decided to emulate an entire Sinclair ZX81 computer, of course.

With more than 1.5 million units sold, the Sinclair ZX81 was a fairly popular computer in the early ’80s. It was [Gert]’s first computer, so it was a natural choice for him to try to emulate. Another reason for the choice was that his mbed-VGA device could only output monochrome color, which was another characteristic of the ZX81.

[Gert] started by modifying a very lean Z80 emulator to make the compiled code run as efficiently as possible on the mbed. Then he went about getting a picture to display on the screen, then he interfaced an SD card and a keyboard to his new machine. To be true to the original, he built everything into an original ZX81 case.

This isn’t the first time we’ve seen a ZX81, but it is one of the better implementations of an emulated version of this system we’ve seen.

Thanks to [Jeroen] for the tip!

Towards More Interesting Instant Cameras

When [Ch00f] was getting jeans rung up at Nordstroms, he noticed how fast thermal receipt printers can put an image on a piece of paper. This observation isn’t unique to the circles [Ch00f] frequents – there are a few small receipt paper printers out there that connect to the Internet, iPhones, and a whole bunch of other Kickstarter-friendly keyword devices.

Nevertheless, a device that can make a hard copy of an image quickly and cheaply isn’t something you just stop thinking about. After rolling the concept around in his head for a few years, [Ch00f] finally came up with the perfect build – a camera.

The hardware for the build is based around an STM32F4 Discovery board. It’s a bit overpowered for this sort of application, and this is one of [Ch00f]’s first adventures in ARM-land. The rest of the hardware consists of a thermal receipt printer and a JPEG camera, the latter of which replaced a cellphone CMOS camera module that was lost in a move.

A custom camera requires a custom enclosure, and for this [Ch00f] made something remarkable. The entire enclosure is CNC milled out of a beautiful piece of figured walnut. The end result looks far too good for a prototype, but it does polish up nicely with a bit of linseed oil.

Now [Ch00f] has an instant camera that takes the idea of a Polaroid and turns it into something that produces a print for tenths of a cent. There’s a time-lapse function – just a zip tie on the shutter button – filters with the help of highlighters, and the ability to record movies in flipbook format.

It’s a great project, and also something that will make for a great crowdfunding campaign. [Ch00f] has already started work on this. He already has a sleek, modern-looking website that requires far too much scrolling than should be necessary – the first step to a winning Kickstarter. [Ch00f] also learned a lot about ARMs, DMA, dithering, gamma correction, and the JPEG format, but that’s not going to get anyone to open up their wallet. You know what will? A slick video. You’ll find that below.

Continue reading “Towards More Interesting Instant Cameras”

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.

goom2

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”