Aaron's Sandbox

Long ago, I used to make simple blinkin' LEDs projects using Microchip PIC devices. I had a cheap programmer, accessed over the parallel port, and the requisite set of simple tools from the manufacturer. It was all perfectly adequate for good clean LED fun. Lately, I've been feeling nostalgic for these simple projects. I want to make some simple hardware, and write simple software to make it go. While I'm making the project, I'll try out this new-fangled habit of keeping records in a publicly-accessible location, just in case 1) someone out there finds my notes useful and 2) the process forces me to usefully document the project for myself.

But! Time has passed. My PIC programmer is somewhere in deep storage, and my current computer doesn't even have a a parallel port. It's time to upgrade, and it looks like while I wasn't paying attention, some nice microcontrollers, complete with C compiler, showed up.

So here's my plan:

Mission: make the wonderful eZ430-F2013 do something cool. That sounds good, but too abstract, therefore:
More-Specific Mission: Add IR-remote-accesible turn-on function to my Xbox. I upgraded an ebay-procured Xbox with Xbox media center, and I like it, but the box can't be turned on via the remote when it's off. This problem has already been solved here, but I think I'd like to do it myself.
Less-Specific More-Specific Mission: During the design phase, think carefully about how to make the hardware and software modular, for a reusable platform. Some interesting module boundaries:

1. IR carrier frequency module
2. IR protocol module
3. Exec module (what action(s) to take upon receipt of specific IR codes)

Development environment: I've previously only done the simplest of projects using the F2013. Working with a new microcontroller is process of exploration - learning how to configure the various hardware peripherals can be a matter of trial and error - the best way to get familiar is to fool around with it. To streamline that process, I'm going to embed my F2013 in a 1C20 development board, for complete control of all the pins and logic-analyzer function, all without touching a wire. Then I can create and download a new testbench environment over one USB cable, and compile and download new software to the F2013 over another.

The standard procedure for developing a simple microcontroller project used to be:

1. Get the testbench ready with power supplies, scope and any required signal sources


2. Grab the breadboard and the handy collection of already-stripped 22GA wire


3. Straighten the micro's pins and plug it into the breadboard, along with any LEDs, buttons or other stuff needed for the project


4. Start code development. The last time I was doing this, the cycle was
   
   
   
   1. Write some code
   
   
   2. Grab a blank device from the UV eraser
   
   
   3. Plug it into the programmer's ZIF socket and program it
   
   
   4. Put the programmed part on the breadboard, and try it out
   
   
   5. Notice bugs, return the chip to the UV eraser. While the device is being erased, come up with ideas for how to fix the bug
   
   
   6. Back to the start!
   
   
   
   

Things are simpler now: there's no need for UV erasers, for one thing. The tools are better too: rather than instrumenting the code to transmit state information over a UART, or blink LEDs at specific execution points, just single-step through the code in the IDE. Still, it's not perfect. Here's my simplest-possible project, which makes an LED throb from full bright to full dark over several seconds:

There are a few good things I can say about this method: it's simple and cheap. But mostly I don't like it: there's too much physical manipulation of wires and chips; it's too easy to accidentally destroy something; I'm always running out of the right kind of wire, the breadboard contacts wear out; hooking up scope probes is always troublesome - they seem to be carefully designed to rotate and jump off their clip point, then fall to the floor, dragging the breadboard with them - anyway, you can only probe the points which happen to be wired out to pins; creating a custom signal source which, say, mocks up some aspect of the application, for testing or analysis, probably means finding another breadboard to wire up, since the first one fills up quickly.

Of course I wouldn't be complaining about all this so much if I didn't have a solution in mind. Next: a better way.