Monthly Archive for February, 2012

Ideas for Future ACRIS Firmware

I’m still procrastinating on the work I have to do by Friday, but whatever… I had more ideas for ACRIS. I just can’t seem to shut up about LEDs.

Anywayyyyyyyys… I had some ideas for future versions of the ACRIS board firmware. Right now, you do 0xAA followed by the instrument address followed by 5 (R,G,B) pairs. I want to retain this as a “simple control mode” and then add an “advanced control mode” that would look like 0x55 followed by the control command followed by its arguments.

Ideas for this mode include:

  • baud rate setting: You can set a different baud rate. Then, you need to send it some pre-defined pattern of bytes. If the system doesn’t receive what it expects within some time period, it’ll go back to the old mode (like screen resolution changes)
  • color correction mode: You can specify whether to do brightness/gamma correction. If so, then the system will try to make the input linear with what your eyes see. This requires some math and/or a lookup table.
  • resolution: Switch between 8-bit and 12-bit resolution.

Plus, I think it’s finally time to enable device-based transmission. That is, right now, all data flows one way: from my computer to the lights. However, I allowed for devices to switch to from receive to transmission mode. As long as no more than one device talks at once, then things will be okay. I want to do stuff like have the device tell the host its status if the host asks for it.

Power LED Matrix for ACRIS

I wanted to demo the ACRIS boards at MIT’s annual HKN Project Expo. This is a simple expo run in part by the EECS department at MIT. The idea is to provide a space for EECS students to show off cool stuff they’ve made. There were all sorts of projects: software, vehicles (Jordan showed off Segboard!), tesla coils, and, of course, blindingly-high-power LEDs. 🙂

My goal was to show off the ACRIS boards because I one day want to turn them into kits. But, the only completed lights I had were the wall sconces I made. So, I decided at the last minute to build a big LED matrix using a piece of sheet metal a friend found for me.

How last minute? I started at 2am the day of the expo and finished at about 10am. 8 hours. 20 LEDs (80 pads to solder to including 20 triple-point-to-point connections), 80 wires. Yeah. I’m tired.

But the result was this really derpy LED matrix held together with lots of Gorilla Tape.

It all began with the top of a rack server (at least that’s what I think it was).

I divided it up so that I would have a 5×4 array of LEDs. My original plan was to drill holes in the board and then screw the LEDs down like I usually do. Unfortunately, MITERS was closed by 3am, so 🙁

Next, I set to work modifying my ATX power supply. I added barrel plugs onto some wire and hooked those up to the 5V line on my power supply.

I had already built the rest of my LED controllers. I have a little army of them now. 🙂

Oh crap. Is that the sunrise?

Time to get serious. I started soldering the LEDs together by connecting all of the VCCs together. My plan was to have 4 columns of LEDs with 5 LEDs per column. Each column would be controlled by its own ACRIS LED controller.

Soldering the VCC lines were tricky because it was effectively a triple-point-to-point weld. And I was starting to get frantic.

Next, it was time to solder more wires on. All these wires I needed to connect to the LED board too… Eep what a mess!

All right, that looks a little better. Gorilla Tape to the rescue!

Lots of soldering, continuity testing, etc. later, I wired everything up. By this point, it was like 10:30 and I had literally a few minutes to run over to the expo.

Close call! But it worked beautifully on the first try. By some miracle, even despite the sleep deprivation, I didn’t screw up any of the LED connections. I had written a really quick visualization algorithm to show the power of the LED board. I wanted to add more plugins, but didn’t get a chance to.

I ended up getting second place and winning a little money. ACRIS is a little more funded now. 🙂

I’m really hoping to get back to working on the boards again soon. I have a lot of new ideas I want to test out. My friend Scott is working on a USB-based version.

Music Visualization Framework Started!

Check this out:

I’m using PyAudio to capture data from my sound card. Right now, I’m just using audioop’s RMS feature to make a loudness meter.

New Glow-ey Project

I was looking at some empty glass Coke bottles the other day and started wondering how I could make something beautiful out of them. Since I can’t seem to shut up for 2 minutes about high-power LEDs and music visualization, I started envisioning some kind of music visualizer based on glowing bottles.

Not sure what the best material to use is yet. My thought is that UV glow paint might work well, but it can be kind of expensive.

I bought a ton of glowsticks off of Woot a while ago, so I’ve been wondering how I can use them. I decided to crack a few open to test things out.

The first one I opened was blue. I first cracked the glass vial inside it, let the reaction finish, and then held it up to a UV light. Then, I added some water to see how much I could dilute it.

