Over the weekend, I received one (1) box of electronic junk. Not just any box of electronic junk (as I have many of those, as it is), but one Great Internet Migratory Box of Electronic Junk.

As per the TGIMBOEJ rules, I took some junk treasures and replaced it with a bunch of my own junk stuff.

And, as per the rules, I took a handful of photos of some of the stuff I pulled out. Not all.

I did not take photos of the stuff I put in. That is for the next person on the list to discover fully. Some vague clues, though: I added some antique semiconductors, some power management related componentry, some completely random small bits of goodness, a working caseless gigabit switch, and a purely mechanical device that is gloriously elegant in its implementation. And some other stuff, too.

More TGIMBOEJ pr0n on the click through….

I have no need — have many already — of the parts pictured at right. But I don’t have them in such an elegant construct.

Thus, I took this vague photo and put the assembly back. It is quite solidly built and, better yet, the individual components are quite easily removed, should one desire.

This is a quarter-inch jack that was likely designed to be used on a mid-70s receiver.

Note the gracefully curved arms with the little plastic nubs at the end.

When you plug a 1/4″ jack into said device, it not only connects the signal lines to the jack but it also actively disconnects the signals from other pins on the jack!

Simple and elegant design. Beyond elegant, it is just terribly pleasant to look at. I don’t believe I could ever install such a thing behind a panel.

I should snap another picture with a jack inserted, to see the change.

This is the real treasure that I claimed, though.

It is a 32 bit hexadecimal entry switch assembly. Beyond that, it is obviously completely modular. Take those screws out along the top and bottom and the whole thing could be reconfigured.

It has an extremely solid feel. You know when you have changed a switch’s value by the solid thunk it makes as it lands in a new position.

This is one seriously well made bit of equipment.

Well made right down to the fact that it is self documenting!

Lifting one of the edge connectors slightly off the boards at the back of the assembly reveals numeric labels.

The C is the common connection. The 1,2,4,8 are — obviously — individual bits that are turned on/off depending on the value of the rotary switch.

Now, seems a little odd that each switch would have two wires for one bit value. Not so fast– the numbers on the right have little lines over them to indicate that the value on the right will be the inverse of the values on the left.

Awesome.

At left is a simple EMSL AtmegaXX8 Target Board (same board I have written about before) 3 bit up/down counter circuit.

Push the left button? Counts down. Push the right button? Counts up.

Simple.

Sort of.

The switches are fully debounced using an extremely elegant algorithm that I ran across while trying to figure out how to efficiently debounce switches with an AVR controller.

Specifically, the software uses a vertical stack count to efficiently debounce up to 8 switches in very few instructions and only 3 bytes of memory.

Read on for schematic and a description of the software…

The software for this circuit can be found in my SVN repository. I added a third LED, but didn’t change the name of the source file. Oh well.

The circuit is terribly simple; two switches connected to ground and three LEDs each connected through a 1K resistor to VCC.

That is it; 8 discrete components.

Aside: I have never used EAGLE, a schematic and board layout package, before. It is awesomely powerful but woefully sucky at the same time. The user experience is just abysmal. Not terribly surprising as it is X11. There is both a commercial and a freeware version available.

But, at least, there is a downloadable binary. The alternative standard appears to be gEDA, for which there are no prebuilt binaries available. There is a Fink package available, but it takes a good 5 hours to build or so on a MacBook Pro.

But I digress.

Diving into the software that goes with this particular schematic, I’m going to discuss it in order of initialization, main loop, and event handling.

The initialization — the prelude of main() — looks like this:

