UPDATE! This is now available in our store!!!

The board is a simple Arduino that has an 8×2 female header so that it can snap right onto the back of the RGB panel. The board also includes a 2.1mm power jack for a 5V power supply, a 6 pin serial header for easy programming using a USB-serial cable, and a 2-pin terminal block for connecting to the panel’s power terminals.

I had the board manufactured by Laen’s PCB service at Dorkbot PDX, which is a great way to get boards made in small quantities for projects just like this. Customers of Laen will instantly recognize his signature purple boards.

I’m so happy with this simple solution for driving my panel that I used it for a display sign when I exhibited at the Twin Cities Maker “Minne-Faire” in April. I wrote some animations for the Arduino backpack to display, and they look great. The video doesn’t do them justice because it’s really hard to capture bright LEDs on video. This panel is blindingly bright!

Feel free to download the source for this demo.

I’m not selling this board as a product because the market is probably too small, but if you have one of these RGB panels, you can make your own. Just download the design files and have the PCB manufactured!

Each bottle is individually controlled with a TLC5940 16-channel PWM driver. The software running on the ATmega328 is Arduino code that implements different lighting effects. Here it is in action:

Hardware

I designed a circuit board for the ATmega328 and the TLC5940. This is basically a custom Arduino and the design files are available below in case you want to make one. The LEDs connect from the bottom of the board. I am using a 5V regulated power supply, so there’s no need for an on-board voltage regulator. I included a 6-pin serial header for easy Arduino programming and mounting holes on the corners so I can hang it from wires. I also included a tactile button in case I wanted to allow some input to control the lamp (currently unused). Also note the Tabasco logo right on the board silkscreen!

I photographed the assembly process so you could see how I constructed the lamp.

1. Make two holes in each cap using a small nail	2. Insert a 3mm LED into the cap
3. Ensure the LED is in the center	4. Connect wires by bending the leads. Make sure they don’t short!
5. Carefully solder and clip the leads.	6. Enclose in heat shrink tubing.
7. Twist wires and weave together.	8. Keep going!
9. Insert wires into underside of board.	10. Now just solder and clip the wires.

Software

Here is the Arduino code running on the lamp. I used the TLC5940 Arduino library to control the PWM driver. You can download the code from here.

#include "Tlc5940.h"

#define NPINS 16
#define NVISUALIZATIONS 6
#define NFUNCTIONS 3
#define BUTTON 2

// pointers to the current and last visualizations                                    
void (*visualization)() = rise;
void (*lastVisualization)() = rise;

// array of visualizations                                                            
void (*visualizations[NVISUALIZATIONS])() = {throb, blinkRandom, onOff, upDown, rise, fall};                        

// An array of all the functions.                                                     
int (*allFunctions[NFUNCTIONS])(float x) = {linear, sine, exponential};


// Each pin has a function associated with it.  The function determines how the brightness                                                                                 
// of the LED changes over time.                                                      
int (*function[NPINS])(float x);

// The x values for the function associated with each LED.  The x value is the current position along                                                                      
// the x axis for the function.  There are are 256 x values on the x axis.  That is, the domain of the                                                                     
// function is [0-255].                                                               
float x[NPINS];

// dx describes (for each LED) how the x value changes over time.  If dx=1, then x is increased by 1                                                                       
// for each duty cycle.  If dx = -1, it is decreased by 1.  If dx=5, then the brightness of the LED will                                                                   
// change faster according to the function because we are moving along the function curve faster.                                                                          
float dx[NPINS];

// y is the current value of the function at x.  If the function is 'linear' and x=128, then y=128.                                                                        
// If the function is 'sine' and x=10, then y=0x03.  See the sineValues array below that defines                                                                           
// the sine function.                                                                 
int y[NPINS];

// For each LED we can specify whether the x value should "wrap" around when reaching the end.                                                                             
// There are 256 possible values for x [0-255].  If we reach 255 and dx=1, then we can wrap around                                                                         
// back to x=0 if wrapFunction=true.  If false, then adding 1 to 255 keeps x=255.     
boolean wrapFunction[NPINS];

// Definition of sine function.  Array lookup executes faster than actually computing the sine.                                                                            
unsigned char sineValues[] = {
  0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x01,0x02,0x03,0x03,0x04,0x05,0x06,0x07,0x08,
  0x09,0x0a,0x0c,0x0d,0x0f,0x10,0x12,0x13,0x15,0x17,0x19,0x1b,0x1d,0x1f,0x21,0x23,
  0x25,0x27,0x2a,0x2c,0x2e,0x31,0x33,0x36,0x38,0x3b,0x3e,0x40,0x43,0x46,0x49,0x4c,
  0x4f,0x51,0x54,0x57,0x5a,0x5d,0x60,0x63,0x67,0x6a,0x6d,0x70,0x73,0x76,0x79,0x7c,
  0x80,0x83,0x86,0x89,0x8c,0x8f,0x92,0x95,0x98,0x9c,0x9f,0xa2,0xa5,0xa8,0xab,0xae,
  0xb0,0xb3,0xb6,0xb9,0xbc,0xbf,0xc1,0xc4,0xc7,0xc9,0xcc,0xce,0xd1,0xd3,0xd5,0xd8,
  0xda,0xdc,0xde,0xe0,0xe2,0xe4,0xe6,0xe8,0xea,0xec,0xed,0xef,0xf0,0xf2,0xf3,0xf5,
  0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,0xfc,0xfd,0xfe,0xfe,0xff,0xff,0xff,0xff,0xff,
  0xff,0xff,0xff,0xff,0xff,0xff,0xfe,0xfe,0xfd,0xfc,0xfc,0xfb,0xfa,0xf9,0xf8,0xf7,
  0xf6,0xf5,0xf3,0xf2,0xf0,0xef,0xed,0xec,0xea,0xe8,0xe6,0xe4,0xe2,0xe0,0xde,0xdc,
  0xda,0xd8,0xd5,0xd3,0xd1,0xce,0xcc,0xc9,0xc7,0xc4,0xc1,0xbf,0xbc,0xb9,0xb6,0xb3,
  0xb0,0xae,0xab,0xa8,0xa5,0xa2,0x9f,0x9c,0x98,0x95,0x92,0x8f,0x8c,0x89,0x86,0x83,
  0x80,0x7c,0x79,0x76,0x73,0x70,0x6d,0x6a,0x67,0x63,0x60,0x5d,0x5a,0x57,0x54,0x51,
  0x4f,0x4c,0x49,0x46,0x43,0x40,0x3e,0x3b,0x38,0x36,0x33,0x31,0x2e,0x2c,0x2a,0x27,
  0x25,0x23,0x21,0x1f,0x1d,0x1b,0x19,0x17,0x15,0x13,0x12,0x10,0x0f,0x0d,0x0c,0x0a,
  0x09,0x08,0x07,0x06,0x05,0x04,0x03,0x03,0x02,0x01,0x01,0x00,0x00,0x00,0x00,0x00
};


void setup() {
  randomSeed(analogRead(5));
  pinMode(BUTTON, INPUT);
  digitalWrite(BUTTON, HIGH);
  Tlc.init(0);
}

void loop(){

  lastVisualization = visualization;
  visualization = visualizations[random(NVISUALIZATIONS)];

  // call the current visualization function                                                                                   
  (*visualization)();

}

// Execute n duty cycles.                                                                                                      
// First we call stepXAll() which adds dx to each x value.  This moves the LED along the x axis                                
// of its function.                                                                                                            
// Then, for each LED,  we compute the new y value for the current x value according to which                                  
// function (linear, sine, exponential) that is associated with the LED.                                                       
// For any LED that is supposed to be on at all (any pin with a y value greater than 0), we turn it on.                        
// A duty cycle is a loop of 256 steps executed quickly in succession.  At the beginning of the duty cycle                     
// each LED that has a value of y>0 will be on.  At each step we see if there are any LEDs that need                           
// to be turned off for the remainder of the duty cycle.  So if an LED has y=100, we will turn it off at                       
// step 100.  That LED will have been on for the first 100 steps of the duty cycle and off for the                             
// remaining 156 steps.  So it is dimmer.  If an LED has y=255, then it will remain on during the whole                        
// duty cycle and be at full brightness.  An LED with a low value y=10 will be very dim because we turn                        
// it off very early in the duty cycle.                                                                                        
// This 256 step cycle is executed n times as specified by the input parameter n.                                              

void dutyCycle(int n) {
  for(int i=0;i<n;i++) {
    stepXAll();
    computePinValueAll();
    for(int p=0;p<NPINS;p++) {
      Tlc.set(p, y[p]*16);
    }
    Tlc.update();
    delay(10);
  }
}

void stepXAll() {
  for(int p=0;p<NPINS;p++) {
    stepX(p);
  }
}

// Increment the x value for pin p by the value dx.                                                                            
// Wrap the function around back to 0 (or back to 255)                                                                         
// if wrapFunction is true for the pin p.                                                                                      
void stepX(int p) {
  x[p] = x[p] + dx[p];
  if (wrapFunction[p]) {
    if (x[p] > 255) {
      x[p] = x[p] - 256;
    } else if (x[p] < 0) {
      x[p] = x[p] + 256;
    }
  } else {
    if (x[p] > 255) {
      x[p] = 255;
    } else if (x[p] < 0) {
      x[p] = 0;
    }
  }
}


void computePinValueAll() {
  for(int p=0;p<NPINS;p++) {
    computePinValue(p);
  }
}

// Compute value y for pin p.                                                                                                  
// Apply the function by invoking it with the x value.                                                                         
void computePinValue(int p) {
  y[p] = (*function[p])(x[p]);
}


//////////////////////////////////////////////////////////////////////////////////                                             
// Mathematical Functions                                                                                                      
//////////////////////////////////////////////////////////////////////////////////                                             

int linear(float x) {
  return (int)(x + 0.5);
}

int sine(float x) {
  return sineValues[(int)x];
}

int exponential(float x) {
 return (int) (255.0 * pow(50, ((x/127.5)-2)));
}


//////////////////////////////////////////////////////////////////////////////////                                             
// Visualizations                                                                                                              
//////////////////////////////////////////////////////////////////////////////////                                             

// Do 30 blinks.  Each LED that is blinked will fade                                                                           
// quickly down to 0 according to the exponential function.                                                                    
void blinkRandom() {
  for(int p=0;p<NPINS;p++) {
    function[p] = exponential;
    wrapFunction[p] = false;
    x[p] = 0;
    dx[p] = -4;
  }

  for(int i=0;i<30;i++) {
    int p = random(0, NPINS);
    x[p] = 255;
    dutyCycle(10);
  }
}

void onOff() {
  allOff();

  for(int p=0; p<NPINS; p++) {
    x[p] = 0;
    dx[p] = 0;
    function[p] = linear;
    wrapFunction[p] = false;
  }

  int on = 0;
  int p;
  int d;
  while (on < NPINS) {
    p = random(0, NPINS);
    if (x[p] == 0) {
      on++;
      x[p] = 255;
      dutyCycle(1);
      d = 200 - (on * 10);
      delay(d);
    }
  }

  delay(1000);
  while (on > 0) {
    p = random(0, NPINS);
    if (x[p] == 255) {
      on--;
      x[p] = 0;
      dutyCycle(1);
      d = 40 + (on * 10);
      delay(d);
    }
  }

  delay(100);
}


void throb() {
  eachDown();

  float minSpeed = 0.4;
  float maxSpeed = 1.0;

  // Set random speeds for LEDs                                                                                                
  for(int i=0;i<NPINS;i++) {
    dx[i] = minSpeed + (random(0, 17) * ((maxSpeed - minSpeed) / NPINS));
  }

  for(int p=0; p<NPINS; p++) {
    function[p] = sine;
    wrapFunction[p] = true;
  }

  // Run for a while.  Each pin will throb according to sine wave.                                                             
  dutyCycle(random(500, 2000));

  eachDown();
  delay(500);
}


void fall() {
  int down[NPINS] = {5, 0, 15, 9, 11, 4, 2, 3, 7, 12, 14, 1, 8, 6, 10, 13};

  allOff();
  for(int p=0; p<NPINS; p++) {
    function[down[p]] = linear;
    wrapFunction[down[p]] = false;
    x[down[p]] = 0;
    dx[down[p]] = 8;
    dutyCycle(8);

  }
  delay(200);
  allOff();


}

void rise() {
  int up[NPINS] = {13, 10, 6, 8, 1, 14, 12, 7, 3, 2, 4, 11, 9, 15, 0, 5};

  allOff();
  for(int p=0; p<NPINS; p++) {
    function[up[p]] = linear;
    wrapFunction[up[p]] = false;
    x[up[p]] = 0;
    dx[up[p]] = 8;
    dutyCycle(8);

  }

  delay(200);
  allOff();


}
void upDown() {
 allUp();
 allDown();
}


void allUp() {
  if (lastVisualization == allUp) {
    return;
  }

  for(int p=0; p<NPINS; p++) {
    x[p] = y[p];
    dx[p] = 1.0;
    function[p] = linear;
  }
  dutyCycle(256);
}

void allDown() {
  if (lastVisualization == allDown) {
    return;
  }

  for(int p=0; p<NPINS; p++) {
    x[p] = y[p];
    dx[p] = -1.0;
    function[p] = linear;
  }
  dutyCycle(256);
}


void eachDown() {
  boolean done = true;

  if (lastVisualization == eachDown) {
    return;
  }

  for(int p=0; p<NPINS; p++) {
    x[p] = y[p];
    dx[p] = -1;
    function[p] = linear;
    wrapFunction[p] = false;
  }

  done = false;
  while (!done) {
    dutyCycle(1);
    done = true;
    for(int p=0; p<NPINS; p++) {
      if (y[p] > 0) {
        done = false;
        break;
      }
    }
  }
}

void allOn() {
  for(int p=0; p<NPINS; p++) {
    function[p] = linear;
    x[p] = 255;
    dx[p] = 0;
  }
  dutyCycle(1);
}

void allOff() {
  for(int p=0; p<NPINS; p++) {
    function[p] = linear;
    x[p] = 0;
    dx[p] = 0;
  }
  dutyCycle(1);
}

Hardware Design Files

The schematic and board design are open source hardware, so you are welcome to have a board fabricated yourself! Download the design files here.

I built a remote-controlled robotics platform using a 4WD mobile platform, an Arduino (Seeeduino Mega), an Adafruit motor shield, and two XBee radios for communication. There are also some super-bright white LEDs on the front for headlights. The point of the project was to show how an XBee radio can be used to send joystick sensor data without using a microcontroller on the remote.

The vehicle is very easy to control using a joystick and a couple of buttons to control the lights. First I’ll describe how the remote control unit works, then I’ll show how the vehicle was built.

The Remote

Here’s a picture of the remote control unit that I built on a breadboard. A Parallax joystick is used to control the vehicle, one button turns the headlights on/off, and another button puts the headlights in “scanner” mode, you know, like Kitt or like a cylon. The radio requires a 3.3V supply, but the analog pins cannot take more than 1.2V, so I used some precision resistors to form a voltage divider so that the analog input voltage was stepped down to less than 1.2V. Also note that the joystick is rotated 90 degrees so that it worked on a breadboard with this orientation.

To make this work, one radio needs to be running the “coordinator” firmware, and the other running the “router” firmware. In this project, the coordinator is on the vehicle and the router is on the remote control, but it should not really manot the AT/transparent firmware.

I used the X-CTU tool from Digi to write the appropriate firmware to the radios and configure them. If you have not done this before, this is not a good project to start with. It is best to start with 2 radios that you already have working together using the API firmware.

The XBee on the remote control unit is configured to send analog/digital sample packets every 100ms. Pins AD1 (pin 19) and AD2 (pin 18) are configured as analog inputs and are connected to the potentiometers in the joystick. Pins DIO3 (pin 17) and DIO4 (pin 11) are configured as digital inputs for the two buttons on the remote that control the lights on the vehicle. Here is a list of the configuration parameters that were set on the remote radio:

• AD1/DIO1 = 2 (configured as analog input)
• AD2/DIO2 = 2 (configured as analog input)
• AD3/DIO3 = 3 (configured as digital input)
• DIO4 = 3 (configured as digital input)
• IR = 0×64 (sample rate set to 100ms)
• PR = 0x1FFF (all pullup resistors enabled — this is the default)

This is a schematic of the remote control unit:

The Vehicle

The wiring for the vehicle is fairly simple. Inside the 4WD platform are 5 AA batteries for powering the motors, and a 9V battery for the Arduino. I’m using a Seeeduino Mega because that’s what I had handy but any Arduino will work. The Adafruit motor shield is connected to the 4 DC motors inside the chassis. I used the 3.3V power supply on hte Arduino to power the XBee radio. The TX/RX lines of the radio are connected to the RX/TX pins on the Arduino. There’s a ribbon cable connecting 4 output pins to the LED headlights, and a ground wire running to the headlight assembly. Here is the bottom of the headlight assembly. These are 100 ohm resistors to keep the current draw below 20mA per LED.

The Software

This code depends on the Adafruit library for using the motor shield, so download that and install it as an Arduino library. The Arduino sketch for this vehicle RobotVehicle.zip can be downloaded from here. Read the code for an explanation of how it works. The basic idea is to decode the incoming XBee API packets and map the joystick position information to the motor speeds. If the joystick is forward, all four wheels move forward. If the joystick is turned slightly to one corner, then the vehicle will move along an arc. If the joystick is hard left or right, then the wheels on the left side and right side will turn in opposite directions, causing the vehicle to rotate in place. By studying the code carefully, you should be able to understand how all of it works. Enjoy!

I bought this awesome RGB LED matrix panel from Adafruit and really wanted to see if I could make it display video from an Android phone. It was somewhat difficult, but by using my Android phone, the OpenCV computer vision library for Android, a Sparkfun IOIO board, and an Arduino, I got it working.

All of the hardware and software setup details are below, but before I explain how it works, let’s see it in action:

How It Works

This is not a beginner project, so if you don’t have experience doing any Android development, you’ll need to be patient. Just getting your Eclipse development environment set up for Android development with the OpenCV and IOIO libraries took me a couple of hours, and I’ve been using Eclipse for about 10 years.

An Android app running on the phone captures video frames and processes them down to a lower resolution suitable for the 16×32 LED matrix. OpenCV is a powerful computer vision/image processing library, and there’s a version that runs on Android. I used the OpenCV library to convert the video frames to 16×32 pixel resolution to match the LED matrix. I also constrained the color space of the frames to 12 bit color. That is, each pixel has 4 bits each for red, green, and blue. That means that each pixel can have 16 different brightness levels of red/green/blue, yielding 4096 possible colors. In other words, all of the image processing is performed on the phone because it’s much more powerful than the Arduino.

The 16×32 12-bit image uses 1024 bytes of memory on the phone (2 bytes per pixel). The Android then uses the IOIO library to write this data out one of the IOIO board’s serial ports. Each frame starts with a two-byte frame marker 0xF0 0×00, then the bytes for the pixel values are written. The performance bottleneck is between the phone and the IOIO board. I can only write about 4 frames per second, even though the serial interface between the IOIO and Arduino is 115200 baud. Since each pixel really only needs 1.5 bytes instead of 2, I could pack the pixel data tighter to get perhaps one more frame per second, but didn’t think it was worth the trouble.

The green wire in the picture below is a serial connection from the IOIO and Arduino. The Arduino code simply reads the pixel values, using the frame marker to know when a new frame begins. The pixel values are written to the LED matrix panel using the Adafruit library for controlling the panel. Driving this matrix is no small feat for the Arduino, since the matrix panel does not do any PWM on its own; the Arduino needs to generate the PWM. This matrix driver software could have been written for the IOIO to control the matrix directly without an Arduino, but Adafruit had really tuned this library for high-performance and very precise timing, so I thought I’d better stay with the Arduino code for now. The result is video at about 4 frames per second. Not very fast, but the color rendition is pretty good.

Hardware Setup

The RGB matrix panel is wired to the Arduino just as Adafruit’s instructions describe. They have an excellent page that describes how the panel works and how to use it.

The RGB matrix and the Arduino are powered by a 5V regulated power supply that can provide 2A (also from Adafruit). The IOIO board is powered independently by a 9V supply that can provide 1A. It’s important to provide plenty of current to the IOIO board so that the phone can charge, however you can adjust a potentiometer on the IOIO to reduce the charging current. As with any project with multiple power supplies, all the grounds must be connected. A single green wire provides the serial data feed from the IOIO to the Arduino RX pin.

I used a diffuser in front of the display to make it look much better. Without a diffuser, the LEDs are simply blinding and it’s not easy to see any image. My diffuser is a piece of acrylic with paper vellum on it. The diffuser is held about 5mm in front of the LED panel (with a little roll of duct tape as a spacer).

The phone (a Samsung Nexus S) is connected to the IOIO via USB. I mounted above the panel by holding it very gently with a Panavise.

Software Setup

Android + IOIO + OpenCV Software
The hardest part of the software setup is preparing your development environment for Android, IOIO, and OpenCV development. The details of how to do this are beyond the scope of this article, but all of the steps are documented in various places.

1. Set up your Android development environment: this is documented on the Android SDK website. After you have performed this step, you will be able to write simple Android programs and run them on your phone.
2. Install the IOIO library: see this great Sparkfun tutorial which describes how to run Android apps that communicate with a connected IOIO board. After you have performed this step, you will be able to upload the HelloIOIO app to your phone and have it communicate with your IOIO board. Don’t move on to the next step until you are sure you have the IOIO working with your phone.
3. Install the OpenCV library for Android by following these instructions. After successfully doing this, you should be able to run the OpenCV Android examples on your Android phone. Don’t proceed until you have this working successfully.
4. Now that you have all the supporting libraries in place, download the RGBMatrixDriver Android application project and install it in your Eclipse workspace and open it. With luck, it will compile cleanly. If not, make sure that the project is correctly pointing to the IOIO and OpenCV libraries as in the image below.
5. You may need to customize the code a bit. I used IOIO pin 7 to send serial data to the Arduino, so you may need to change the pins specified in the call to openUart in RGBMatrixActivity.java. You may also need to change some screen dimensions specified in RGBMatrixView.java to work with your phone — just follow the comments.

Once you have the application running on your phone, this is what it looks like in action. The video image is displayed with the same resolution and colors as the RGB matrix.

Arduino Software
Now that the hard part is done, it’s easy to get the Arduino software installed.

1. First, you’ll need Adafruit’s library for driving the panel. This project uses a slightly older version which you can find here. Install it in your Arduino sketchbook libraries folder just like any other library.
2. Then download and install the RGBMatrixSerial sketch and install it in your Arduino sketchbook. Compile it and upload it onto your Arduino. The sketch is so simple, I’ll show the whole thing here:

   #include "RGBmatrixPanel.h"
   
   #define A   A0
   #define B   A1
   #define C   A2
   #define CLK 8
   #define LAT A3
   #define OE  9
   #define WIDTH 32
   
   int count = 0;
   byte currentByte = 0;
   byte lastByte = 0;
   uint16_t color;
   RGBmatrixPanel matrix(A, B, C, CLK, LAT, OE, true);
   
   void setup()
   {
     Serial.begin(115200);
     matrix.begin();
   }
   
   void loop() {
     int index;
     while (Serial.available()) {
   
       lastByte = currentByte;
       currentByte = Serial.read();
   
       // Look for the frame marker 0xF000
       if ((lastByte == 0xF0) && (currentByte == 0x00)) {
         count = 0;
         matrix.swapBuffers(false);
       } else {
         if ((count % 2) == 1) {
           color = (lastByte << 8) | currentByte;
           index = (count-1)/2;
           matrix.drawPixel(index % WIDTH, index / WIDTH, color);
         }
         count++;
       }
     }
   }
   

Future Ideas

• increase the framerate a bit by packing 2 pixels in 3 bytes of transmitted data (only really need 1.5 bytes per pixel), but need different frame marker detection.
• use the 32x32 matrix panel from Adafruit
• try BlueTooth connection between phone and IOIO board (need to upgrade IOIO firmware)
• Get an Arduino Mega ADK and use it to interface with the Android phone instead of the IOIO. The framerate should be higher.

]]> http://nootropicdesign.com/projectlab/2011/12/03/vintage-holiday-ads/feed/ 0 http://nootropicdesign.com/projectlab/2011/11/01/chipkit-uno32-review/ http://nootropicdesign.com/projectlab/2011/11/01/chipkit-uno32-review/#comments Tue, 01 Nov 2011 23:07:26 +0000 Michael http://nootropicdesign.com/projectlab/?p=942 I recently got a chipKIT Uno32 prototyping platform from Newark so I could take it for a spin. Newark is the US distribution arm of Farnell and they carry both the chipKIT Uno32 and the chipKIT Max32.

Nice looking board!

There are plenty of powerful features of the Uno32 that make it compelling, especially when comparing to the Arduino. There are 42 I/O pins, which is nice. The clock speed is 80MHz versus 16MHz on the Arduino. For most hobbyists this won’t matter much; I have not often found CPU speed to be a limiting factor in projects. There’s more Flash memory to store your programs: 128K versus Arduino 32K. Again, I have never felt limited by the size of a program. In fact, the largest Arduino program I’ve written is a full-featured implementation of Asteroids and this only took 28K of Flash memory for the program.

But when it comes to SRAM, the memory that you use in your programs to store data structures, buffers, stack, etc, the chipKIT Uno32 has 16K versus 2K on the Arduino. This is a vast improvement for me. I’ve done a lot of video work with the Arduino (e.g. the Video Experimenter shield, Hackvision game system, etc.) and the size of SRAM is a significant barrier to video frame storage.

There are also 2 UARTs used for serial communication, versus the 1 on Arduino. When using Arduino, if you want to communicate with two serial devices at once (for example, the Serial Monitor on your computer and a GPS module), you had to use a software implementation of serial communication for one of the devices. But with 2 UARTs, the chipKIT Uno32 allows 2 independent hardware implementations. I like that a lot. There’s also a realtime clock and calendar (RTCC) on the PIC32MX320F128H microcontroller with the option of connecting a 32.768KHz clock crystal. That could be useful for some projects.

Make sure you check out the Hackaday article where they did an in-depth review of these boards from a performance perspective.

But what I was really interested in understanding is Diligent’s claim that the chipKIT boards are “Arduino Compatible”. What does this mean in practical terms for the hobbyist?

Compatibility: The Good News

Well, you can program the Uno32 using the normal Arduino API, like digitalWrite, digitalRead, analogRead, etc. For most hobbyists, this will allow them to read sensors, light LEDs, control motors, and the like. Maybe you need lots of digital outputs — the Uno32 has 42 pins instead of 19 on the ordinary Arduino. The Uno32 is a lot cheaper than the Arduino Mega.

So, the normal Arduino API works, but what about direct access to ports in order to more efficiently control digital I/O? I often use direct manipulation of the AVR microcontroller ports instead of using digitalWrite and digitalRead calls. That is, I set a digital pin HIGH with something like PORTB |= 0×2 instead (for speed). Will this code work with the chipKIT boards? Yes! I was surprised, but apparently the chipKIT compiler makes the appropriate adjustments to the resulting compiled code to allow direct port manipulation using the AVR semantics.

Compatibility: The Bad News

Here are some things that I think are bad news with regard to Arduino compatibility.

• Outputs are 3.3V — This means that the output voltage of the digital pins isn’t high enough to be recognized as an input HIGH voltage by many 5V CMOS chips. For example, you can’t use the digital outputs on chipKIT boards to drive a 74HC595 shift register. The 3.3V output is not high enough to trigger the input pins on CMOS chips which generally require at least 3.5V. This problem can be address by adding more components to your circuits (e.g. a transistor to translate to a higher input voltage), but that defeats the purpose of convenient Arduino shields.
• Current limitations — On the Arduino, each digital pin can source/sink up to 40mA as an absolute maximum, but in practice you should limit to 20mA. However, the chipKIT boards have a maximum of +/-18mA per pin, and the reference manual states that this should be limited to +7/-12mA per pin. This is going to be a disappointment to people wanting to drive LEDs, 7-segment displays, etc. Furthermore, the maximum current that can be sourced/sunk across ALL I/O pins simultaneously is only 200mA. That’s not much current to spread across 42 pins! I tried to light a bright blue LED and was only able to draw a dim 8mA (with no current limiting resistor at all!) because the forward voltage of the LED is just barely over the 3.3V board output voltage. Again, this can be solved with external circuitry, but that’s not convenient.
• Code rewrites — If your Arduino code accesses AVR registers directly (for example to use timers) or involves AVR assembly, you are going to have to rewrite it. This means that using my Video Experimenter on the chipKIT board would b e a total rewrite of the gnarly AVR assembly.
• Incompatible pin assignments — If you use special microcontroller functions found on the AVR, you will not find them on the same pins on the chipKIT boards. For example, my Video Experimenter shield utilizes the analog comparator function to compare the voltage of a video signal with a reference voltage. The analog comparator pin is D6 on the Arduino, but is D11 on the chipKIT Uno32. This is another barrier to using Arduino shields on the chipKIT boards. The pins don’t have the same functions.

Bottom Line

The chipKIT Uno32 is a nice board and will give many Arduino users a boost in speed and in the number of pins available. Users doing more sophisticated things that involve direct AVR register access, timers, and libraries written in AVR assembly won’t be able to simply switch to the chipKIT for their work without a lot of rewriting. Most disappointing to me is that many Arduino shields simply aren’t going to work on the chipKIT. And due to the 3.3V output, even projects using LEDs (the bread-and-butter of the Arduino world!) may have some challenges due to current limitations and the lower voltage available to light up all those blinky lights. Nonetheless, I welcome Microchip and Diligent’s efforts and hope to see some great chipKIT projects in the future!

Resources

Diligent chipKIT site
chipKIT Uno32 Reference Manual
chipKIT forums
Tips and tricks for translating between 3.3V and 5V

A few days later, on Friday September 9, I noticed an interesting lurker in my online store. The domain name of the potential customer caught my eye: tsa.dhs.gov. Was this someone at the Department of Homeland Security? Specifically, the Transportation Security Administration?

Who's this shopping in my store?

IP address lookup confirms that the shopper is from DHS

Over 5% of my visitors on Sept. 9 were from Department of Homeland Security

Uh oh.

I had not done anything wrong, but I really didn’t want a personal visit from Homeland Security, the FBI, or SEAL Team Six. In late morning, my wife called me at the office from home — I was sure that gentlemen in dark suits were at the door, but it was a false alarm. I was feeling paranoid.

Could the government really be that interested in me? Maybe looking at a map of my U.S. visitors would make me feel better…

Nope.

The statistics indicated that the visitors were not spending more than a minute on average on the site. They were taking a quick look, then leaving. My theory is that maybe a link to my Defusable Clock was included in some morning briefing or something, and a bunch of people checked it out. What do you think?

Nonetheless, I felt compelled to add this paragraph to the clock project post, hoping it might defuse the situation (pun intended):

The Defusable Clock is a fully-functional alarm clock just like you’d expect (a normal beeping alarm, snooze alarm, etc.). But at any time you can press the big red button to start a scary countdown sequence exactly like bombs in Hollywood movies. There are 4 wires across the top of the clock. You have 10 seconds to choose the correct wire to cut: one wire stops the countdown and saves the day, two have no effect, and one will “detonate” the device immediately. These role of each wire is randomly assigned when the detonate button is pressed, so it’s a new challenge every time. Also, the wires are attached with screw terminals, so you can replace them easily. If you don’t want to actually cut the wires, you can just pull them out of the screw terminals if you keep the screws a little loose.

The microcontroller is an ATmega328 with the Arduino bootloader, so this clock is programmable with the Arduino IDE. The ATmega328 is certainly more powerful than needed for a clock, but this device has lots of inputs/outputs, and ATmega328 chips are now about the same price as the older ATmega168. It keeps very accurate time and requires a simple 9V “wall wart” power adapter. A special alarm mode lets you even use the countdown sequence as the alarm and require it to be defused when you wake up in the morning. What a stressful way to start the day!

We are going to offer this as an electronics kit later this fall. Only the electronics will be in the kit — nothing that looks like dangerous explosives! With some imagination, I’m sure you can make a great looking Defusable Clock for yourself, but don’t go scaring anyone with it, and don’t bring it anywhere near an airport, ok? The product page will have plenty of warnings not to use this kit for any evil purposes or get into trouble with your school, employer, or local law enforcement! There will also be a picture gallery where you can submit a picture of your clock after you build it.

UPDATE: the Defusable Clock kit is NOW AVAILABLE FOR PURCHASE!

I’m sure some of you will have some ideas and comments, so please leave them below. Keep in mind that this is no more dangerous than any other alarm clock, and yes, we have already spoken to a lawyer about all of this.

Here’s one more version I made using clay for plastic explosives:

Clay used to simulate C4