I noticed that the material wasn’t dissolving too well. Also, I couldn’t tell where the fluorescent dye was located. A glowstick basically has two parts: the first is a reservoir of hydrogen peroxide; the second contains dye and some other stuff. When glass vial is broken, the peroxide mixes and causes a chemical reaction to occur. However, the dye itself can also respond to a UV light and that’s what I’m trying to take advantage of.

I decided to open up two red glowsticks to see… Turns out, for these glowsticks, the dye is located in the vial (most times, the peroxide is in the vial).

So, I wrapped the very tip with a paper towel and used a pair of diagonal colors to chip off the very top and pour it into a Coke bottle. Awesome picture ahead:

Here’s what two vials worth of glowstick dye look like in the bottle.

I tried adding water. Looked okay at first:

But it separated out! Damn… it must be oil-based.

So I carefully got the bubble out of the bottle of water (tipped it upside down, waited for the bubble to fall down to the bottom, let it out). Then, I refilled the bottle with a bit of olive oil to see if it would mix with the oil. Turns out, it does!

(the stuff at the bottom is just excess water… ignore it.)

Unfortunately, you can’t use olive oil forever — it’ll just go rancid. So, you need to use mineral oil, which isn’t particularly cheap. Maybe it would better to use these glass vials of dye in their own project. I could easily make some kind of visualizer out of them. Perhaps I’ll save the Coke bottles for a future project.

(Sorry about the crappy photos — I was using my phone).

ACRIS communication fixed for realz this time(?)

I have been fighting with this problem for a year. I was so convinced that my board fix for ACRIS would stop the issue of the boards randomly stopping to process data. I thought I could fix everything by adding pulldown resistor to force the communication chips to be in read mode when the microcontroller wasn’t telling them what to do.

Wroooooooooooooooong. 🙁

Turns out, it’s a software problem. It’s always a software problem. Seriously. I encounter so many software bugs compared to electrical bugs, it’s not even funny. Well maybe a little bit, but whatever. Even if it isn’t a software problem, usually you can fix your problem in software.

I noticed that when I unplugged the communications links and plug the lines back in, I could force the lights to freeze. So, there was something going on with the RS-485 chip, I thought.

So, I immediately read the datasheets of the SN75176B (the TI chip I use) and the MAX485 (the RS-485 chip made by Maxim, which is over 3 times as expensive). “A-ha!” I told myself, “clearly the issue is that the SN75176B produces unknown voltages when the comm link is broken whereas the MAX485 guarantees a logic ‘1’ output.” Therefore, the AVR must be going a little crazy, stopping communication. I was so convinced that I even started writing a blog post on how much cheap stuff sucks before even testing my theory.

Okay, turns out that wasn’t the issue because I made a little test setup:

On this board are two AVR microcontrollers with corresponding RS-485 chips. The left microcontroller uses tha MAX485 and the right uses the SN75176B. Much to my surprise, the SN75176B was actually better at not dying when I started disconnecting and reconnecting the communications cables.

So what was going wrong? I investigated by having the debug LEDs show the various error registers. Turns out, sometimes when you disconnect and reconnect the cable, you get framing errors (FE0 in UCSR0A is on). But wait, there’s more! When the communication freezes, the whole AVR slows down to a crawl. A .1ms operation takes a good 10 seconds or so… very odd. My guess is that sometimes, a framing error occurs and the receive interrupt is stuck in a loop waiting for it to complete. As a result, the chip seems to be running slowly. By temporarily stopping the interrupts, resetting the UART, and re-enabling the interrupts, I can save the communications bus.

Oh, one more thing. For the rework I posted above, I used 10K resistors for the pulldowns. That was stupid; I should have tested things first. For the MAX485, 10K pulldowns are more than enough. But take a look at what happens when I first start up the SN75176B.

(You don’t want to know how long it took me to get that damn picture).

10K pulldowns are apparently too weak. After using a 1K pulldown instead, things looked much better:

I should have tested that out before I reworked my lights, but unfortunately, they’ll have to stay like that because I don’t feel like taking them down and fixing them again.

I’ve been running them for almost 9 hours now at the highest brightness with very fast communication and they haven’t failed once. So I think the problem is fixed.

Making Xilinx Suck Less: A Better Build Environment

One of the biggest problems with the Xilinx workflow is that it doesn’t adhere to the way that people typically work on their projects nowadays. The Xilinx tools basically vomit intermediate build files and log files all over your build directory, making it hard to tell which files are the ones that are important (i.e. modifiable by you) and which ones are just debris.

Can we fix this? Mostly, yeah. Here’s how. These are the things I wanted to have happen:

  • Compatible with version control software — all build files should go in a separate directory from config files and source files
  • Completely command-line build and programming process (so that I can easily automate what I’m doing)
  • Easily-available logs and reports

    So, I have a directory structure that goes like this:

  • gen/ — Coregen-generated files
  • hdl/ — VHDL sourcecode
  • proj/ — project config files
  • xil/ — build files generated by Xilinx tools
    • xil/xst — I’ll get to these later
    • xil/ngdbuild
    • xil/map
    • xil/par
    • xil/trce
    • xil/bitgen
    • xil/reports — Final spot for all logfiles generated
  • other crap