int main(void) {
    DDRB = 0xFF; // Make all PB* -- PORT B -- pins output.
    PORTB = 0xFF; // turn all PB* -- PORT B -- pins off.

This turns all 8 bits of PORTB, pins PB0 through PB7, into output pins. Only PB0, PB1, and PB2 are used, but there is no harm in setting them all.

It also sets all pins to be outputting a logic 1; to be pulled high. Since the LEDs are connected to VCC through resistors, this effectively turns all of the LEDs off. A bit misleading, but — as a comment on a previous article indicates — the Atmel chips can handle more current through an output pin when acting as ground (sink) then when acting as VCC (source).

    bit_clear_8(DDRC, BIT(PC0) | BIT(PC1)); // PC0, PC1 is an input
    bit_set_8(PORTC, BIT(PC0) | BIT(PC1)); // Turn on pull-up resistor on PC0, PC1

This configures the pins PC0 and PC1 to be input pins. It also turns on the internal pull-up resistor on said pins. Without that second line of code, you would need to add pull-up resistors externally to the chip.

If you forget that line of code (I forget to turn on the pull-up for PC1 when I added a second switch) and don’t have an external pull-up resistor, it is very likely that the input pin will quite happily float between on and off quite rapidly as you wave your hand over the circuit. Makes for a good random number generator, but isn’t very useful for any kind of a push-a-button,make-something-happen circuit.

    bit_set_8(TCCR0B, BIT(CS01));
    bit_set_8(TIMSK0, BIT(TOIE0));

This block of code configures one of the chip’s timer’s into a mode where it counts from 0 (default) to 255 and, upon rolling over to 0, sends an overflow interrupt signal.

Setting bit TOIE0 of TIMSK0 turns on the overflow interrupt whenever Counter0 overflows. Counter0 simply counts up 1 unit per clock cycle, unless configured otherwise.

Setting bit CS01 of TCCR0B configures the timer to only increment once per every 8 clock cycles.

Since the clock is running at 1mhz, every 8 clock cycles times 256 counts between interrupts yields one interrupt every 2 milliseconds or so (unless my math is whack).

I use this once-every-2-milliseconds signal to sample the inputs and debounce using the vertical stack counter.

    sei(); // turn on interrupts

Finally, the sei() call simply enables interrupts. That is, it effectively causes the configured set of interrupts (and other stuff) to become active and start doing their thing.

This instruction is equivalent to setting the I bit of the AVR status register (SREG).

The “main loop” is rather straightforward.

volatile unsigned char ledState = 0;
....
int main(void) {
	// ... initialization code (see above) ....
    while (1) {
        PORTB = ~ledState;
    }
}

It simply updates the output pins on PORTB to be the currently desired LED state.

Or, since the LEDs turn ON when their corresponding pin is OFF, it simply writes the inverse of the current state of the LEDs to PORTB. This allows the internal program logic to be that bit much more straightforward.

Obviously, the real program functionality is squirreled away in the logic that maintains the ledState.

Now that everything is configured to rely upon an overflow interrupt to do the actual work of tracking user input and translating that to state changes, exactly how is that done?

ISR(TIMER0_OVF_vect) {

First, declare a handler for the TIMER0 overflow signal.

    unsigned char sample = PINC;
    unsigned char changes = debounceB(sample);

Then, read the current state of the PINC inputs. In this case, I’m reading all 8 bits even though only 2 pins are configured as inputs. The other 6 will be effectively ignored.

The debounceB function contains the vertical stack counter based debouncing logic. We’ll get to that next.

changes will contain the bits of PINC that have remained stable over the last 4 samples. Thus, the bits that are set in changes are the bits that have either been set or cleared for all 4 of the last passes through this function; they are debounced.

    if (bit_read_8(changes, BIT(PC0)) &&
        (!bit_read_8(sample, BIT(PC0)))) {
        ledState ++;
        ledState = ledState % 8;
    }
    if (bit_read_8(changes, BIT(PC1)) &&
        (!bit_read_8(sample, BIT(PC1)))) {
        ledState --;
        ledState = ledState % 8;
    }

These two bits of logic simply test to see if either the switch on pin PC0 or PC1 are pushed (and debounced).

Since the pins are configured to use pull-up resistors and the switches are connected to GND, pushing the switch yields a logical zero on the corresponding pin.

The test in changes determines if the bit is stable and the test in sample determines the state of the switch; on or off.

}

And that is it.

Almost. The real work is done in the routine that does the debouncing itself.

A vertical stack counter works by effectively “stacking” the bits in multiple bytes. In this case, there are two bytes. One byte contains all of the least-significant-bits and the other byte contains all of the most-significant-bits.

End result? 2 bytes represent 8 2 bit counters.

In this case, I’m only using 2 of the 2 bit counters. This leaves me considerable room to expand and the bitwise math is quite efficient.

static unsigned char debounceB0,debounceB1,debouncedBState;

The debouncing routine requires three bytes of persistent state; the vertical counters live in debounceB0 and debounceB1. The previous state is held in debouncedBState.

unsigned debounceB(unsigned char sample)
{
    unsigned char delta, changes;

    // Set delta to changes from last sample
    delta = sample ^ debouncedBState;

This sets delta to be the difference between the previous state (debouncedBState) and the latest sample. Any bits that have changed will be set in delta.

    // Increment counters
    debounceB1 = debounceB1 ^ debounceB0;
    debounceB0  = ~debounceB0;

This tricksy bit of bitwise math simply increments all of the vertical counters. If they overflow, they wrap back to 0.

    // reset any unchanged bits
    debounceB0 &= delta;
    debounceB1 &= delta;

Any counters associated with bits that didn’t change between the last sample and this sample are reset.

    // update state & calculate returned change set
    changes = ~(~delta | debounceB0 | debounceB1);
    debouncedBState ^= changes;
    return changes;
}

This sets changes to be the set of bits for which no change was detected and for which the counter has rolled back around to zero. If either the bit has changed in this pass (thus causing the counter to reset to 0) or the counter has yet to overflow, the state will still be considered to be volatile and, thus, the corresponding bit in changes will be zero.

It is a terribly elegant little routine. I found allusions to it in a couple of different AVR forums and finally found a description of the vertical counter portion of the algorithm here. From there, it was a matter of figuring out how to use changing bits in the sample to appropriately reset the counters.

Here is another explanation and a bit of pseudo code. I found it helpful in vetting my implementation.

When writing AVR micro-controller code, you typically end up with something like this:

int main(void) {
	... initialization code ...
	while(1) {
		... main loop that never exists here ...
	}
}

The main loop spins forever and is generally the bit of code that updates various output ports based on program state. It might likely also read inputs, too. And it might contain bits of code that delays execution for a while. And it is very likely rife with conditionals that’ll cause any given pass through the loop to very in execution time.

Not a very good place to do time sensitive stuff like, say, debouncing a button press or responding to other user events.

Really, it is far more effective to separate input processing entirely from the execution of the main loop. Input processing can update a global once the input has been fully validated and the main event loop can then process the event and reset the global.

Fortunately, the AVR has an exceedingly flexible interrupt system that can allow a chunk of code to effectively be executed “out of band” from the main loop.

Specifically, you can configure the chip to process an interrupt when an input pin changes state or based on a timer. Timers can be configured to count up over time and then send an overflow interrupt when the counter overflows either an 8 bit or 16 bit value. Furthermore, the timer can be prescaled such that it increments only every 8, 64, 256, or 1024 clock cycles, effectively causing the interrupt to be fired every 8x or 16x the prescaled values number of clock cycles.

And that is just the internal mode. The timer can also be incremented based on a clock signal provided on one of a couple of pins on the chip.

There are a boatload of other options and configurations available.

So, starting with the same circuit as described in the previous post (two LEDs), the following code uses a timer with maximum prescaler (so you can see the state change!) to cause the LEDs to act as a 2 bit counter.

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>

#define bit_set_8(var, mask)   ((var) |= (uint8_t)(mask))
#define bit_clear_8(var, mask)   ((var) &= (uint8_t)~(mask))
#define bit_toggle_8(var, mask)   ((var) ^= (uint8_t)(mask))
#define bit_read_8(var, mask)   ((var) & (uint8_t)(mask))

#define BIT(x)   (1 << (x))

volatile unsigned char ledState = 0;

// timer 0 overflow interrupt handler
ISR(TIMER0_OVF_vect) {
    // cycle LED state
    ledState ++;
    ledState = ledState % 4;
}

int main(void) {
    DDRB = 0xFF; // Make all PB* -- PORT B -- pins output.
    PORTB = 0xFF; // turn all PB* -- PORT B -- pins off.

	// increment timer every 1024 clock cycles
    bit_set_8(TCCR0B, BIT(CS02) | BIT(CS00));
    bit_set_8(TIMSK0, BIT(TOIE0)); // turn on overflow interrupt for timer 0

    sei(); // turn on interrupts

    while (1) {
        PORTB = ledState;
    }
}

Note that the timer updates the ledState global completely independently of the while(){} loop in main(). That is, main() simply renders the user interface, as it were, while the interrupt updates the state.

And, thus, we have the foundation for dealing with a button press, debounce and all, in isolation from rendering the UI (which will eventually be a flipper coil — a rather time sensitive operation that will require the main loop to be quite consistent in execution speed).

Trivial:

#include <avr/io.h>
#include <util/delay.h>

int main(void) {
    DDRB = 255U; // Make all PB* -- PORT B -- pins output
    PORTB = 0x0; // turn all PB* -- PORT B -- pins off.

    while (1) {
        PORTB = 0x1; // B0 on, B1 off
        _delay_ms(200);
        PORTB |= 0x2; // B0 and B1 on
        _delay_ms(100);
        PORTB = 0x2; // B0 off, B1 on
        _delay_ms(200);
        PORTB = 0X0; // All off
        _delay_ms(2500); // 2.5 seconds off
    }
}

Each on/off port is represented by a single bit. So, each of the pins in PORTA, PORTB, PORTC, or PORTD — assuming they are in straight digital input/output mode and whatever AVR chip you are targeting has enough pins to have 4 port sets — will be controlled by a single bit in one of four bytes.

Clearly, some macros to toggle bits are in order. Now, it turns out that macros to toggle bits are a big source of contention amongst the AVR development community. They hide too much magic, or so they say, and, if you are going to be programming embedded systems, you ought to be comfortable with C level bit twiddling, damnit.

Seriously — I read about 25 messages on the subject of bit twiddling as a part of the AVR API. The arrogance and close-mindedness was pretty silly.

Whatever.

Now that the bit twiddling is going to be hidden by macros, it is time to also modify the circuit to connect the LEDs through to VCC. Thus, the circuit will be more inline with basically every tutorial and document found on the net.

I also moved to using 1K ohm resistors — less current draw on the chip and just as bright (meaning that I was driving them with way too much current before).

The code now looks like this:

#define LED_ON(port, nr) port &= ~(1 << (nr))
#define LED_OFF(port, nr) port |= (1 << (nr))

int main(void) {
    DDRB = 255U; // Make all PB* -- PORT B -- pins output
    PORTB = 0xFF; // turn all PB* -- PORT B -- pins off.

    while (1) {
        LED_ON(PORTB, PB0);
        _delay_ms(200);
        LED_ON(PORTB, PB1);
        _delay_ms(100);
        LED_OFF(PORTB, PB0);
        _delay_ms(200);
        LED_OFF(PORTB, PB1);
        _delay_ms(2500); // 2.5 seconds off
    }
}

The LED_ON/LED_OFF macros take care of inverting the logic.

For additional bit manipulation operations, here are some useful macros culled from the discussion about a possible bit manipulation API that may or may not be added to the avr-gcc distribution someday:

#define bit_set_8(var, mask)   ((var) |= (uint8_t)(mask))
#define bit_clear_8(var, mask)   ((var) &= (uint8_t)~(mask))
#define bit_toggle_8(var, mask)   ((var) ^= (uint8_t)(mask))
#define bit_read_8(var, mask)   ((var) & (uint8_t)(mask))

#define bit_set_16(var, mask)   ((var) |= (uint16_t)(mask))
#define bit_clear_16(var, mask)   ((var) &= (uint16_t)~(mask))
#define bit_toggle_16(var, mask)   ((var) ^= (uint16_t)(mask))
#define bit_read_16(var, mask)   ((var) & (uint16_t)(mask))

/* equivalent to the poorly named _BV */
#define BIT(x)   (1 << (x))

The above enables expressions like:

bit_set(PORTD, BIT(0) | BIT(2) | BIT(4) | BIT(7));
bit_clear(PORTG, BIT(1) | BIT(6));
bit_toggle(PORTE, BIT(5) | BIT(3));
bit_read(PORTF, BIT(7));

http://svn.red-bean.com/bbum/trunk/avr/ATmegaXX8/

The EMSL Target Board is built around the ATmega 168 micro-controller (same controller as the Arduino — which, frankly, I couldn’t care less about other than as a source of knowledge…).

It is an extremely easy to use and surprisingly powerful micro-controller. If it weren’t so convenient, I wouldn’t be writing this.

Seriously. If you have any interest in screwing around with micro-controllers, there is little excuse not to dive in now. It is cheap, easy, and powerful.

Beyond the EMSL Target Board, you’ll also need a Lady Ada USBTinyISP programmer that has been appropriately patched (when assembled).

First, grab and install AVR Mac Pack from the fine folks at Objective Development (same source of LaunchBar and Little Snitch — both awesome products in their own right).

AVR Mac Pack has everything needed to talk to the AVR, a compiler that can target the AVR, and support for Xcode based development.

Once installed, the next step is to verify that the programmer can talk to the board using avrdude (all commands assume that $PATH has been updated to include the AVR Mac Pack stuff — be forewarned that the installation of AVR Mac Pack will edit some files in /etc/ to change the shell. It doesn’t work if you are using tcsh):

avrdude -p m168 -c usbtiny -P usb

avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

Uh oh! That ain’t good! Oh, that happened because I hadn’t flipped on the “power the target board” switch on my programmer. With the stock USBTinyISP, it’ll be a jumper. Replace it with a switch. You’ll be happier.

Anyway, once on:

avrdude -p m168 -c usbtiny -P usb

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9406

avrdude: safemode: Fuses OK

Woot!

You could use AVR Mac Pack’s avr-project command to create an Xcode project, but it produces an Xcode project that can’t install the built executable from within Xcode. I find it easier to start with the Peggy Makefile. Xcode’s Organizer can be trivially configured such that cmd-b will cause the makefile to build and install the desired chunk of code.

Firs,t you’ll need to edit the opening bits of the maekfile to successfully target the m168 part (this assumes that your source file

PRG            = buttflip
OBJ            = buttflip.o
PROGRAMMER     = usbtiny
PORT		   = usb
MCU_TARGET     = atmega168
AVRDUDE_TARGET = m168
OPTIMIZE       = -Os
DEFS           =
LIBS           =

Now, the makefile claims no need to edit below that particular header. It lies. There are these evil things called “fuses” in AVR micr-controllers that you have to deal with exceedingly carefully. Seriously. Wrong value can lead to a nice bit of inert plastic encased silicon.

Actually, you really want to change the makefile preamble to also include a CPU speed indicator (which is set via the ungodly confusing fuse values mentioned below):

AVRDUDE_TARGET = m168
OPTIMIZE       = -Os
DEFS           =
LIBS           =

HZ          = 1000000

And, slightly below that, change the definition of CFLAGS to this:

override CFLAGS = -g -DF_CPU=$(HZ) -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) $(DEFS)

You’ll see why in a second.

Ben pointed me to the AVR Fuse Calculator. God send. For now, I’m sticking with the default fuse values because I’m too lazy to go read the spec sheet closely enough to figure out what the more optimal settings might be:

install:  $(PRG).hex
	avrdude -p $(AVRDUDE_TARGET) -c $(PROGRAMMER) -P $(PORT) -v  \
	 -U lfuse:w:0x62:m \
	 -U hfuse:w:0xDF:m \
	 -U efuse:w:0x01:m \
     -U flash:w:$(PRG).hex

I totally don’t understand the fuse values. The default fuse calculator came up with a different value for efuse. avrdude complained. I set it to 0×01 because that was the value avrdude indicated was expected. It works. I have no clue why.

OK… great… now… need some kind of Hello, World! for a micro-controller. Sounds like it is time to Blink an LED or something.

Of course, you’ll need an LED. I used a random red LED because they are the cheapest and most commonly available. Thus, if I melted the LED, no real pain incurred.

You’ll also need a resistor to drop the voltage a bit for the LED. I used a 120 ohm resistor as that was handy — anything in the 120 to 220 ohm range should do fine.

LEDs have polarity. That is, they only work one way. The lead coming out of the flattened side of the LED is the negative lead (or, if you haven’t clipped them, the longer lead is the positive lead).

To make this code make the most sense, I wired up the LED such that it turns on when the output pin is turned on and turns off when off. That is, the positive lead of the LED — the round side — is connected to the PB0 pin of the ATmega168 chip. The negative is connected to one lead of the resistor. The other lead of the resistor is then connected to ground (GND) on the target board.

Aside: Usually, the LED will be hooked from VCC [positive] to the chip through the resistor. I’m not fully sure why, but it makes the code backwards– setting the bit turns off the LED, and vice-versa. Confusing. For this, I hooked it up the intuitive way.

The code is rather straightforward:

#include <avr/io.h>
#include <util/delay.h>

int main(void) {
    DDRB = 255U; // Make all PB* pins output

    while (1) {
        PORTB = 0x1; // high
        _delay_ms(250);  // 1/4 second on
        PORTB = 0X0; // low
        _delay_ms(2500); // 2.5 seconds off
    }
}

That is it!

Setting DDRB simply configures all PB# pins to be outputs. Overkill for only one pin, assuredly.

Setting PORTB to 0×1 simply turns on pin PB0 — takes pin PB0 high [5v]. If the LED were hooked to PB1, that would be 0×2. PB3? 0×4. PB4? 0×8. Etc… It is just basic bitwise I/O.

The calls to _delay_ms() entirely rely upon the setting of HZ in the makefile (which sets F_CPU). The ATmega168 part has an internal oscillator running at 8 MHZ, but that is subdivided to yield a 1 MHZ CPU speed.

End result?

The LED should blink; short tim on, longer time off.

Next up?

Two LEDs & some useful tools for manipulating bits. And the circuit will be refactored into a more standard form (LEDs connected to VCC).

The latest source code for this project is available in my personal subversion repository here: http://svn.red-bean.com/bbum/trunk/avr/ATmegaXX8/one-led-blinker/.

Ben picked up a ton of SIP machine pin sockets from Halted recently.

I grabbed about 200 from him and populated my EMSL Atmega target board with enough to provide for both on-board prototyping and to easily break out to a bread, board when needed.

Each point accepts a 24 gauge (or so) wire quite nicely. Makes for easy prototyping while not obscuring the documentation silkscreen on the board.

Next up?

I have all the parts needed to replace an entire flipper circuit in any modern Williams/Bally pinball machine.

Thus, I should have enough parts to drive a solenoid or flash-lamp from the AVR micro-controller.

First, though, I’ll flash some LEDs in response to button presses, though. All one voltage and relatively little chance of blowing up chips, bulbs, or shocking myself.

Once that works, I’ll wire up higher voltage / current drivers. I figure I ought to be able to both replace the flipper drivers with a much more maintainable system while also adding some automatic diagnostics that will light some LEDs inside the pinball when the flippers need to be rebuilt or maintained.

The folks at Evil Mad Scientist Laboratories whipped up an elegant little kit that includes an ATmega168 AVR Micro-controller, 4 or 5 discrete components, and a circuit board.

The Atmel AVR micro-controllers are awesome. They cross three particular barriers to entry that I arbitrarily chose prior to screwing around with micro-controllers.

Specifically:

• Price: $10 per useful part The Atmel series ranges from less than $1/part to a bit north of $10/part for the über-deluxe controllers. The ATmega168 in this kit can be had for less than $5/each and includes 23 I/O lines (6 of which can be used for ADC), 16K of program memory, and can run up at speeds up to 20MHZ.
• USB based Programmer less than $50 LadyAda sells a simple USB programmer (based on the Atmel chips — it implements a USB stack in software!) for $22. It works great, once you fix this particular bug (which involves replacing two resistors with wires; not hard).
• Easy & Powerful Programmability (on a Mac) Code for the Atmel series of chips is written in C and compiled quite easily via gcc. The ObDev folks have made an easy to install package available. It just works. Better, the chips support in system programming (without sacrificing pins for I/O!) and, thus, “build and run” in Xcode re-loads the code on the target chip without having to either power down the board or remove the chip from the circuit. Edit-compile-run is very very fast.

  The code, itself, is pretty straightforward. The header files provide all the #defines needed to deal with all the random I/O based hardware functionality quite straightforward. The chips, themselves, are exceptionally flexible, with the ability to reconfigure what pins do what in software.

  The hardest part is remembering which pin maps to what random #define’d symbol.

  

  The Atmel chips are, in fact, the same chips (almost the same exact chip — the proto boards use a slightly less expensive part in that it doesn’t have quite as many I/O ports) used in the Peggy Board (also from EMSL). I picked up the ladyada programmer and grabbed the source from EMSL.

  I had simple animation up and running within a couple of hours, most of that time being consumed by dealing with the now fixed USBTiny programmer bug. Not much longer after that and I had a pretty neat line based animation.

  Jamie over at Noise Land Arcade else has grabbed the code and made a neat animated pacman sign (video here).

Which brings me to this kit: This credit card sized board is designed quite specifically for prototyping ATmega168 (and several others) based projects. Beyond including a bit of room for adding a couple of 8-pin DIPs (or other random components), the silk screen fully documents the various mnemonics associated with each pin.

First project?

I’m going to build modern style flipper replacement for ’80s and early ’90s Williams/Bally pinball machines. The old school flippers require more maintenance and tend to fail gracelessly, taking out other discrete components upon failure.

This board is total overkill. I really only need an 8 pin Atmel controller per flipper; maybe one chip for both flippers, if I optimize.

But at $9/each for the board, controller and discrete components (including shipping and CA tax) in lots of 10, I might just stick with building it out on the EMSL prototype board.

As with many EMSL projects, everything is open source. The board is single sided and easy to etch, but silk screening on the various documentation bits would be difficult.

Evil Mad Scientists Laboratory has made the foundation of this build available as The Peggy for $80.

In typical EMSL fashion, that link includes tons and tons of information, including full details, board design, source, and loads of implementation notes.

So, apparently, it is being called Aqua Teen Day. Good enough.

Better yet, though, is that the fine folks of boston — the level headed public that makes the city such a great place — are celebrating the first annual “Aqua Teen Day” by decorating the city with LED art.

On January 31st, 2007, the authorities in Boston completely lost their minds. It wasn’t the first time, but this particular date was heavily reported and even the most head-in-the-sand die-hard “OMGWTFBINLADENFTChildren!!!one!!!” fear mongers found it ridiculous.

I am, of course, referring to the Aqua Teen Hunger Force “Hoax Device” bomb scare.

I could go on a political rant about fear based leadership and the general stupidity of the security theater played out in our cities and airports.

But that is boring.

I’d rather remind people of the jackassery that has happened and, once again, laugh at it. Then vote appropriately.

To that end, I purchased memorial kits from the fine folks at Evil Mad Scientist Laboratories and put them together over the last few days.

The results are just stunning. And effective. I brought the boards into work on Monday and, on the way home, stopped for a beer with boards in hand. Several folks asked about them and, upon explaining the history of the boards, they became just a touch more enlightened as to the stupidity of certain leadership and just a slight bit more inclined to learn more and vote accordingly.

Mission accomplished. With laughter included.

(The kits were a special edition from EMSL — you’ll have to contact them for availability. The LED “peg board” is generic; you can lay out the LEDs anyway you want to make any kind of similar display, including a “charlieplexed” mode that allows simple animations. I believe EMSL will be offering the generic form of the kit sometime soon.)

I spent a chunk of the evenings this weekend soldering together the aforementioned kits from Evil Mad Scientist Laboratories.

As I said before, truly awesome kits.

While assembling the kits, I whipped out the camera and took a few random photos.

The kits are done, but I’m holding on the final photos until tomorrow.

So, for now, click on through for a bit of macro electronic assembly pr0n.

The kits included a huge pile of 10 mm LEDs. Big frosty LEDs in several different colors.

That are completely impossible to tell which color is which without powering ‘em up.

Not a problem — the LEDs are nicely separated by color.

One thing that has changed since I built kits over 2 decades ago (Sheesh!!) is the prevalence of digital over analog.

One aspect of digital is that it tends to result in fairly repetitive circuits. And repetitive means lots of the same kinds of components.

I really appreciate the big bag of zero ohm resistors, too!

The boards are designed such that the LEDs sit completely flush to the board.

Took me a moment to realize that components with fat bottoms area easy to keep flush by simply bending both leads the same direction.

Once I made that realization, I could populate the boards with all LEDs of one color and then solder ‘em all in one pass, doing one lead of each LED at a time to minimize heat.

In any case, I had a lot of fun building these kits. And I have some awesome photos of the final products.

More soon…