Archive for the 'General' Category

todo.vim and vdb.vim: making reading stuff easier

Sometimes I get tired of hardware work, so I screw with vim for a while. I decided to write a few syntax highlighters for two of my common use cases: storing key:value pairs and making todo lists. Right now both bundles are in my .vim repo but I’ll probably split them out into their own repositories soon.

The vdb format is just a way to easily visualize hierarchical key:value pairs.

todo.vim provides some highlighting and key macros for making and editing todo lists.

First Results from Beat Tracker!

So I finished a preliminary version of my live beat tracker, bt. I fed in a 126 BPM song and got:

The software reads a data stream from the FPGA and prints out a cute little UTF-8 table and keeps track of the best average tempo. The FPGA handles all of the hard work: running a lot of metronomes (I can fit upwards of like 80-100 on there), and classifying beats.

That’s the good news. The not so good news is that the beat classifier, the thing that says “I think I found a beat, does it match any of the metronomes?” needs some serious improvement and tweaking before it can actually classify most songs. K-Pop works really well right now because the differential between beat energy and not-beat energy is very large — a metronome is basically built right into the track. On the other hand, it doesn’t get dubstep at all.

And we’re (more or less) back…

Wow. My last post was in late July. I’m not really sure what happened in August, but this semester has been hitting me repeatedly with a bag of bricks. Every time I think that I can spend a few hours working on personal projects, it turns out that I just forgot about something else that I had to do. I thought senior year was supposed to be easy. 🙁

Anyways, this post is a general update on what’s been going on and where some of my projects are headed.

LED Controllers

I’m so sad that I’ve essentially left ACRIS untouched since the beginning of the semester. Also, I haven’t even come close to finishing documentation for it yet. SADNESS

‘sokay though because I’m finally getting back to working on it, even if I should be doing other things. I found a couple of bugs in the first boards that I made, but they should be fixed for the next revision. I’m hoping to start selling them as kits at some point, but I need to work out a few details before I’m ready to do that. In particular, the parts are expensive. I really wish I could make the board modular somehow so that you could add any number of LED controllers onto the board. Also, I’m tying the outputs of the LED driver together in groups of 3, but that may not be what a user wants. What’s the best solution for that? IDK yet.

To whet your appetite:

At any rate, I’m hoping the project will be good enough for Hackaday. I’ve been working hard on it, but I never really know if the work I do is good enough for others to find interesting.

Tor for Microcontrollers

For the computer security class I’m taking, I’ve decided on a kind of weird (and probably a bit stupid) final project: Tor for AVRs. The idea is that if you have a mesh network of devices, you may want one device to securely communicate with another without knowing who the source really is. To demonstrate this, I need an array of AVRs… I was hoping to get some funding, but it looks like I’ll need to buy everything myself. I’ll be documenting this over the next few weeks. (I also need an entertaining name.)


Two of the classes I’m taking this term are particularly interesting. 6.828 is an operating systems engineering class. It’s basically a lot of C, but I particularly like it because it balances classroom instruction with a lot of coding. The labs in the class have you implement core aspects of an exokernel-like operating system. The most entertaining part is that when you run into a bug, it’s usually because you implemented something wrong 3 labs ago. It makes for fun times.

Proficiency with gdb is pretty much essential. A while ago, a coworker pointed me to this article on how to pimp your gdb with a few features that allow you to see how your code is running.

Also, I’ve recently added cscope support to my vim configuration. My productivity has skyrocketed when coding in C (ctags is still useful for other languages).

6.858 is a computer security class. I’m also enjoying the labs in this class, which are approximately split evenly between teaching methods for attacking systems and defending them. The first lab, for example, taught a few buffer overflow attack techniques.

Other Stuff

I’ve updated my blogroll a bit. I also plan to recategorize a lot of my older posts to make searching and so forth easier.

Soldering things you can’t really see: building an AC’97 Pmod for Nexys2

Many boards manufactured by Digilent have a uniform type of plugin interface they call “Pmods.” They provide a bunch of IO pins as well as VCC and ground. Pmods can do pretty much everything as long as they can fit into 8 signal lines.

I’ve been looking for a good way to get audio signals into the FPGA. One way would be to use an ADC. Generally, this isn’t too hard to do, but you need to scale and bias the audio line correctly so that it takes the full width of the ADC and is located in the center part.

Another option is to use an audio codec chip. The UCB1400, for example, is an AC’97 chip; it provides a simple serial interface for both inputting and outputting audio streams. I was originally hoping that I could just buy a Pmod containing an AC’97 chip and connectors, but I wasn’t able to find anything online.

So, I then decided to try to include an AC’97 interface in the auxiliary board that I am designing for ACRIS (the board has to do many things, including routing the data from the FPGA out to the LED controllers). But fortunately, I found out that Chris Terman, a Course 6 professor here at MIT, already designed a Pmod for the Nexys2. After contacting him, he gave me the parts to build a bunch of boards and debug his design.

The fun part: the board uses surface mount components, including 0402 resistors and caps. How small are 0402s? This small:

The trickiest part is installing the UCB1400. It’s in a 48-LQFP package, so the pins are very close to one another. I found that the best way to solder the package was to tack down a corner or two, then go to an opposite side and apply a tiny bit of solder at one end. I then raked the iron back and forth across the pins (in the method known as drag soldering), but due to the nature of the pins, I had to use a good amount of solder, which meant that when I was done, all the pins were bridged together. Finally, I used a solder wick to unbridge the pins. The only major problem I had was the initial alignment of all the pins. A slight rotation or shift causes them to become mismatched to the pads.

The results, though, were pretty good:

Next, I’ll be working on controlling the board with the FPGA.

Nexys2 Board Testing

After ordering my Digilent Nexys2 eval board with a 500K-gate Xilinx Spartan-3E and a variety of I/O devices, I never got around to testing it (other than to use the factory-programmed image on the PROM). I brought it to my dorm when I moved back in a few days ago and have had some free time to play around with it.

This is just a very simple example. The board takes two bytes of input and then acts on the data. The first byte says which LEDs to modify (e.g. 11100000 would modify LEDs 0, 1, and 2). The second tells which value to set them all, as a number from 0 to 255. The data is then read into a controller that stores the new value and specifies the brightness of the LED via a PWM block.

Once I got that up and running, I just wrote a few macros that would allow me to set the LEDs. The “chase” macro simply sets an LED and then diminishes the ones behind it. The “grad” macro simply makes a gradient. Currently, I’m implementing Xilinx’s FFT core so that I can take the FFT of some serial data and control the LEDs as necessary.

My implementation can be found here (just create a new project, load this design in, with serpwm.vhd as the top level, and specify the pins: TXD, RXD, LEDS, and clk).