This way, I can just add xil to my .gitignore file and all the build files will be ignored, but everything else will be tracked. I can easily switch between code branches without having to worry that my project files will be stale. Perfect!

All right, now to tackle the next problem: how do you actually make Xilinx follow these standards? Well, I created a build script (note: I am ashamed to say that I still have pretty much no clue how Makefiles work, so I just wrote a shellscript). Here’s how I built it. Knowing this process will help you to set up your own projects for command-line building.

  1. The first step is to just make your project with the Xilinx ISE GUI. It will automatically set up all the files you need for building. Yes, you can make all these config files yourself, but that’s a huge pain and you only need to do this once.
  2. After you set up a project with the GUI, build it all the way through generating a bitfile. This will allow you to figure out what commands ISE actually runs in order to produce your buildfiles. You can find these commands in the logs that are generated (search for “Command Line:”).
  3. Now check out this build script. You should be able to roughly match each command that ISE runs with a command here. Basically, the process for going from HDL to a bitfile is this:
    1. xst takes your sourcefiles and generates an NGC file
    2. ngdbuild takes your NGC file and generates an NGD file
    3. map takes the NGD file and makes an NCD file
    4. par takes that NCD file and does placement and routing, producing another NCD file
    5. trce uses that NCD file to check timing constraints and stuff
    6. bitgen also uses the NCD file to create a BIT file

    By passing some special flags into each of the programs, we can tell them where to store all their intermediate files, making things nice and neat!

  4. The build script I included needs some modification so that it works with your project. Based on what you see from ISE and from this buildscript, you should be able to modify the command line switches to get what you want. Also, take a look at the Xilinx Command Line Tools reference guide.
  5. You’ll need the following project configuration files from the project you generated with ISE (projname being the name of your project). Put these in your proj/ folder.
    • projname.lso
    • projname.prj
    • projname.ut
    • projname.xst

    You should also put your UCF file in your proj/ folder.

  6. Check projname.prj to make sure that the HDL source files are with relation to your base directory (if you follow my design, they should look like hdl/something.hdl).
  7. projname.xst needs to be modified a bit.
    1. tmpdir should be xil/xst/tmp
    2. xsthdpdir should be xil/xst
    3. Make sure there is a line that looks like -lso proj/projname.lso after the run command. If not, add it.
  8. Finally, I have a batch script for Impact for programming my device (ML605 for me). This is highly dependent on what board you have, but here’s my batch file. To make your own, consult the Impact documentation and also run the Impact GUI and watch for the commands it runs in the command window when you program your board.

Yeah, it’s a bit of a process for getting things to work, but once they do, your productivity should go up quite a bit. Once you get used to this design anyways, it’s easy to create new projects that look similar. Best of all, they’re very compatible with version-control programs.

Yay, now Xilinx ISE sucks a little less! 🙂

Making Xilinx Suck Less: Replacing Chipscope

I’ve spent January doing some initial work on my thesis. I’m working on channel emulation for the Airborne Networks Group of MIT Lincoln Lab. My work involves the use of a sweet FPGA eval board (Xilinx ML605, which has a Virtex 6) and an even sweeter addon board that has two high-speed (i.e. expensive) ADCs and DACs on it.

Unfortunately, interfacing the addon board (called FMC110) is a complete pain in the ass thanks to the complete lack of implementation specifications. It’s been a lot of reverse-engineering 4DSP’s reference design and taking guesses and I’m still having no luck with even the most basic aspects of interfacing the board, but nevertheless I’m still trying.

I use Chipscope a lot since I don’t have a logic analyzer. Chipscope is an FPGA-integrated logic analyzer that lets you capture data on your FPGA and view the waveforms on your computer using their software.

It works pretty well. I’ve found that you have to put everything into registers before you send the data out (pipelining everything), but other than that, integration is very easy.

What sucks, though, is the Chipscope software. The waveform viewer is written in Java and doesn’t even support horizontal scrolling. Come on. Seriously? Like literally the most important thing you should ever have in a waveform viewer is the ability to easily scroll around. Chipscope lacks a whole bunch of other features so I’ve been anxious to get rid of it. I didn’t know that you could until I discovered that if you go to File -> Export, you get this window:

Turns out, there are waveform viewers that are free and are actually reasonable! For example, GTKWave! So, by exporting all the buses to a VCD file, you can import this file into GTKWave and view your signals without the misery of having to use Chipscope. Check it out: