A few weeks back we ran a piece about the convergence of making and baking in an attempt to create a cake festooned with working LEDs. The moral was that not every creative idea ends in victory, but we applauded the spirit it takes to post one’s goofs for the whole internet to see and to learn from.

[Craig]’s LED matrix proved unreliable…and the underlying cake didn’t fare much better, resembling that charred lump in the toaster oven in Time Bandits. The cakes-with-lights meme might have died right there if not for a fluke of association…

At the time the story ran, some of us were working on an unrelated LED project which involved experimenting with light diffusers, trying to spread distinct points of LED light to a more soothing glow. Drafting vellum and frosted acrylic both worked well, but small pieces of upholstery foam had proven especially effective.

Between seeing the cake project and handling squares of foam, an idea was jokingly tossed out: backlight a cake from below, using angel food cake as a light diffuser much like the foam we’d been experimenting with. The density, optical properties (and taste) do seem remarkably similar!

(On the left: polyurethane upholstery foam, the sort used in sofa cushions. On the right: angel food cake. Or…wait…is it the other way around?)

In the creative afterglow of Maker Faire (or more likely it was just exhaustion), this idea somehow made the jump from tongue-in-cheek to demo-or-die. The concept would look something like this:

A custom pedestal would secure the LEDs in place while providing a more prominent perch for the cake. A layer of glass or clear acrylic separates the two, so the LEDs would remain clean for future projects and the cake would not be sullied with any sort of flux or lead or other electronic residue. RoHS compliant cake!

Two questions then remained:

• What sort of display would we make? Static lighting would be boring, we knew this had to be animated. As a first crack at this sort of thing, we settled on a single seven-segment display, counting down.
• What type of LEDs to use? Instead of wiring up a pile of discrete LEDs, for the sake of a quick prototype we instead opted for serial addressible LEDs. Even then, there are decisions to be made:

(Left: BlinkM "smart LED." Right: MaceTech ShiftBrite. Top: RGB “pixels” available in various types from Adafruit, Bliptronics and Cool Neon.)

The choice of what type to use was based more on availability than on engineering: our Adafruit RGB pixels were tied up in another project, and we didn’t have enough BlinkMs or ShiftBrites on hand to build our prototype and didn’t want to wait around for shipping. We’d just bought a string of Cool Neon’s new “Total Control Lighting” LEDs at Maker Faire and were eager to try them in something, so they won by default. Looking back, these proved less than ideal for this particular project due to the diffuse bulbs, but we give them kudos for being among the easiest to program. Over the years we’ve messed with many different addressable LEDs, and have found that there is no One LED to Rule Them All — every one of them has unique and desirable attributes for different tasks.

We then fashioned an LED-holding template in Adobe Illustrator, sized to fit a single page:

This was printed and glued to a sheet of mat board, then the holes for the LEDs were laboriously cut out with a hobby knife. A laser cutter or even just a drill press would have made this much easier. For scale reference, each of the segments is about 1.5 inches wide, and with this just being a first prototype we didn’t bother with fancy beveled corners.

After cutting LED holes, the sidewalls and some supports were cut from foam core board and assembled using a hot glue gun. These added about two inches of height to the pedestal, to accommodate the bullet-shaped LED housings and the wires underneath. Then we punched each LED into place:

And there’s photographic proof of our first goof. Aside from the whole absurd idea, that is. These LED strings have connectors on both ends for daisy-chaining, with a distinct “in” and “out” end to each string. In our enthusiasm to attach a microcontroller, not thinking this through, we cut the “in” end and soldered our own breadboard wires. Electronically speaking this works just fine, but a better idea would be cutting the “out” connector, making that into our chip-to-LEDs adapter. Then this string would still work fine at the end of any chain, as well as with Cool Neon’s own driver circuits (which use the plug), and we’d have an adapter dongle for future applications with these strings. Lesson learned.

The string has 25 LEDs. Our display has seven segments, with three LEDs each. The last four LEDs were just wadded up under the pedestal and aren’t used here, but could have been made into ground effects lighting or something suitably corny.

After physical installation of the LEDs, we wrote and tested the code, which runs on an Arduino, natch. We’ll delve into the source later.

This pic shows the order in which the LEDs were installed and are addressed by the code. Also, the small boxes around each segment (more mat board and hot glue) restrict the diffuse outward glow from the lights and support the top acrylic for the cake:

We added contact paper to the bottom side of the acrylic, to further control stray light. This was probably overkill, but did help in positioning the cake segments later, as a sort of template. We’re not certain if acrylic is food-safe, so it’s possible that our eventual offspring may be born with tails or something. A small price to pay for SCIENCE!

Thus began the baking. And hilarity ensued…

(Devil’s food and angel food. In the same cake. You know this can’t end well.)

It was already determined that the segments would be angel food cake. The non-segment parts of the cake needed to be opaque…not just to contain the light, but as a vehicle for frosting, because a cake without frosting is no cake at all! We opted for chocolate, but most anything will do…red velvet, carrot cake, you name it. Not fruitcake though, it has an intense gravitational field from which not even light can escape.

The chocolate cake proceeded without incident. After baking and cooling, we trimmed down the risen center portion of the cake to give it a more uniform cross-section…this also provided essential sustenance to carry us through the next phase.

You’ll notice there are no photographs of the angel food cake being made. Oh, sure, [Craig] may be man enough to show his failures, but not us. We usually take umbrage to those television ads that depict the “man of the house” as an imbecile when confronted with domestic tasks, as if all males are HULK SMASH! brutes who can’t so much as feed or dress themselves. We’ve seen some awesome cooking hacks around here and know it’s simply not true. Then we tried baking an angel food cake…

Angel food cake (the name being an obvious conspiracy of marketing to lure us in) is a strange and alien thing, no doubt a product of NASA research that also brought us aerogels and space shuttle thermal tiles. The box contains what looks like diatomaceous earth, to which water is added. No eggs or oil or anything resembling, y’know, food. This is frothed in the mixer and poured in a pan, baked (during which it swells to over 6,000 times its original volume) and then, removed from the oven and allowed to cool (very important that it’s on its side, for whatever alien agenda reason) it proceeds to mock you for all eternity as an impenetrable sticky mass that defies all attempts at cutting or removal, like a loaf-pan version of the Blob from X-Men. We could actually hear the garbage disposal chewing as it worked on this. For five minutes.

After that experience, we’re officially declaring a one week moratorium on manly pride. If you see a guy washing his colors and whites together, or microwaving Hot Pockets and calling it “dinner,” he is totally fair game for mockery. You have our permission.

So, another trip to the grocery store, returning with a pre-made angel food loaf cake (day old, for extra durability)…which, we’ll note, would have been cheaper than buying the mix in the first place…and we can proceed…

Both cakes were carved into suitably-sized segments and arranged on the acrylic base/template. To help keep the angel food segments spotless and clean of frosting, we pre-frosted the top of the chocolate cake before carving it up, and would touch up the seams after the fact. Had to get creative with the last few rectangles of chocolate cake, but frosting hides all sins. The angel food cake should have been trimmed a bit thinner to match the height of the chocolate cake, but we were getting hungry after the whole emasculating fiasco and just wanted to see if this thing would work or not.

A quick test with the cake atop the LED pedestal showed a problem: the white cake picked up all diffuse light in the room, entirely washing out the backlighting. But we’d seen this problem before…of all things, a SparkFun capacitance meter kit, which suffers the same issue where its red LED segments are washed out by the white diffusers in a bright room. The fix there is to add a piece of smoked acrylic atop the display. So we applied a similar principle here, but wanting to keep everything edible we used fruit roll-ups instead of acrylic. Reflecting on it now, fruit jelly would have tasted better and would slice well with the rest of the cake.

The fruity fix didn’t address the problem completely, and it was still necessary to operate the cake in near-darkness for best effect, which may or may not be a problem since programmers normally thrive in low-light conditions. The photo above shows how the number “6” looks under normal room lighting…washed out and nearly indistinguishable from the full “8”. Using brighter, more directional LEDs (but still using the fruit topping) would probably help with this…BlinkMs or ShiftBrites or their higher-lumen equivalents. Not too much though, or you’ll go all Easy Bake Oven on it.

Here’s a video of the completed countdown cake in action:

So the idea does…kind of…work. Would we try it again? Probably not. It was a fun idea to mess around with – a hack – and any day you get to eat cake and call it your job is a good day indeed, but the effect ultimately wasn’t worth the effort. Like the original article, we hope this one can be filed under “heroic failure.” It’s progress though, and might give someone food for thought. Maybe third time’s the charm.

A closing thought is that this could be combined with a Wave Shield or the chipKIT digital audio technique from a prior article to play the Happy Birthday song, creating a cake that’s both fattening and incredibly annoying!

Finally, here’s the Arduino sketch that drives the LED display:

// 7-segment LED Cake Sketch for Arduino.
// Uses Cool Neon's "Total Control Lighting"
// addressible LEDs.  Data issued on Arduino
// digital pin 11, clock on pin 13.

#include <SPI.h>

// 7-segment bitmask for each digit.
// Bit-to-segment mapping is as follows:
//     1
//   2   0
//     6
//   3   5
//     4
// This corresponds to the order in which LEDs
// are mounted in the physical template.
byte segmask[] = {
  B0111111, B0100001, B1011011, // 0 - 2
  B1110011, B1100101, B1110110, // 3 - 5
  B1111110, B0100011, B1111111, // 6 - 8
  B1110111, B1111010,           // 9, ersatz 10
  B0100001, B0110000, B0011000, // Spinny thing
  B0001100, B0000110, B0000011
};

#define N_PIXELS  25
#define GAMMA    2.4
byte gamma[256];

void sendPixel(byte r, byte g, byte b)
{
  SPI.transfer(~((r >> 6)              |
                ((g >> 4) & B00001100) |
                ((b >> 2) & B00110000)));
  SPI.transfer(b);
  SPI.transfer(g);
  SPI.transfer(r);
}

void sendLatch()
{
  for(byte i = 0; i < 4; i++) SPI.transfer(0);
}

void setup()
{
  int i;

  // Initialize SPI communication:
  SPI.begin();
  // The following 3 lines can normally be
  // left out - Arduino's default SPI config
  // appears to be MSB, Mode 0 and runs at
  // 4 MHz (instead of 8 as is done here,
  // but still plenty quick).  But for
  // posterity, here's the full config:
  SPI.setBitOrder(MSBFIRST);
  SPI.setDataMode(SPI_MODE0);
  SPI.setClockDivider(SPI_CLOCK_DIV2); // 8 MHz

  sendLatch(); // Wake up!

  // Set all pixels to initial "off" state:
  for(i = 0; i < N_PIXELS; i++) sendPixel(0, 0, 0);
  sendLatch();

  // Calculate gamma correction table.
  // Provides a perceptually more linear
  // fade between brightness levels.
  for(i = 0; i < 256; i++) {
    gamma[i] = (byte)(255.0 *
      pow((float)i / 255.0, GAMMA));
  }
}

byte digit = 10,
     prev  = 10;

void loop() {
  byte i, bit, x;
  int  fade;

  // Fade from previous to current digit:
  for(fade = 0;fade < 256; fade++ ) {

    // For each of 7 segments:
    for(bit = 0x01; bit < 0x80; bit <<= 1) {

      x = 0; // Assume segment is off by default
      if(segmask[digit] & bit) { // On, or fading on
        x = (segmask[prev] & bit) ? 255 : gamma[fade];
      } else if(segmask[prev] & bit) { // Fading off
        x = gamma[255 - fade];
      }

      // 3 LED "pixels" per segment
      for(i = 0; i < 3; i++) sendPixel(x, x, x);
    }

    // Last 4 pixels are unused and stay off
    for(i = 0; i < 4; i++) sendPixel(0, 0, 0);

    sendLatch(); // Update LEDs
    delay(1);    // ~1000 updates/sec
  }

  // Hold last image for remainder of ~1 sec.
  delay(1000 - 256);

  if(digit > 0) { // Still counting down
    prev = digit;
    digit--;
  } else { // Done counting, reset...
    // But show spinny animation first
    for(int n = 0; n < 5; n++) {
      for(digit = 11; digit <= 16; digit++) {
        for(bit = 0x01; bit < 0x80; bit <<= 1) {
          x = (segmask[digit] & bit) ? 255 : 0;
          for(i = 0; i < 3; i++) sendPixel(x, x, x);
        }
        for(i = 0; i < 4; i++) sendPixel(0, 0, 0);
        sendLatch();
        delay(100);
      }
    }
    digit = prev = 10;
  }
}

A couple of notes on using the Total Control Lighting LEDs:

• Red wire = +5V. White = data (Arduino pin 11). Green = clock (Arduino pin 13). Blue = ground.
• The datasheet suggests issuing 32 consecutive zero bits to mark the start of a full frame of data, but we’d sometimes see a stray first or last pixel on the initial image. A more reliable approach has been to issue the 32 zeros at the program’s start, then after each full frame. Rock steady.

In our hands-on review of the Digilent chipKIT Uno32, we posed the question of what the lasting appeal might be for a 32-bit Arduino work-alike. We felt it needed some novel applications exploiting its special features…not just the same old Arduino sketches with MOAR BITS. After the fractal demo, we’ve hit upon something unique and fun…

So just what are the chipKIT’s unique features over a stock Arduino? Until the expected Ethernet shield ships this summer, a few ideas are on hold. Let’s see then…there’s no shortage of MIPS, of course…but there’s also heaps of RAM and flash storage. And with the latter, sampled audio came to mind. There are Arduino shields for just this sort of thing — the Adafruit Wave Shield turns up in many projects, using an SD card for sound storage — but if one’s needs are modest, the chipKIT’s PIC32 is perfectly capable of storing brief audio samples in its own flash program space, no cards, adapters or added expense required. We estimate the Max32 can hold nearly a full minute of voice-quality audio.

Playing with the idea, we found we could do one better. Actually, several better. A limitation of SD card-based players like the Wave Shield is that they can only play one sound at a time. Dealing with the FAT filesystem and buffering audio data off the card takes nearly everything the Arduino’s little ATmega chip can muster…polyphonic sound requires kludges. But our flash-resident audio samples on the chipKIT are trivial to access. With the fast 32-bit CPU, many samples can be processed simultaneously…and then, with gobs of RAM, time-based effects such as reverb can be added. And before we knew it, there was a toy synthesizer sitting on the table:

Having previously dabbled with the PIC32 using Microchip’s tools, we were surprised by the simplicity with which this went together. A few early rough spots aside, the chipKIT and MPIDE environment show major promise for being every bit as simple as Arduino. In fact, the whole build was completed faster than the documentation phase. And then a second surprise, even to us: everything in the parts list, aside from the chipKIT board itself, is common stuff that could be found at RadioShack. No funky special ICs, components or mail-order shields. Most of the “magic” is in software, thanks to this fast microcontroller.

Here’s a demonstration of the finished mini-synth in action:

Please excuse the demonstrator’s tragic lack of rhythm and coordination. This is why professional musicians get paid millions while amateurs lead sad lives as technology bloggers. Be thankful that we spared you the blooper reel.

Input is via five piezoelectric transducers (RadioShack #273-0073, $2.19 each) attached to analog inputs A0 through A4. We could have just used pushbuttons, sure, but we wanted something that could sense the pressure of each hit, and these were cheaper than force-sensitive resistors. Piezo sensors have a specific polarity, and the positive side (red wires) should connect to the analog inputs, and black to ground. There’s also a 2000 Ohm resistor added across each element:

Input for the reverb effect is straightforward. Two 10K potentiometers on analog inputs A6 and A7 (these are on the second row of analog inputs on the chipKIT Uno32, not present on Arduino). One controls the amplitude, the other controls the delay:

Finally, sound output uses high-speed PWM output on digital pin 3, passed through a simple low-pass filter to a headphone jack:

On our breadboard we’re using a handy little headphone breakout board from SparkFun, but one could just solder the appropriate wire leads onto a bare jack from “The Shack” (ugh). You may want to optionally add a 1 Meg pot just before the headphone jack. The circuit worked fine as-is with headphones or an amplified iPod speaker, but totally saturated our camera’s microphone input when fed directly.

This demo uses 16 KHz sound samples. As per Nyquist theory, the low-pass filter is then designed for an 8 KHz (-ish) cutoff frequency. For purely voice applications, half those rates should be sufficient (saving flash space and allowing longer samples), and the two resistor values should then be doubled.

And that’s it for parts. Can you believe it? On to the code…

To begin, we need something that can convert sound files into a format the C compiler can use. An ugly little UNIX command-line utility converts WAV files from a very specific format (8-bit mono, uncompressed) into C header files that can be #included by the MPIDE project. Arduino normally would use the PROGMEM directive to put these tables into the code flash space, but that’s not required here. Surprisingly, the much-loved Audacity program wouldn’t export 8-bit WAVs, but we found it possible to batch convert sounds using iTunes.

const signed char sample_drum[] = {
        0x02,0x03,0x01,0x00,0x00,0x00,0x00,0x01,
        0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x00,
        ...HUNDREDS OF LINES OF STUFF...
        0xff,0xff,0xff,0xfd,0xfd,0xff,0x00,0x00,
        0x00,0x00,0x00,0x00,0x02,0x00 };

We’ll spare you the horror of looking at that code or doing the conversion. You can download the complete set of project files here, and then adapt it to your own needs. The remainder of this article deals only with the MPIDE code.

But first, one fix is required: in our prior article, we encountered an issue with the chipKIT’s analog read speed, and a fix was discussed in the comments. This involves scrounging among the MPIDE source files for “wiring_analog.c” and changing a few lines. The old code resembles:

delayMicroseconds(99);
while ( ! mAD1GetIntFlag() ) { }
analogValue = ReadADC10(0);
mAD1ClearIntFlag();

This should be changed to:

delayMicroseconds(2);
mAD1ClearIntFlag();
while ( ! mAD1GetIntFlag() ) { }
analogValue = ReadADC10(0);

We’re told this change will be incorporated into later releases of the toolkit and this won’t be necessary for much longer. If you’re just ripping out the digital audio code from this project and ignoring this drum pad stuff, you can skip the change altogether.

And then there’s our sketch code:

// Mini sampling synthesizer for chipKIT Uno32.

#include "sounds.h"       // N_SAMPLES and data are here
#define PWM_PIN         3 // OC1 PWM output - don't change
#define SAMPLE_RATE 16000 // All samples fixed at 16 KHz
#define MAX_SOUNDS     10 // Polyphonic limit
#define MAX_ECHO     4000 // 1/4 sec fits in Uno32 RAM

short
  echo_data[MAX_ECHO]; // Circular buffer for echo

int
  echo_delay = 0, // Duration of echo effect
  echo_vol   = 0, // Echo effect volume (0-1023)
  echo_pos   = 0; // Current position in echo buffer
volatile int      // May change during interrupt:
  n_sounds   = 0; // Number of sounds currently playing

struct soundStruct {
  int sample; // Index of corresponding audio sample
  int pos;    // Current position within sample
  int vol;    // Playback volume, 0-1023
} sound[MAX_SOUNDS];

#define N_PADS N_SAMPLES // One pad for each sample

struct padStruct {
  short max;       // Max pressure during press (0-1023)
  short count;     // Timer for filtering out noise
  byte  triggered; // If set, currently reading a press
  short add;       // If >0, begin sound at next interrupt
} pad[N_PADS];

void setup()
{
  memset(pad, 0, sizeof(pad));    // Clear drum pad data
  memset(echo_data, 0, sizeof(echo_data)); // Clear echo
  pinMode(PWM_PIN, OUTPUT);     // Enable PWM output pin

  // Open Timer2, 1:1 w/256 tick interval (for 8-bit PWM)
  OpenTimer2(T2_ON | T2_PS_1_1,256);
  OpenOC1(OC_ON | OC_TIMER2_SRC | OC_PWM_FAULT_PIN_DISABLE,
    0,0);

  // Open Timer1 with interrupt for sample mixer (16 KHz)
  ConfigIntTimer1(T1_INT_ON | T1_INT_PRIOR_3);
  OpenTimer1(T1_ON | T1_PS_1_1, F_CPU / SAMPLE_RATE);

  delay(1);  // Slight delay avoids false trigger at start.
}

// Piezo transducers as input pads are fussy.
// To avoid false positives, a bit of hysteresis is used:
#define PRESS_MIN     20 // Must read at least this force
#define PRESS_COUNT    3 // for this many samples, then...
#define RELEASE_MAX    8 // Must read less than this force
#define RELEASE_COUNT 15 // for this many samples.
// Still imperfect; there are occasional double-triggerings
// and false triggers on adjacent pads.  Could be addressed
// with better mounting and isolation of pads and/or with
// improved input filtering in code or in hardware.

// The loop() function just reads pad and dial inputs; all
// audio work is done in the subsequent interrupt function.

void loop()
{
  int i, a;

  for(i = 0; i < N_PADS; i++) {  // Sample each pad...
    a = analogRead(i);

    if(pad[i].triggered) {    // Previously pressed?
      if(a <= RELEASE_MAX) {  // Yes, released now?
        if(++pad[i].count >= RELEASE_COUNT) {  // Really?
          // Sounds aren't added to play list here, just
          // flagged; they're added to the mix in the
          // interrupt.  This avoids a race condition
          // where this code may be trying to add a sound
          // while the interrupt is removing one.
          pad[i].add       = pad[i].max;
          pad[i].triggered = 0;
          pad[i].count     = 0;
        }
      } else {  // Still pressed...watch for new max
        if(a > pad[i].max) pad[i].max = a;
        pad[i].count = 0;  // Reset release counter
      }
    } else if(a >= PRESS_MIN) {  // Untriggered; new press?
      if(++pad[i].count >= PRESS_COUNT) {  // Really?
        pad[i].triggered = 1; // Flag to watch for release
        pad[i].count     = 0;
        pad[i].max       = a;
      }
    } else {  // Untriggered and below press threshold
      pad[i].count = 0;  // Clear press counter
    }
  }

  // Echo parameters come from potentiometers on A6 and A7
  echo_vol   = analogRead(6);
  echo_delay = map(analogRead(7), 0, 1023, 0, MAX_ECHO);
}

// This is the mixing/sample-playing interrupt,
// invoked at 16 KHz to match the audio sample rate.
// With guidance from Mark Sproul's PIC32 port of
// Brett Hagman's Tone library for Arduino.
extern "C"
{

void __ISR(_TIMER_1_VECTOR,ipl3) playSample(void)
{
  int i = 0, sum = 0;

  mT1ClearIntFlag();  // Clear interrupt flag

  while(i < n_sounds) {  // For each sound playing...
    // Waveform is cumulative, NOT averaged
    sum += (int)sample[sound[i].sample].data[sound[i].pos] *
      sound[i].vol;
    sound[i].pos++;  // Advance counter.  If end hit...
    if(sound[i].pos >= sample[sound[i].sample].size) {
      n_sounds--;  // Decrement number of sounds playing:
      // Move sound at end of list to the slot currently
      // occupied by the vacating sound (unless the same)
      if(i < n_sounds) {
        memcpy(&sound[i], &sound[n_sounds],
          sizeof(soundStruct));
        continue;  // Sound moved; dont advance index
      }
    }
    i++;
  }
  sum /= 1024;

  // Add in echo effect (if enabled) from circular buffer.
  // This takes place before audio level clipping so that
  // any clipping distortion won't be repeated in echo.
  if((echo_delay > 0) && (echo_vol > 0)) {
    sum += echo_data[echo_pos] * (echo_vol + 1) / 1024;
    echo_data[echo_pos] = sum;
    if(++echo_pos >= echo_delay) echo_pos = 0;
  }

  // Clip audio to 8-bit range.  This may cause distortion
  // when multiple sounds or echo exceed the 8-bit range.
  // Invoking the "quick & dirty" alibi again.
  if(sum < -128)     sum = -128;
  else if(sum > 127) sum =  127;

  SetDCOC1PWM(sum + 128);  // Set PWM output value 0-255

  // Check for any new sounds flagged by loop().
  // Done last because sounds finished above will
  // free up polyphonic slots.
  for(i = 0; i < N_PADS; i++) {
    if(pad[i].add) {
      if(n_sounds < MAX_SOUNDS) {
        sound[n_sounds].sample = i;
        sound[n_sounds].pos    = 0;
        sound[n_sounds].vol    = pad[i].add + 1;
        n_sounds++;
      }
      pad[i].add = 0;  // Clear flag even if not added
    }
  }
}

} // end extern "C"

Explanation:

The setup() function initializes two timers:

• Timer 2 and Output Compare 1 (hardware features of the PIC32 chip) are used for pulse width modulation (PWM). In conjunction with the filter previously described, this positions the speaker for each audio sample (Google for “PWM DAC” for explanations and examples). The PWM input clock is set to the chip’s full speed of 80 MHz, with an interval of 256 “ticks” (for 8-bit resolution), yielding a PWM waveform at 312,500 Hz. For this sort of DAC filtering it’s recommended that the PWM frequency be at least ten times the sample rate, so this is more than adequate for our needs. This is also why the code bypasses the native Arduino analogWrite() function for PWM, which operates on a much slower clock. Lastly, using Output Compare 1 dictates that we must use digital pin 3 for the audio output; this is one of the five native hardware PWM lines on this chip.
• Timer 1 operates at our audio sample frequency (16 KHz) and has an interrupt function attached. This function mixes audio samples and changes the PWM duty cycle of Timer2/OC1. The rates on both of these timers are set up once and never need to change, just the one duty cycle is varied.

This section of the code (and one line in the interrupt function) is admittedly not very Arduino-like, directly accessing hardware features in a non-portable manner. A more formal implementation would abstract these details into a library to which the novice programmer could just pass data. But for the sake of a simple, single-file demo, there it is, warts and all. In many ways, this is just a starting point to work from.

The loop() function reads the state of the piezo sensors and marks sounds to be played (received by the interrupt, later). There’s some crude debouncing of the piezo inputs…this really could use some more sophisticated filtering (which the PIC32 could easily handle), but it was skipped for brevity. The code generally detects varying pressure, but there’s still a fair bit of false triggering going on. In this function the reverb controls are also read: just two analogRead() calls, with the second one then mapped to the full length of the reverb buffer.

The interrupt handler is where all the fun stuff happens, and it’s surprisingly simple.

The extern “C” declaration makes the C++ compiler happy with the interrupt function declaration.

The program is designed for up to ten concurrent sounds, the details of which are held in the “sound” structure array (there’s more than enough CPU performance for greater polyphony, but it’s mostly just a matter that the input pads aren’t terribly practical for this). When a pad hit is sensed, a new item is added to this array (up to the maximum). Structure elements indicate which audio sample is used for this sound, the current playback position within the sample, and the volume level.

Audio samples are stored as signed values (rather than unsigned) because this makes them easier to mix (just add together) and easier to adjust gains (just multiply). Every opportunity is taken to use fixed-point math. From the prior fractal demo, we saw what a massive performance difference this can make — sometimes orders of magnitude. Most of our analog readings (returned as 10 bit integers from 0 to 1023) correspond to a gain (relative volume) value of 0.0 to 1.0 (or 0% to 100%). To perform this scaling in fixed-point units, add 1 to the reading, perform the multiplication (one instruction on the PIC32), then divide by 1024 (a simple shift operation, also one instruction). There’s no loss in accuracy vs. converting to floating-point; the source and destination values are going to be quantized anyway.

// Floating-point, slow:
// scale = float 0.0 to 1.0
out = (int)((float)in * scale);

// Fixed-point, crazy fast:
// scale = integer 0 to 1023
out = in * (scale + 1) / 1024;

Along these lines, note that where the audio samples are summed, this division is skipped until the end. This saves some cycles and the result works out the same. Algebraically speaking, (A/X)+(B/X)=(A+B)/X, and so forth. The interim 32-bit sum isn’t likely to overflow.

Fixed-point math happens again when applying reverb. The echo volume, in the integer variable echo_vol (10 bit again, from one of the analog knobs) is in the range 0 to 1023, corresponding to 0% (no reverb) to 100% (echo is as loud as the original sound). Reverb (in echo_data[] array) is a circular buffer — as sounds are played, the contents here (scaled by echo_vol) are first added to the output, then the result is placed back in the same position in the array and the position counter is incremented by one. When the end of the array is reached (or a shorter limit indicated by echo_delay) we “wrap around” back to the beginning.

The final resulting audio value is clipped to an 8-bit range. This may introduce clipping distortion when many loud sounds are used simultaneously. For brevity again, bells and whistles have been omitted, but courageous programmers could opt to add “soft clipping” here to limit such distortion. There’s ample CPU muscle.

The final 8-bit signed value is then transposed into the unsigned range and fed into the OC1 duty cycle for PWM output.

Lastly, the interrupt checks for any sounds that the loop() function flagged as being “hit,” and adds these to the concurrent play list. This flag-and-add behavior, rather than adding items directly in loop(), avoids a potentially nasty race condition whereby loop() could be in the midst of adding a sound just as the interrupt is removing others, throwing off the counter.

And that’s all there is to it. This demo only uses about one fourth of the storage on the Uno32, which itself has one fourth the capacity of the Max32…and we’ve yet to exploit any sort of compression. There could be some fun applications here, maybe adding better Super Mario sounds to toilets or voice prompts to other chipKIT projects (“Your door is ajar”). What other ideas could you see happening here?

Following Maker Faire, we’ve had a few days to poke around with Digilent’s 32-bit Arduino-compatible chipKIT boards and compiler. We have some initial performance figures to report, along with impressions of the hardware and software.

Disclaimer: Digilent has provided Hack a Day with Uno32 and Max32 boards for evaluation.

chipKIT isn’t the first attempt to extend the Arduino form factor to a 32-bit microcontroller core…other products such as Maple, Netduino or the FEZ Domino have been around for well over a year…but the chipKIT boards are notable for the effort Digilent has put into creating a seamless transition. The aim is to create a single unified tool both for traditional 8-bit Arduino boards and Digilent’s 32-bit work-alikes, where the same IDE, the same code, and a good number of the same shields can all work despite the different underlying architectures. In fact, they’re hoping the Arduino project accepts their integration method as an official means of adding new hardware to the Arduino IDE — not just for their own product, but for anyone else to use as well.

As noted in our prior report, we were impressed that they do appear to deliver on this promise. The transition between “classic” Arduinos and the 32-bit boards is indeed quite slick. But we’re finding at this early stage that there are still some rough bits to be worked out. So, for the time being, we’re keeping both the Arduino IDE and Mpide (Digilent’s multi-platform derivative) installed on the development system; the latter has not yet obviated the need for the former. But we see how the concept is supposed to work, and we like it.

For the most part, Mpide works as intended as a dual-platform IDE. Just select the appropriate device from the Tools->Board menu, recompile, and the code is now ready for the corresponding chip. But a couple things have bit us in the rear:

• The AVR compiler in Mpide either isn’t fully optimizing, or the floating-point libraries were built sans optimization or something. This threw off our benchmark numbers initially — the results were atrocious! In order to keep the numbers realistic, we’re using the standard Arduino IDE for the corresponding benchmarks. To be fair, they did warn us about this performance issue in person at Maker Faire, but until it’s fixed they could be more forthcoming about it with some documentation or on the web site…otherwise it could look like they’re trying to skew benchmarks more in their favor.
• The String() constructor is borked when handling integers. The following line compiles fine for AVR chips, but throws a tizzy fit with the PIC32 compiler:
  

  String foo = String(42);

Given that the IDE was wrapped up literally hours before going live online and at Maker Faire, it’s understandable that there are some loose ends. Just be prepared as an early adopter that this won’t be as pain-free a transition as they’re aiming for. The great thing with open source is that we can get in there, spot such problems, and offer suggestions and submit fixes…the situation will no doubt improve with time.

Some Benchmarks

We wanted to create a fractal demo similar to what they were displaying at Maker Faire. We didn’t have the spiffy SparkFun Color LCD Shield on hand, so instead we had to settle for a serial LCD, 4D Systems’ uLCD-144. This does affect the numbers somewhat, as we’ll see.

In MIPS alone, the chipKIT should beat the Arduino by a factor of five. Then there’s the native 32-bit-ness of it: when dealing with larger numbers, the AVR processor at Arduino’s core has to shift and fiddle bits between consecutive 8-bit values in order to achieve 32-bit results. So the PIC32 should show a considerable performance benefit beyond MIPS alone. In practice, this doesn’t always pan out.

The uLCD-144 is a 128 by 128 pixel 16-bit color LCD with a serial UART interface running at 115,200 bits per second. The graphics commands aren’t terribly efficient, and it’s necessary to send a five byte packet for every pixel drawn. This includes coordinate data; there’s no block write function in serial mode. On the plus side, it’s easy to talk to using the Arduino or chipKIT’s native serial UART.

Here’s the code for the Mandelbrot sketch, using floating-point math:

/* Simple Mandelbrot set renderer for Arduino vs. chipKIT benchmarking
   w/floating-point math, via www.hackaday.com.  This example uses the
   4D Systems uLCD-144(SGC) serial display module, wired as follows:

      uLCD Pin:   RES  GND  RX  TX  VIN
   Arduino Pin:     2  GND   1   0   5V    */

const int
  pixelWidth  = 128,  // LCD dimensions
  pixelHeight = 128,
  iterations  = 255;  // Fractal iteration limit or 'dwell'
const float
  centerReal  = -0.6, // Image center point in complex plane
  centerImag  =  0.0,
  rangeReal   =  3.0, // Image coverage in complex plane
  rangeImag   =  3.0,
  startReal   = centerReal - rangeReal * 0.5,
  startImag   = centerImag + rangeImag * 0.5,
  incReal     = rangeReal / (float)pixelWidth,
  incImag     = rangeImag / (float)pixelHeight;

void setup()
{
  pinMode(13,OUTPUT);   // Arduino status LED
  pinMode(2,OUTPUT);    // LCD reset pin
  digitalWrite(13,LOW); // LED off
  Serial.begin(115200);

  digitalWrite(2,LOW);  // Reset LCD
  delay(10);
  digitalWrite(2,HIGH);
  delay(2000);          // Allow time for reset to complete

  Serial.write(0x55);   // Issue auto-baud command
  while(Serial.read() != 0x06); // Wait for ACK
}

void loop()
{
  unsigned char cmd[20];   // Serial packet for LCD commands
  int           x,y,n;
  float         a,b,a2,b2,posReal,posImag;
  long          startTime,elapsedTime;

  Serial.write(0x45);      // Clear screen
  delay(100);              // Brief pause, else 1st few pixels are lost

  cmd[0] = 0x50;           // 'Pixel' command is issued repeatedly

  digitalWrite(13,HIGH);   // LED on while rendering
  startTime = millis();

  posImag = startImag;
  for(y = 0; y < pixelHeight; y++) {
    cmd[2] = y;            // Y coordinate of pixel
    posReal = startReal;
    for(x = 0; x < pixelWidth; x++) {
      a = posReal;
      b = posImag;
      for(n = iterations; n > 0 ; n--) {
        a2 = a * a;
        b2 = b * b;
        if((a2 + b2) >= 4.0) break;
        b  = posImag + a * b * 2.0;
        a  = posReal + a2 - b2;
      }
      cmd[1] = x;          // X coordinate of pixel
      cmd[3] = n * 29;     // Pixel color MSB
      cmd[4] = n * 67;     // Pixel color LSB
      Serial.write(cmd,5); // Issue LCD command
      posReal += incReal;
    }
    posImag -= incImag;
  }

  elapsedTime = millis() - startTime;
  digitalWrite(13,LOW);    // LED off when done

  // Set text to opaque mode
  cmd[0] = 0x4f;
  cmd[1] = 0x01;
  Serial.write(cmd,2);

  // Seems the chipKIT libs don't yet handle the String(long)
  // constructor, hence this kludge.  Working backward, convert
  // each digit of elapsed time to a char, with " ms" at end
  // and text command at head.  Length is variable, so issue
  // command from final determined head position.
  cmd[19] = 0;
  cmd[18] = 's';
  cmd[17] = 'm';
  cmd[16] = ' ';
  n = 15;
  do {
    cmd[n--] = '0' + elapsedTime % 10;
    elapsedTime /= 10;
  } while(elapsedTime);
  cmd[n--] = 0xff; // Color LSB
  cmd[n--] = 0xff; // Color MSB
  cmd[n--] = 0;    // Use 5x7 font
  cmd[n--] = 0;    // Row
  cmd[n--] = 0;    // Column
  cmd[n] = 0x73;   // ASCII text command
  Serial.write(&cmd[n],20-n);

  delay(5000); // Stall a few seconds, then repeat
}

And the timing results, in milliseconds, for the Arduino (top) and chipKIT (bottom):

Arduino: 54,329 ms.
chipKIT: 12,417 ms.

To reiterate (pardon the pun), due to some performance issues we used the traditional Arduino compiler, not the one included in Mpide. If you’re curious, the output from that compiler took about 8.5 minutes to complete the task! Oof.

So, about a 4.4x speedup. Not bad, but we were expecting a more dramatic difference. Part of this is due to the inherent bottleneck of the serial communication with the LCD…we’ll get back to that in a moment. Another limiting factor is that both chips are emulating floating-point math. If we can use 32-bit integer data types, thePIC32 should really shine. So, a fixed-point Mandelbrot generator followed:

/* Simple Mandelbrot set renderer for Arduino vs. chipKIT benchmarking
   w/fixed-point math, via www.hackaday.com.  This example uses the
   4D Systems uLCD-144(SGC) serial display module, wired as follows:

      uLCD Pin:   RES  GND  RX  TX  VIN
   Arduino Pin:     2  GND   1   0   5V    */

const int
  bits        = 12,   // Fractional resolution
  pixelWidth  = 128,  // LCD dimensions
  pixelHeight = 128,
  iterations  = 255;  // Fractal iteration limit or 'dwell'
const float
  centerReal  = -0.6, // Image center point in complex plane
  centerImag  =  0.0,
  rangeReal   =  3.0, // Image coverage in complex plane
  rangeImag   =  3.0;
const long
  startReal   = (long)((centerReal - rangeReal * 0.5)   * (float)(1 << bits)),
  startImag   = (long)((centerImag + rangeImag * 0.5)   * (float)(1 << bits)),
  incReal     = (long)((rangeReal / (float)pixelWidth)  * (float)(1 << bits)),
  incImag     = (long)((rangeImag / (float)pixelHeight) * (float)(1 << bits));

void setup()
{
  pinMode(13,OUTPUT);   // Arduino status LED
  pinMode(2,OUTPUT);    // LCD reset pin
  digitalWrite(13,LOW); // LED off
  Serial.begin(115200);

  digitalWrite(2,LOW);  // Reset LCD
  delay(10);
  digitalWrite(2,HIGH);
  delay(2000);          // Allow time for reset to complete

  Serial.write(0x55);   // Issue auto-baud command
  while(Serial.read() != 0x06); // Wait for ACK
}

void loop()
{
  unsigned char cmd[20];   // Serial packet for LCD commands
  int           x,y,n;
  long          a,b,a2,b2,posReal,posImag,startTime,elapsedTime;

  Serial.write(0x45);      // Clear screen
  delay(100);              // Brief pause, else 1st few pixels are lost

  cmd[0] = 0x50;           // 'Pixel' command is issued repeatedly

  digitalWrite(13,HIGH);   // LED on while rendering
  startTime = millis();

  posImag = startImag;
  for(y = 0; y < pixelHeight; y++) {
    cmd[2] = y;            // Y coordinate of pixel
    posReal = startReal;
    for(x = 0; x < pixelWidth; x++) {
      a = posReal;
      b = posImag;
      for(n = iterations; n > 0 ; n--) {
        a2 = (a * a) >> bits;
        b2 = (b * b) >> bits;
        if((a2 + b2) >= (4 << bits)) break;
        b  = posImag + ((a * b) >> (bits - 1));
        a  = posReal + a2 - b2;
      }
      cmd[1] = x;          // X coordinate of pixel
      cmd[3] = n * 29;     // Pixel color MSB
      cmd[4] = n * 67;     // Pixel color LSB
      Serial.write(cmd,5); // Issue LCD command
      posReal += incReal;
    }
    posImag -= incImag;
  }

  elapsedTime = millis() - startTime;
  digitalWrite(13,LOW);    // LED off when done

  // Set text to opaque mode
  cmd[0] = 0x4f;
  cmd[1] = 0x01;
  Serial.write(cmd,2);

  // Seems the chipKIT libs don't yet handle the String(long)
  // constructor, hence this kludge.  Working backward, convert
  // each digit of elapsed time to a char, with " ms" at end
  // and text command at head.  Length is variable, so issue
  // command from final determined head position.
  cmd[19] = 0;
  cmd[18] = 's';
  cmd[17] = 'm';
  cmd[16] = ' ';
  n = 15;
  do {
    cmd[n--] = '0' + elapsedTime % 10;
    elapsedTime /= 10;
  } while(elapsedTime);
  cmd[n--] = 0xff; // Color LSB
  cmd[n--] = 0xff; // Color MSB
  cmd[n--] = 0;    // Use 5x7 font
  cmd[n--] = 0;    // Row
  cmd[n--] = 0;    // Column
  cmd[n] = 0x73;   // ASCII text command
  Serial.write(&cmd[n],20-n);

  delay(5000); // Stall a few seconds, then repeat
}

And the numbers:

Arduino: 27,734 ms.
chipKIT:  7,209 ms.

Now only a 3.8x difference, despite the PIC32 speaking its native tongue. What gives?

Even at 115,200 bits/sec, the serial LCD is seriously holding us back, as the code is going to “block” as each character is output. Some back-of-envelope calculations suggest how much time is being lost there:

128 x 128 pixels, 5-byte command per pixel = 81,920 bytes.
Including start and stop bits for each byte = 819,200 bits total
819,200 bits / 115,200 bps = ~7.1 seconds.

So our MCU is sitting there for seven seconds with its thumb up its ASCII in order to update the display. Sure enough, if we comment out the Serial.write() command but leave all the calculations in place, the results are significantly more dramatic:

Floating-point:

Arduino: 49,685 ms.
chipKIT:  5,822 ms.
9.3x improvement.

Fixed-point:

Arduino: 22,326 ms.
chipKIT:    168 ms
133x improvement. Hot damn. Now we’re talking!

So we could actually render this at interactive frame rates, for the want of a sufficiently fast interface to the LCD. This sort of limitation is going to crop up every time we connect to a real-world device. Not everything is 100% internal code and math…there are finite limits to I/O throughput, and that more than anything can cap the speed of the total application. So we really can’t give a consistent “Everything will be X percent faster” estimate for this board.

The performance looks good for math, especially if an algorithm can work in integer or fixed-point formats. Another thought we had was analog-to-digital sampling, which has applications in robotics…say for a line-follower or balancing robot. More frequent samples should yield smoother operation, or multiple samples can be averaged to yield higher-precision results. The PIC32 should scream in that regard. And yet…

void setup()
{
  const int samples = 10000;
  int       i,n;
  long      startTime,elapsedTime;

  Serial.begin(115200);

  startTime = millis();
  for(i = 0; i < samples; i++) {
    n = analogRead(0);
  }
  elapsedTime = millis() - startTime;

  Serial.print(samples);
  Serial.print(" samples in ");
  Serial.print(elapsedTime);
  Serial.print(" ms = ");
  Serial.print(((float)samples * 1000.0) / (float)elapsedTime);
  Serial.println(" samples/sec");
}

void loop()
{
}

Arduino: 10000 samples in 1119 ms = 8936.55 samples/sec
chipKIT: 10000 samples in 1008 ms = 9920.63 samples/sec

Running full-tilt, the PIC32 is capable of up to 1 million ADC samples per second, compared to 125,000 on the Atmel chip. Certainly the library implementation is going to introduce some overhead, but what gives? Rooting through the library source code turns up this gem in wiring_analog.c:

 //*     A delay is needed for the the ADC start up time
 //*     this value started out at 1 millisecond, I dont know how long it needs to be
 //*     99 uSecs will give us the same approximate sampling rate as the AVR chip
 //      delay(1);
 delayMicroseconds(99);

This raises a couple of red flags. First, why should the sampling rate aim to match the AVR? For time-related functions like delay() and for Serial.begin() bitrates, of course we’d want similar numbers, those relate to temporal increments. But we don’t — or at least shouldn’t — measure time with ADC readings. And secondly, well, why not find out how long the ADC startup time really needs to be? A few minutes’ sifting through Microchip datasheets eventually turned up the correct answer: two microseconds. So, changing the line in wiring_analog.c to:

delayMicroseconds(2);

Yields dramatically different results:

chipKIT: 10000 samples in 101 ms = 99009.90 samples/sec

About a tenfold improvement, and the readings still look valid. This does break like-timing compatibility with the AVR-based Arduinos, but as we said, why? It’s understandable that some decisions may have been made in haste…it’s a monumental project, getting all this code ported to an entirely different chip, and the IDE is still fresh from the oven…but some of these little broken details do have us concerned about what other surprises may still lurk beneath.

Don’t get us wrong…we’re enthusiastic about the chipKIT boards. The technical challenge is met, and just needs some cleaning up. What remains for Digilent now is a marketing challenge: who is this really for? When we talk about things like megasamples and fixed-point algorithms, these aren’t exactly day-one topics familiar to the Arduino’s target audience of first-time programmers. And the more advanced user may have moved on already, leaving Arduino behind. So why keep this form factor? Why keep this IDE?

Obviously, part of the allure is the existing ecosystem of Arduino shields. There’s some pretty nifty stuff out there, networking and touch screens and stepper motor drivers, most of which will physically plug right in. Having an existing solution saves development time. Then there’s the ease and familiarity of the Arduino libraries. Even though they’re slow and clunky in places, it can be really handy sometimes just to squirt out some status information to a serial port without having to do all the UART setup manually.

The chipKIT boards are cleverly priced to approximate Arduino on a cost basis (even undercutting a bit). That’s a great start, with code and price parity, but where’s the extra value? What the Uno32 and Max32 may need are some killer apps. Ideas that the novice can implement, but that really take advantage of the PIC32 chip’s added performance and capabilities. Speed may be just one part of that. What can we do with the extra RAM and flash space that a normal Arduino just can’t handle, even with the fanciest of shields? Folks have done some mind-blowing stuff with the little 8-bit AVR. We’re looking forward to seeing if this is the tool that takes these hacks to the next level.

Google’s Maker Faire exhibit space is swarmed with robots…er, androids. Amidst some cool bipeds and Segway-balancers, our inner sci-fi nerd was most smitten with this hexapod design, which they’ve dubbed SKPR Bot. The “Skipper” is on hand to showcase the ease of various Google technologies: SketchUp, Android OS and the Android Open Accessory Development Kit. The whole project came together in less than six weeks.

18 servos are mounted to a framework designed in SketchUp and laser-cut by Ponoko. The low-level servo PWM control is handled by the Dev Kit (essentially a rebadged Arduino Mega, as we’ve seen), while an Android OS phone provides a slick GUI and handles all the inverse kinematics calculations required as the robot takes each step. The coolest bit is that it’s all up for grabs. At this moment you’ll have to scrounge around the ’net a bit to find the plans and code, but some time post-Faire they plan to bring everything together at the SKPR Bot site.

Psst…wanna buy a laser cutter, but not ready to sell your internal organs? Nortd Labs’ Lasersaur project aims to create an open source large-format laser cutter/engraver that undercuts (har har!) the cost of commercial models by an order of magnitude.

As the most direct interface between computer and programmer, keyboards can be a deeply personal, sometimes almost religious thing. Some find solace in their vintage IBM Model M, or luxurious leather keyboard, but maker [Carol Chen] took things into her own hands, quite literally. [Carol]’s Maker Faire exhibit has a half dozen specimens of interesting commercial tactile and ergonomic options…but [Chen]’s personal keyboard, where she commits to her work as a full-time coder, has been made to her own exacting specifications.

 

Not every cool hack needs to involve microcontrollers, LEDs or other bling. We were initially drawn to the Bloxes display simply because we love a good multipurpose construction set, whether it be Lego, 80/20 aluminum, or in this case, a system of interlocking cubes formed from six identical pieces of corrugated cardboard, cut and scored in such a manner as to form a surprisingly sturdy little building block. They can become simple furniture, groovy Logan’s Run-style room decor, or the all-important kids’ forts…then later dismantled and made into something else.

If you’ve been hungry for more power for your microcontroller projects, but reluctant to dump your investment in Arduino shields or the libraries and community knowledge that go with them all, Digilent has you covered. Their new chipKIT boards are built around the Microchip PIC32 MCU…a powerful 32-bit chip that until recently was left out of the cross-platform scene. A majority of code and quite a number of Arduino shields will work “out of the box” with the chipKIT, and the familiar development tools are available for all three major operating systems: Windows, Mac and Linux.

We first mentioned these a couple weeks ago, but the software was unavailable at the time. Seeing the development tools in action was quite unexpected…

What’s really fascinating with chipKIT is that the workflow is exactly Arduino-like. The serial bootloader works with avrdude, and you can program both “real” Arduinos and Digilent’s 32-bit work-alikes using the exact same IDE; there’s no need to run two different IDEs for two different boards, as has been the case with Leaf Labs’ 32-bit Maple. As a demonstration, they compiled and ran code for an Arduino Mega with SparkFun LCD shield…then popped the shield off and placed it on the Max32, selected the 32-bit board in the same IDE, and repeated the process. The exact code ran on the new board/shield combo, with stunning performance — all the standard Arduino libraries have been implemented natively for the PIC32; this is not emulation.

Because Digilent didn’t just adapt the Arduino IDE to their one specific board, but rather developed a system by which the IDE can be extended to new hardware, it’s their hope that their work (not an official Arduino project) might be rolled back into the mainline code, and that other developers might jump on the bandwagon to provide Arduino IDE support for their own boards, whether they be based on AVR, PIC32 or a completely different kind of microcontroller altogether. The groundwork has been laid.

The chipKIT comes in two versions: Uno32 and Max32, similar in form factor to the Arduino Uno and Mega 2560, respectively. These can be ordered directly from Digilent’s web site, and the IDE is freely downloadable as of today. We have evaluation hardware in-hand and expect to be providing a proper review in the near future.

It’s a madhouse already at the 2011 Bay Area Maker Faire. Though the show doesn’t officially start until tomorrow, Friday is “Education Day”, a special preview for local schools. As makers scramble to set up their displays, a thousand impressionable young minds seek the most cacophonous mixture of taiko drumming, ArcAttack’s musical Tesla coils, and the beeping and booping of the R2-D2 Builder’s Club.

Our initial view of the Spy Video TRAKR “App BUILDR” site had us believing this would be an internet-based code editor and compiler, similar to the mbed microcontroller development tools. Delving deeper into the available resources, we’re not entirely sure that’s an accurate assessment — TRAKR may well permit or even require offline development after all. Regardless of the final plan, in the interim we have sniffed out the early documentation, libraries and standalone C compiler and have beaten it into submission for your entertainment, in order to produce our first TRAKR hack!

TRAKR software development at the moment, to phrase it just as politely as we can, has a Wild West flavor to it. The finished tools and reference materials aren’t expected until October. Early documentation is rough — entire sections still missing — so it’s frequently necessary to rummage through their example code to learn how things operate. And the compiler is exceedingly rough right now…it requires a minor patch just to get started, and works only within Cygwin, a UNIX-like command shell for Windows systems. So tonight we’re gonna program like it’s 1999! To continue, we’ll have to assume you’re at least vaguely familiar with command-line development tools, as explaining the entire process from scratch is more than we can fit here.

It probably goes without saying, but for posterity: these are beta tools and the entire process will almost certainly change as the TRAKR HAKR site nears release, rendering these directions obsolete. Until then, for those wanting to get an early start, here’s how we began building our own TRAKR hacks…

Getting the compiler

The C compiler and documentation are presently located on the Apps Help page of the TRAKR web site. Just follow the directions there to download the App Primer (containing the compiler and demo source code), the TRAKR Codebook PDF (an introduction to TRAKR programming), and the Function Reference and code snippets for lighter-weight reference once you’re familiar with the concepts.

The Apps Help page states that the tools work with Linux, but this isn’t entirely true. The App Primer ZIP file contains only the Cygwin (Windows) toolchain, along with the TRAKR libraries and sample code. The C compiler is based on arm-elf-gcc 3.4.6 — Linux users might stand a chance with the pre-built 3.4.3 package from the GNU ARM web site. You’ll still need to download the App Primer for the libraries. With Mac OS X, things get ugly…we’ve yet to locate a viable package for Intel Macs. Building the 3.4.6 toolchain from source (or via MacPorts) has brought only frustration, and the TRAKR makefiles don’t play nice with later (but working) arm-elf-gcc editions. Joy. Eager to move ahead, and not wanting to invest a lot of time on beta tools that are certain to change, some of us are simply using the Windows package in VirtualBox for now.

Getting the compiler to actually work

After unpacking the App Primer ZIP file, copy the TRAKR.1 folder inside to a suitable working location within your Cygwin directory. The _MACOSX folder can be deleted — this is just an artifact of the files having passed through a Mac at one point; there are no OS X build tools here.

Just unpacking the Primer and trying to compile the examples, you’ll encounter a slew of “undefined reference” error messages and a failed build. There’s a problem with the TRAKR library — some test data that’s not properly archived — but it’s a straightforward fix. Go into the Internals directory and edit the Makefile using vi (or another editor of choice if you have one installed). Line 22 looks like this:

OBJECTS = $(S_OBJECTS) $(O_OBJECTS)

It should be changed to this:

OBJECTS = $(S_OBJECTS) $(O_OBJECTS) $(O_IMAGES)

Save the changes and exit the editor, then (still in the Internals directory) type:

make trakr.a

Now you can go back to any of the examples and successfully compile by typing “make”. For example:

cd ../EX06_Sound
make

This will create a “.bin” file that can be loaded onto the TRAKR. Attach a USB cable between your computer and the TRAKR vehicle (the power switch can be on or off, it doesn’t matter). In a moment, the TRAKR’s internal storage will show up as a small removable drive. Then just copy the .bin file to the APPs folder on this drive, e.g.:

cp EX\ Sound.bin E:APPs

Disconnect the USB cable, power up the TRAKR and remote, press the remote’s Home button and use either stick to navigate to the “EX Sound” menu item, then press the “Go” button. The app should prompt you to record 10 seconds of audio from the TRAKR’s microphone, then plays this back. Cool stuff!

Writing your own apps

Each TRAKR app is required to have three functions: Start(), Run() and End(). Your Start() function contains one-time initialization code, such as opening the motors to software control; End() is the complimentary function for when your program finishes, restoring control to normal TRAKR operation. Run() contains the meat of your application…this function is expected to return either “true” or “false” to indicate whether it should run again iteratively, or is ready to exit.

The header file svt.h contains constants and prototypes for the functions described in the Codebook and reference documents. This includes high-level functions for producing graphics and sound, turning the infrared LED on or off, reading the controls, driving the motors and accessing the SD card. This is all the Official Documented Stuff thatApp BUILDR will encourage us to use.

But there’s a second header, JAPI.h, revealing much of the underlying functionality on which the TRAKR library is built. And for the time being, this is the only way to access the really interesting stuff like digital I/O, video processing and USB host. This is most definitely not the Official Documented Stuff, and relying on it now means your code will probably require some changes to work with the Official Stuff later.

There’s something conspicuously absent from both libraries: higher-level digital I/O such as serial UART or precise PWM control. We’re not even certain yet whether any the accessible breakout lines correspond to these hardware functions. Maybe it’s something forthcoming, or maybe this will require the chip datasheet, with code talking to the registers directly. Worst case, such I/O will just have to be done with slower bit-banged methods. Which is exactly what we do with…

Our first hack

We really wanted to showcase both the software and hardware hackability of the TRAKR. There isn’t the space for an overly-technical writeup, but neither do we want to send you off with a trivial modification. Hopefully we’ve found a good balance here…mildly esoteric, but most readers with modest prior soldering and programming experience should be able to follow along and create something similar.

Our inspiration came from an earlier Hack a Day article about the txtBomber, a handheld dot-matrix graffiti printer:

The width of the TRAKR is about the same as a sheet of paper. With a row of solenoids and some paint markers, we could make a fantastic mess with this…or even simpler, skip the markers and head to the beach, having the TRAKR “comb” messages in the sand.

Problem is, we didn’t have a stack of solenoids on hand, and we wanted to get right into this rather than wait around for parts to arrive. Rooting among the detritus of our secret underground vault, we found a great substitute from a prior project: a row of 48 addressable LEDs driven by shift registers, the board on which they’re mounted perfectly matching the TRAKR’s 10 inch width! So our aim now was to achieve the same effect in light. The TRAKR moves too slowly for retinal persistence of vision to occur, but we could use long exposure photography to capture the results.

Anyone can buy a TRAKR off the shelf now, but the light bar was something custom-made for a POV project. The good news is that it’s a very common circuit, something we’ve linked to before, and a slightly scaled-back version can be built on a breadboard. Ours has a set of six 75HC595 shift registers with decoupling caps, each driving eight LEDs with associated current-limiting resistors. Very similar to what’s shown in that article, but cascaded out to six chips. You could also do something similar (and way more colorful) using ShiftBrite LEDs.

The LED board is held to the ’bot with masking tape. Spared no expense!

As pointed out in our teardown, the all-important JACK3, containing the GPIO lines, is smack dab in the middle of the TRAKR main board. The unpopulated header USB2, which we’ll use as a power tap, is closer to the outside edge.

In our haste to create a presentable demo, we just soldered wires directly to the TRAKR’s circuit board, but at some point intend to dismantle the thing again and solder on a proper header for inserting wires. For +5VDC and ground, the VDD5V and VGND pads of the idle USB connector are used. The shift registers require three data lines (as we’ll explain in a moment), and we opted to use the first GPIO lines on the board, labeled GPC0, GPC1 and GPC2.

The shift register interface, referred to as a 3-Wire serial connection or sometimes SPI (Serial Peripheral Interconnect), is a synchronous serial interface, meaning that each bit of data is accompanied by the synchronized tick of a clock bit on another line. A third line, called the latch, signals the end of the data transmission — in the case of an 8-bit shift register, this will output on its 8 parallel data lines the last 8 bits that were “clocked in” over the serial connection.

For our light bar hack, we’ll use GPC0 as the clock line, GPC1 as the data line, and GPC2 as the latch. Most microcontrollers feature some kind of native 3-Wire/SPI support, but as mentioned earlier, with the TRAKR library at present we’ll have to trigger all these bits through software control.

Next thing we need is an image to display on the LEDs, one row at a time. Naturally, we’re going to use the Hack a Day logo:

In the source code archive provided later, the image is present as a 1-bit Windows BMP file, simple to work with because the data is uncompressed. The image is turned sideways as it requires less code for the program to decode each horizontal row of the bitmap than it would for processing vertical columns. It’s 48 pixels wide, corresponding to the 48 pixels in the LED bar, and 60 pixels high, including some blank lines at either end so repeated logos don’t run one into the next.

Our example program is hardcoded for this one demo image, which is embedded in the executable. A more sophisticated program might allow the user to load an image from the SD card, and would properly parse the BMP header to query the actual image dimensions. Again, we’re just looking to keep the code simple and not stretching out to hundreds of lines.

// POV demo for Spy Video TRAKR w/shift register LED bar.

#include "svt.h"  // Official API
#include "JAPI.h" // Secret sauce

#define ROWS  60 // Image height in pixels
#define COLS  6  // Image width in bytes (pixels = 8x this)
#define PAD   (3 - ((COLS - 1) & 3))
extern unsigned char _binary_logo_bmp_start[]; // In logo.o

#define CLOCK (1 << 0)  // GPC0
#define DATA  (1 << 1)  // GPC1
#define LATCH (1 << 2)  // GPC2

void Start()
{
  JAPI_SetIoOutputMode(CLOCK | DATA | LATCH);
}

bool Run()
{
  unsigned char *ptr, byte;
  int r, c, b;

  // 62 byte offset to start of image data within BMP:
  // 14 byte BMP header, 40 byte DIB header, 8 byte palette
  ptr = &_binary_logo_bmp_start[62];

  for(r=0; r<ROWS; r++) {     // Each line in image
    for(c=0; c<COLS; c++) {   // Each byte in line
      byte = *ptr++;
      for(b=128; b; b>>=1) {  // Each bit in byte
        if(byte & b) JAPI_SetIoLow(DATA);
        else         JAPI_SetIoHigh(DATA);
        JAPI_SetIoHigh(CLOCK);
        JAPI_SetIoLow(CLOCK);
      }
    }
    JAPI_SetIoHigh(LATCH);
    JAPI_SetIoLow(LATCH);
    Sleep(20);
    ptr += PAD;  // BMP rows start on 4-byte boundary
  }

  return true;
}

void End()
{
}

The graphics-related #defines should be clear by now, we know this program is set up for this one specific image. The CLOCK, DATA and LATCH #defines correspond to the individual bits passed to GPIO-related functions, making subsequent code easier to read.

In the Start() function, the call to JAPI_SetIoOutputMode() initializes all three lines as outputs.

Because of the way the image is formatted, there’s minimal work now to be done in the Run() function. For each horizontal row of the image, six bytes of image data are output one bit at a time, 48 bits total: the DATA line is set either high or low to indicate the corresponding 1-bit pixel value, and then the CLOCK line is quickly toggled high and then low to “clock out” the data bit. At the end of each row, the LATCH line is similarly toggled to tell the shift registers to display the new data. A 20 millisecond delay holds the image for a moment so it’s not all scrunched together, given the TRAKR’s limited speed.

The next line advances the image pointer to the start of the next row, if required. In BMP files, rows are always a multiple of 4 bytes wide. Our bitmap is only 48 pixels (6 bytes) across, so this skips the two extra bytes at the end of each row. The final “return true;” line tells the TRAKR library to repeat our Run() function again indefinitely.

The End() function is empty for this program, but it still needs to be present to keep the linker happy.

A ZIP file containing the above source code, bitmap image and makefile can be downloaded here. Extract this archive within the Trakr.1 folder, alongside (not within) the Internals directory. “cd” to this directory and type “make”. If all goes as planned, this should produce the file POV.bin, which can be loaded on the TRAKR as described earlier.

Even in this early stage, warts and all, we’re quite excited by the prospects for this toy’s hackability. Wild Planet is to be applauded for their open-minded approach in encouraging software and hardware modifications. A lot of comparisons are already being made to the Roomba and Rovio, both of which have spawned enthusiast sites and even books. Time will tell if the Spy Video TRAKR catches on the same way.

So that’s our TRAKR hack…now let’s see yours! When you’ve got something cool to showcase, don’t forget to tip us off!

Last Friday we looked at Wild Planet’s Spy Video TRAKR programmable RC vehicle mostly from an end user perspective. Much of our weekend was spent dismantling and photographing the device’s internal works, and poring over code and documentation, in order to better gauge the TRAKR’s true hackability. Our prior review included some erroneous speculation…we can clarify a number of details now, and forge ahead with entirely new erroneous speculation!

Our plan with this teardown is to establish more concrete details of what’s hackable inside the device, what’s not, and to help nail down some of the unstated hardware specifications.

We incorrectly reported that no programming documentation or compiler is yet available. Turns out all this information was simply tucked away in a help section of the TRAKR web site, not on the “App BUILDR” page where we expected it. Derp! These resources are still in a rough state, yet proved to be a far more valuable source of information than the physical teardown. C code and PDFs aren’t very photogenic though, so we’ve got plenty of circuit board pr0n to start with!

Inside the Remote

The concealed rear USB port was mentioned last time, which we’ve been informed is to allow for field-upgradeable firmware. If you don’t mind being tethered to one spot, we discovered the remote can also be powered from a USB hub, or even from the TRAKR’s own USB host port.

In another nod to tinkerer-friendly design, both the remote and the TRAKR are held together with identical Phillips screws throughout, recessed but not hidden under stickers or rubber pads.

The LCD screen is one typically seen in cell phones, 15-bit color at 160×120 pixels.

The remote and TRAKR have outwardly-identical radio transceivers. They’re rather well-sealed and we’ve not dismantled them further yet, but recall hearing they’re based on a Nordic 2.4 GHz part. Wild Planet claims that with a forthcoming firmware change, they’ll be WiFi-capable. We remain hopeful but skeptical — it seems far more likely that the remote’s rear USB port will come into play, or in the interim perhaps one of the SparkFun Nordic options will prove a viable choice for PC control.

Inside the TRAKR

Removing the screws is straightforward, but fully removing the lid from the TRAKR requires several cables be detached first — and they’ve all been glued in place for reliability. We just cut through the glue with an X-acto knife and pried a bit, but maybe it can be more delicately dissolved or melted.

The right side of the main board (turned sideways here) focuses on connectivity and the CPU. The ribbon cable at left leads to the camera. The pair of two-pin headers lead to the microphone and front accessory bump switch. The purpose of the unpopulated SW1 isn’t known — it might be that early designs featured an additional rear or top switch, now vestigial. The larger headers lead to the radio module and the trim pots and recessed reset/debug switches on the bot’s undercarriage.

No need to get through that epoxy blob. Digging through configuration files for the compiler, the chip appears to be a Nuvoton W55VA91, featuring an ARM926EJ core running at 192 MHz, and hardware-assisted JPEG codec.

Little to see on the underside. Another inactive V0_TVOUT pad taunts us! This side is dominated mostly by the SD card socket, and…

The USB host port is on a small daughter board, and each of the motors has some local driver circuitry as well.

Each motor is driven through a reduction gearbox. They operate quietly with only a slight amount of slop. As with the radio, we’ve not further dismantled these yet.

Though not powered, the front wheels aren’t as boring as we first thought. This rack and spring mechanism keeps a constant tension on the rubber tread belts, allowing them to flex and maintain traction as the TRAKR drives over various terrain.

The partly-disassembled camera pivot mechanism. Two small rubber pads provide just enough friction to hold the camera in its set position, yet still allow it to pivot easily. If attempting to add servo control to the camera, removing those pads will likely help.

Extracting the camera PCB from its housing, we were greeted with a low-hanging hack opportunity: the board was designed to accommodate multiple LEDs, but in practice shipped with just one large one in place. Boosting the light output should be a very simple matter of adding the missing resistors and LEDs, though you’ll need to drill holes through the case or run wires to mount the LEDs externally.

We’re not 100% certain of the camera sensor yet. From PR materials at Maker Faire, we know it’s from OmniVision, but don’t know the exact model. Based on size and specifications, the OV7670 looks like a possibility, in which case it should be capable of full VGA resolution, not just the QVGA output we’ve seen.

The “accessory port” is just a passive attachment point to clip things on; it resembles a headphone jack, but isn’t. There is a pushbutton switch behind it, maybe an interactive cat-poking stick is planned.

The artist’s signature.

Reassembly was straightforward. Cable connectors are keyed for orientation, and for those that aren’t a unique size, the correct positions can be inferred from cable length. And there was no mysterious “extra screw” at the end — everything went together easily and worked on the first try.

Passengers

Arduino, natch. Small devices like this can be powered from the TRAKR’s USB host port, but without an FTDI driver on the host side this connection can’t be used for serial communication.

Half-size and quarter-size breadboards fit exceedingly well, almost snapping into place. But anything placed back here though is going to block access to the SD and USB ports.

More Hack Ideas

Having explored the hardware inside and out, we’re already ruminating on the possibilities…

The TRAKR has a big infrared LED on the front (with two more easily added). The firmware for TV-B-Gone is open source. Enough said.

With the transport deck removed, the rear wheels of the TRAKR protrude slightly behind the body. With the addition of a gyro sensor, will it be possible to get the TRAKR to stand upright and scoot around Segway-style? The remote’s joysticks are non-proportional, but software control of the motors allows for very fine speed adjustment. It’s been done with LEGO NXT, so we think the practicality of this idea will come down to the responsiveness of the TRAKR’s motors. (Yes, we know it’s just propped up against the back wall there. Shhh!)

At the Bay Area Maker Faire this past May, we had our first glimpse of Wild Planet’s Spy Video TRAKR, a $130 radio-controlled toy with some surprises under the hood.

On the surface, the Spy Video TRAKR — the latest addition to the popular Spy Gear toy line — is an R/C tank with a video camera and night vision, with the added ability to download new “apps” from the internet for extra functions. With a little detective work, one uncovers the TRAKR’s secret double life: it’s also an eminently hackable robotics platform! Prior Spy Gear toys have been popular hack targets, providing inexpensive, mass-produced sources of unusual items such as head-mounted displays. Rather than throw up barriers, Wild Planet has chosen to embrace this secondary market, with plans to release development tools and documentation making it possible to extend the device’s capabilities.

Read on for our image-heavy unboxing and initial impressions.

The packaging is outwardly consumer-oriented — this is, first and foremost, a kids toy after all — and the “USB Connected” and “Download & Build Custom Apps” labels are about as technical as it gets on the outside.

Batteries not included. You’ll need plenty. And did you ever expect to see Linux mentioned by name on anything at Toys R Us? Awesome!

Internal packaging is minimalist and largely recyclable. No twist ties, no staples, no plastic bubbles, no registration cards or catalogs. Much appreciated! We’ve seen much smaller toys with far more gratuitous packaging, so this was a welcome relief.

The entire contents of the box are as follows:

The TRAKR vehicle is a stubby, squat tank, measuring about 10 inches wide and 7 inches long. Six AA cells install behind a cover on the underside of the unit. The total weight with alkaline cells is 1065 grams, or about 2 pounds 5 oz. Picks up easily with one hand.

The front of the TRAKR vehicle features a number of sensors. Left to right, these include: microphone (the white circle at the left), a presently-unused accessory connection port which appears to contain a bump switch, the color video camera and infrared LED for night vision, and speaker (larger white circle at the right). The camera can be pivoted from straight ahead to about 30 degrees upward, but there is no servo control of this function; it must be manually positioned.

With the transport deck removed we can see the ports on the back of the TRAKR: an SD card slot for storing photos and video (also SDHC compatible), the USB mini-B connector for attaching to a PC (or Mac, etc.), and a USB type A connector that currently serves no purpose, but might be related to future accessories (and hacks, of course).

When connected to a host computer, the TRAKR appears as a 1-megabyte FAT12 filesystem. New apps, downloaded from the Spy Video TRAKR web site, are installed by simply copying the corresponding .bin file to the APPs directory on this flash drive. It’s quite a bit like the mbed microcontroller in this regard. With the three factory apps pre-loaded, there’s about 900K free space remaining. Additionally, the TRAKR can function as an SD card reader when attached via USB.

The remote control unit is a bit over 5 inches high and wide. Four AA cells install behind a back cover, and the total weight is 392 grams, or about 13.5 oz. The size and heft of the controller is sufficiently comfortable for both young and adult hands. There are two single-axis sticks for driving the tank Battlezone-style, five buttons (one dedicated to the “home” function, the rest being app-specific), a power and volume switch, speaker, and a 1.75″ color LCD screen in the center. Though the sticks have an analog feel, in practice they appear to be simple non-proportional controls.

The LCD looks to be half-QVGA resolution (160×120). The video feed averages a good 15 frames per second over the device’s wireless (2.4 GHz, but not WiFi) connection.

Night vision is provided by a single 8mm near-infrared LED, with a range of about six feet.

The camera can also take QVGA (320×240) color stills, and half-QVGA (160×120) video, recorded to the SD card as JPEG and AVI, respectively. Here are some unprocessed stills directly from the memory card:

So that’s an overview of the TRAKR as it comes straight from the box. To do more, we begin by visiting the Spy Video TRAKR web site:

The “Download Apps” link currently leads to a list of about a dozen simple apps developed in-house:

None of the apps is particularly outstanding; they appear to be for illustrative purposes, each one demonstrating a single idea and not wanting to overwhelm the budding programmer. Most range from about 20 to 40 kilobytes.

Clicking an app name reveals more information — a description, download link for the compiled app, and also a source code link for us geeks. Unfortunately, that’s where the fun ends for now. “APP BUILDR,” the code editor and compiler which works online (again like the aforementioned mbed microcontroller), is not yet accessible:

NOOOOOOOOOOOO!

The Spy Video TRAKR was originally slated to ship this fall for the holiday shopping season. Wild Planet managed a great head start at getting the TRAKR into production and distribution — we have the toy in-hand and you can already find this at a number of retailers — but the software is still on its original schedule for an October release. We understand software timelines and are sympathetic to that reality, but this does mean there’s little sense of urgency if your main interest in the TRAKR was for programming. It can wait.

In the interim, we can start to deconstruct the development process with the small bits of information available. From Maker Faire, we do know that the TRAKR contains an ARM9 processor, and is programmed in C. And while the code editor isn’t yet online, we can follow the “Download Source” link for an app to retrieve its source code. Here’s an excerpt from one of the demonstration programs:

Indeed it’s C, with just a light wrapping of functions (e.g. Start() and Run() instead of a main() function). There’s clearly a Spy Video TRAKR-specific API (svt.h) for accessing hardware functionality like the TRAKR’s motors or the controller’s buttons and display, but documentation for this library isn’t available online yet.

At this point, we’re still dealing entirely with standard, as-advertised, out-of-the-box capabilities. The thing about the TRAKR that really made us stop and take notice at Maker Faire, the thing that has us genuinely enthusiastic about the product even though this article probably sounds like a total corporate shill by now (we approached them first, honest), has everything to do with the toy’s Easter egg:

It’s a sublime detail: the clear letters on the otherwise frosted cover just above the rear ports hint at intriguing stuff within. The cover is held on with just a couple of ordinary Phillips screws. Say, were you the sort of curious kid who’d dismantle their toys to see what makes them work? We thought so.

On the outside: the URL for the consumer. On the inside: the URL for the inquisitive. Just a fraction of an inch and a thin sheet of plastic apart. It’s absolutely brilliant, and there’s no mention of this on the packaging or the standard web site.

So — in addition to the standard app web site, a second web site (and sadly an equally unfinished one at this time) is planned to delve even deeper into the system’s inner workings. But even without this information, we can see hints of what’s ahead just by examining the board, which they’ve thoughtfully labeled. We can make out an unpopulated third USB port, an unpopulated switch connector, a breakout header that appears to have eight GPIO lines and one analog input, and a smaller breakout header for an SPI port of some sort (perhaps debugging).

Additionally, both the TRAKR and the remote control have switches and ports concealed under access panels:

The trim pots on the TRAKR are almost certainly for tuning the radio transceiver. The switches on both units are labeled “USB” for one position and “SPI” for the other, and this appears to be related to debugging or flash memory programming. Both switches ship in the “SPI” position.

Programmer/designer [Steven Wittens] has posted a fantastic write-up on the black art of producing compact demo code, dissecting his own entry in the 1K JavaScript Demo Contest. The goal is to produce the best JavaScript demo that can be expressed in 1024 characters or less and works reliably across all standards-compliant web browsers.

[Wittens] details several techniques for creating a lot of visual flash in very few bytes, including the use of procedural graphics rather than fixed datasets, exploiting prime numbers to avoid obvious repetitions in movement, and strategically fudging formulas to save space while adding visual interest. These methods are just as applicable to other memory-constrained situations, not just JavaScript — some of the contest entries bear a resemblance to the compact microcontroller demos we’ve previously showcased, except running in your browser window.

The contest runs through September 10th, allowing ample time to come up with something even more clever. Whether he wins or not, we think [Steven] deserves special merit on account of having one of the most stylish blogs in recent memory!

35 years following its introduction, and despite fewer than 100 systems deployed, the Cray-1 remains one of the most recognizable computers in history; it is a timeless icon of pure supercomputer badassery. Custom case builder [Daryl Brach] pays homage to this classic with his third-scale model housing two modern PC motherboards.

In an interesting reversal, the base of the model — the upholstered bench that housed cooling and power distribution for the original Cray — holds the PC motherboards and storage, while the upper section is currently just for show but may house a water cooling rig in the future. The paint scheme is inspired by the Cray-1 on display at the Smithsonian, though Daryl’s model does make a few modern concessions such as LED lighting. Hinged panels in the base flip open to access the systems’ optical drives (perhaps to watch Tron on DVD).

The Cray-1 ran at 80 MHz and could house up to eight megabytes of memory…just about unfathomable performance in its day. It’s not clear what processors [Daryl] chose to outfit his system with, but regardless, even an entry-level modern PC doesn’t just run circles around its progenitor, it runs ray-traced glass spheres around it. Technology marches on, but good design never goes out of style.