It was an interface that launched a thousand hacks. Near trivial to program, enough I/O lines for useful work, and sufficiently fast for a multitude of applications: homebrew logic analyzers, chip programmers, LCD interfaces and LED light shows, to name a few.

Today the parallel printer port is on the brink of extinction (and good riddance, some would say). Largely rendered obsolete by USB, few (if any) new peripherals even include a parallel connector, and today’s shrinking computers — nettops, netbooks, media center PCs — wouldn’t have space for it anyway. That’s great for tidy desks, but not so good if you enjoyed the dirt-cheap hacks that the legacy parallel port made possible.

Fear not, for there’s a viable USB alternative that can resurrect many of these classic hacks! And if you’ve done much work with Arduino, there’s a good chance it’s already lurking in your parts drawer.

A recurring element among many recent hacks is the use of an Arduino or other USB-connected microcontroller as an intermediary between a PC and an external circuit. Code running on the microcontroller will poll some sensor to detect a change (for example, an empty coffee pot), then send a message over USB to a host PC where another program then acts on it (updating a web page to tell the world there’s no coffee). This is a reasonable approach, the parts are affordable and simple to program, but for many projects we can get by with just half the code, complexity and expense…and some folks will be thrilled to hear, no Arduino!

When the microcontroller on an Arduino board talks to a host PC over USB, all of the heavy lifting of USB communication is done by a separate chip: the FTDI FT232R USB to serial UART interface. This allows code on both the host and microcontroller to use much simpler asynchronous serial communication. As a size- and cost-cutting measure, some Arduino variants place this chip on a separate board to be attached only when programming the microcontroller, allowing it to be re-used for the next project.

This default USB-to-serial mode of the FT232R is what usually draws all the attention and gets all the girls. An alternate mode, less talked about but no less useful, is bitbang mode. This gives us independent software control of up to eight I/O lines, similar to the classic parallel port or the digital I/O lines of a microcontroller.

Acquiring the Hardware

If one isn’t already in your stash, FT232R breakout boards are easy to come by. Any shop that carries the Arduino Pro or LilyPad, or some of the bargain-priced Arduino derivatives (e.g. Boarduino), will also offer a programming cable that breaks out four of the FT232R I/O lines:

Above: The SparkFun FTDI Basic Breakout board (around $14) is surrounded by the FTDI TTL-232R converter cable (around $20). Both break out four data lines that can be used for general-purpose I/O.

Four data lines may seem constraining, but for many tasks this is sufficient; projects using SPI communication, shift registers and port expanders will be well served. If you need the full complement of I/O lines, more sophisticated breakout boards are available:

Above: just a few of the available full breakout boards. Clockwise from top: SparkFun Breakout Board for FT232RL (around $15), Modern Device USB-BUB ($12), DLP Design DLP-USB232R ($18) and DLP-USB1232H ($25), and FTDI’s own FT4232HQ Mini Module ($30). The latter two are based on more capable chips, the FT2232H and FT4232H, backwardly compatible but with additional features far exceeding the scope of this article.

Setting Up for Development

Another encouraging aspect of the FTDI interface is cross-platform software support; the same hacks can be created whether you’re using Windows, Linux or Mac OS X. Two software components are required to begin development: a device driver, which operates behind the scenes to handle all the low-level USB communication, and an API library, which is linked with your own code and forwards requests to the driver. Complicating matters slightly, there are two different APIs to choose from, and the setup process is a little different for each OS.

FTDI’s own API is called D2XX. This library is proprietary and closed source, but they do not charge for its use, even in commercial situations. An alternate API, libftdi, is community-developed and fully open source. This library has similar capabilities, but different function names and syntaxes. Conversion between the two APIs is very straightforward, and we’ll provide an example for each.

Windows users: if you’ve used Arduino before, the necessary driver is already installed. Otherwise, download and extract the latest Windows driver from the FTDI web site. When first connecting an FTDI cable or breakout board, use the Found New Hardware Wizard to locate and install the driver. If you want to use the D2XX library, the header and object files are included in the driver folder. This is the easier option. If you’d prefer the open source libftdi, you’ll need to download and install the both the libusb-win32 device driver and source code, then download and build libftdi.

Linux users: most current Linux distributions already have the necessary driver present as a kernel module. The D2XX library for Linux can be downloaded from the FTDI driver page, but libftdi is easier to install: simply locate libftdi-dev in your favorite package manager and have it take care of the dependencies when installing. In either case, FTDI programs for Linux need to be run as root, e.g.

sudo ./hello-ftdi

Mac OS X users: download the D2XX library from the FTDI download page. The included ReadMe file will explain how to install this library. If you’d prefer to use libftdi, download the source for libusb (legacy 0.1.12 version) and libftdi from their respective sites, then use the following commands in a Terminal window to build and install each of the two libraries:

./configure
make
sudo make install

If you’ve used Arduino in the past or have the FTDI Virtual Com Port (VCP) driver installed for any other reason, this needs to be disabled before bitbang mode will work on the Mac; the two cannot coexist. In a Terminal window, type:

sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext

To restore the driver and resume using Arduino or other FTDI serial devices:

sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext

Other operating systems: drivers for several other platforms are available. Please see the FTDI drivers page for details and links.

Most of the FTDI sample code is written in C, and that’s what we’ll use here. Bindings for other languages are available on the FTDI web site.

Hello World: Flash an LED

The standard introductory program for nearly every microcontroller is the LED flasher, so let’s give that a try. You’ll need an FTDI cable or any of the breakout boards, one LED and a 220 Ohm resistor.

Connect the resistor to either leg of the LED, but keep note of which leg is the positive (anode) side. Then insert the LED/resistor pair into the socket on the end of the FTDI cable as shown below, with the negative leg connected to the GND line (the black wire on the FTDI cable) and the positive leg to the CTS line (brown wire).

Here’s the C source code, using the libftdi API. If you plan on using D2XX, have a look at the second listing a bit later; the relationship between functions should be fairly obvious.

/* hello-ftdi.c: flash LED connected between CTS and GND.
   This example uses the libftdi API.
   Minimal error checking; written for brevity, not durability. */

#include <stdio.h>
#include <ftdi.h>

#define LED 0x08  /* CTS (brown wire on FTDI cable) */

int main()
{
    unsigned char c = 0;
    struct ftdi_context ftdic;

    /* Initialize context for subsequent function calls */
    ftdi_init(&ftdic);

    /* Open FTDI device based on FT232R vendor & product IDs */
    if(ftdi_usb_open(&ftdic, 0x0403, 0x6001) < 0) {
        puts("Can't open device");
        return 1;
    }

    /* Enable bitbang mode with a single output line */
    ftdi_enable_bitbang(&ftdic, LED);

    /* Endless loop: invert LED state, write output, pause 1 second */
    for(;;) {
        c ^= LED;
        ftdi_write_data(&ftdic, &c, 1);
        sleep(1);
    }
}

If the program successfully compiles (all of the required headers and libraries in the appropriate locations, and properly linked with our own code), the LED should flash slowly.

The code is largely self-explanatory, but there are a couple of points worth highlighting:

• Note the second parameter to ftdi_enable_bitbang(). This is an 8-bit mask indicating which lines should be outputs (bit set) vs. inputs (bit clear). As we’re only using a single output line (CTS in this case), we set just the one bit corresponding to that line (0×08). For additional outputs, we can OR the bit values together. The bitbang I/O pin mappings aren’t defined in either API’s header, so you might find it helpful to keep around a header such as this:

  #define PIN_TX  0x01  /* Orange wire on FTDI cable */
  #define PIX_RX  0x02  /* Yellow */
  #define PIN_RTS 0x04  /* Green */
  #define PIN_CTS 0x08  /* Brown */
  #define PIN_DTR 0x10
  #define PIN_DSR 0x20
  #define PIN_DCD 0x40
  #define PIN_RI  0x80

• Notice that the second parameter to ftdi_write_data() is a pointer to an 8-bit variable. The function normally expects an array (and the second example will demonstrate this), but for this simple case only one value is required. When issuing a single byte like this, remember to always pass by reference (a pointer), not a numeric constant. The last parameter to the function is the number of bytes.

The value(s) passed to ftdi_write_data() indicate the desired state of the output lines: a set bit indicates a logic high state (3.3 or 5 volts, depending on the FTDI adapter used), and a clear bit indicates logic low (0 volts). The mapping of bits to I/O pins is exactly the same as for ftdi_enable_bitbang(), so the prior #defines may be helpful in that regard.

More Bells and Whistles

There are many project ideas that only occasionally need to toggle an I/O line: ring a bell when a web counter increments, flash a light when email arrives, send a Tweet when the cat uses the litter box. The code for such tasks will often be just as simple as the example above. But when communicating with more complex devices and protocols, this byte-at-a-time approach becomes very inefficient. Every call to ftdi_write_data(), even a single byte, issues a USB transaction that will be padded to a multiple of 64 bytes, and there can be latencies of a full millisecond or more before this request is actually sent down the wire. To efficiently send complex data streams, it’s necessary to pass an entire array to the ftdi_write_data() function.

Bitbang mode operates very differently than the chip’s default serial UART mode. In the serial configuration, one simply calls fwrite() to issue a block of data to the serial port, and the chip manages all the details of the transmission protocol: word length, start, stop and parity bits, and toggling the logic state of the TX line at the required baud rate. In Bitbang mode there is no implied protocol; this is raw access to the data lines, and we must take care to construct a meaningful signal ourselves, essentially creating an image map of the data lines over time:

Suppose we want to communicate with a device that uses the SPI protocol (Serial Peripheral Interface, also sometimes called Microwire, synchronous serial or three- or four-wire serial, depending on the implementation). The required output would resemble the waveform in the illustration above: one output line provides a clock signal, another represents the data bits (in sync with the clock), and a third issues an end-of-data latch signal. If sending 8 bits of data, our output array would need to be twice that size (to represent the high and low state of each clock tick), plus two additional bytes for the latch high/low at the end. 8 * 2 + 2 = 18 bytes in the output array (possibly a few extra bytes, if a specific device requires a short delay before the latch signal).

SPI might be too esoteric for an introductory article; not everyone will have the right components around. Instead, let’s make something visually gratifying: we’ll drive a group of LEDs using pulse width modulation. This is of dubious utility but it’s flashy and hints at the speed and fine control that’s possible using this port.

The hardware setup is similar to the first example, but repeated four times: four LEDs, four 220 Omh resistors (we’re limiting it to four in order to work with the FTDI cable or SparkFun Basic Breakout, but it’s easily expandable to eight with the other boards). The negative legs are all connected in common to the GND line (black wire on the FTDI cable), while the positive legs are connected to CTS, TX, RX and RTS (brown, orange, yellow and green wires, respectively). The SparkFun Basic Breakout has DTR in place of RTS for the last pin, but the example code will work the same with either one…we’ll explain how shortly.

Here’s how the components look on a breadboard. Notice that the +5V line (red wire on FTDI cable) is skipped:

And here’s the source code, using the D2XX API. Adapting this to libftdi is straightforward; see the first example for the different syntaxes.

/* pwmchase.c: 8-bit PWM on 4 LEDs using FTDI cable or breakout.
   This example uses the D2XX API.
   Minimal error checking; written for brevity, not durability. */

#include <stdio.h>
#include <string.h>
#include <math.h>
#include <ftd2xx.h>

#define LED1 0x08  /* CTS (brown wire on FTDI cable) */
#define LED2 0x01  /* TX  (orange) */
#define LED3 0x02  /* RX  (yellow) */
#define LED4 0x14  /* RTS (green on FTDI) + DTR (on SparkFun breakout) */

int main()
{
    int i,n;
    unsigned char data[255 * 256];
    FT_HANDLE handle;
    DWORD bytes;

    /* Generate data for a single PWM 'throb' cycle */
    memset(data, 0, sizeof(data));
    for(i=1; i<128; i++) {
        /* Apply gamma correction to PWM brightness */
        n = (int)(pow((double)i / 127.0, 2.5) * 255.0);
        memset(&data[i * 255], LED1, n);         /* Ramp up */
        memset(&data[(256 - i) * 255], LED1, n); /* Ramp down */
    }   

    /* Copy data from first LED to others, offset as appropriate */
    n = sizeof(data) / 4;
    for(i=0; i<sizeof(data); i++)
    {
        if(data[i] & LED1) {
            data[(i + n    ) % sizeof(data)] |= LED2;
            data[(i + n * 2) % sizeof(data)] |= LED3;
            data[(i + n * 3) % sizeof(data)] |= LED4;
        }
    }   

    /* Initialize, open device, set bitbang mode w/5 outputs */
    if(FT_Open(0, &handle) != FT_OK) {
        puts("Can't open device");
        return 1;
    }
    FT_SetBitMode(handle, LED1 | LED2 | LED3 | LED4, 1);
    FT_SetBaudRate(handle, 9600);  /* Actually 9600 * 16 */

    /* Endless loop: dump precomputed PWM data to the device */
    for(;;) FT_Write(handle, &data, (DWORD)sizeof(data), &bytes);
}

When successfully compiled and run, the LEDs should slowly pulsate in a repeating “chaser” cycle. There are some notable differences from the first example:

• LED4 is defined by two bits, a logical OR of both RTS and DTR, and the two bits are always toggled in unison. This isn’t a mandatory requirement, it simply makes the program compatible with different hardware: the FTDI cable and the SparkFun Basic Breakout use a different signal on the last pin, and toggling both bits makes it work the same regardless.
• The baud rate is explicitly set to 9600 bps (bitbang mode will actually run at 16 times the baud rate). This is so the PWM speed will be the same whether using libftdi or D2XX. The former library normally initializes the port to 9600 baud by default, while the latter API (used here) opens the port at maximum speed and we need to slow it down to match. In practice, at maximum speed we’re able to get about 650,000 8-bit samples per second out this port.
• In Mac OS X 10.6, you may find it necessary to pass the -m32 flag to gcc in order to compile and link with the D2XX library. And Windows programmers using Cygwin may need some additional header files:

  #include <stdarg.h>
  #include <windef.h>
  #include <winnt.h>
  #include <winbase.h>

Pulse width modulation makes for a nice visual demonstration of speed but unfortunately can’t really be put to serious use. In addition to the previously-mentioned I/O latency, other devices may be sharing the USB bus, and the sum total is that we can’t count on this technique to behave deterministically nor in realtime. PWM with an LED looks just fine to the eye…the timing is close enough…but trying to PWM-drive a servo is out of the question. For a synchronous serial protocol such as SPI, where a clock signal accompanies each data bit, this method works perfectly, and hopefully that can be demonstrated in a follow-up article.

Not a Panacea

FTDI bitbang mode comes in handy for many projects, but it’s not a solution to every problem. There are many situations where a microcontroller is still preferable:

• For extended standalone use, it’s a no-brainer: a microcontroller board costs less than a fancy meal and runs for days on a 9-volt battery. Only when a project is going to involve a full-on PC anyway should bitbang mode be considered.
• If a task involves basic analog-to-digital conversion, you’re almost certainly better off using a USB-connected microcontroller with built-in ADC. It’s just less hassle than the alternative.
• For tasks that require continual high-speed polling of a sensor, bitbang mode will needlessly gobble USB bandwidth and CPU cycles. Most microcontrollers have an interrupt-on-change feature that avoids polling entirely, using resources only when a change actually occurs.

We hope this introduction has planted the seeds of new hacks in your mind, or will breathe new life into forgotten classic parallel port hacks. To dig deeper, the FTDI web site is the best resource. Here you’ll find data sheets, articles, and most useful of all are the application notes. There’s also information for working with other languages: Java, Perl, Python and Visual Basic, among others.

Update, Saturday July 4th, 2009: All preorders are closed.

A probe cable makes it easy to connect the Bus Pirate to a circuit and get hacking. Good test clips make quick connections on cramped PCBs without causing short circuits. We made two cables for the Bus Pirate v2, keep reading for an overview of our designs and list of part suppliers.

Friday, July 3, 2009 is the last day to pre-order a Bus Pirate. There’s only two days left to get your own Bus Pirate, fully assembled and shipped worldwide, for only $30.

Overview

We use these cables to connect the Bus Pirate’s I/O pins to a microchip or test circuit. A cable consists of a 2×5 connector, a cable, and some kind of attachable probe like an alligator clip or test hook.

The gray cable (top) is a ‘junk box’ cable, we recycled it from scrap parts and old computer hardware. The ‘expensive’ cable (bottom) uses high quality and special-order parts.

2×5pin female connector

The Bus Pirate’s I/O header is two rows of five 0.1″ spaced pins. We used a 2×5 arrangement because 2×5pin female ribbon cable connectors are common and cheap. We decided against a single row of 10 pins because the connector is an expensive specialty item.

The pin names are shown above, and are silk-screened on the bottom of the PCB. See the Bus Pirate page for detailed descriptions of each pin function.

The junk box cable uses a 2×5pin female connector from an old PC ISA card.

The expensive cable uses a black connector with a reinforced cable holder. Mouser has gray connectors ($0.69) and black connectors ($1.15).

Ribbon cable connectors have internal pins that pierce the cable when the top part is pressed onto the bottom part.

Ribbon cable

Standard 2×5pin female connectors attach to 0.05″ 10-strand ribbon cable. The wire thickness is usually 22, 24, or 26 AWG. We think 12inches (30cm) is a useful length that doesn’t get in the way.

Grey ribbon cable is pretty common. We salvaged a piece from an old computer connector, you might get lucky and find one with a 2×5 connector already attached.

A color coded cable makes it easy to identify each connection. DigiKey has 5 foot sections ($3.03), Mouser has it by the foot ($1.16, $1.19).

Ribbon cable is cheap and readily available, but it tends to tangle and kink. A really nice probe could use a ribbon cable stub attached to thicker test leads.

Test clips

Test clips are the most important part of the cable. They have to be easy to position, and maintain contact with the circuit. Alligator clips work, but there’s a lot of exposed metal that can create short circuits. Professional test clips have a grabber that retracts into the probe leaving less metal exposed.

Alligator clips

The junk box cable has alligator clip probes, we pulled them off test leads like these (40 leads for $12). You could also use loose red and black clips (20 for $2.30).

Remember to put the rubber housing on the cable before soldering the wire to the alligator clip, it won’t go on later. In the photos you can see that some of our covers are cut to fit over the front of the clip because we forgot.

Round test hooks

This is the classic, round-bodied test hook. These are great for grabbing onto 0.1″ pin headers, wires, and the leads of through-hole components. The hooks are usually too big to use with surface mount components, and the round body makes it hard to fit more than a few in a small space.

Test hooks are easy to position. Squeeze the probe to extend a single metal hook, grab something, then release. The hook retracts into the body of the probe, securing it in place and preventing short circuits.

Most hooks come apart by pulling the top away from the body. Put the test lead through the hole in the cap and solder it to the metal tab. Push the halves together when the joint is cool.

DigiKey ($17.26) and Fry’s ($14.95) have multi-colored hooks in sets of 10. Deal Extreme has dirt-cheap 10 packs of yellow ($2.30)  and black ($2.33) hooks, but the reviews say the quality matches the price so buy extra (via [haku]).

Flat test tweezers

Tweezer-probes are great for clipping onto the legs of through-hole, surface mount, and many smaller chips. They usually have a flat body so they fit better in tight spaces than round hook probes.

This type of probe has tiny tweezers instead of a hook. Accidental short circuits are rare because there’s so little exposed metal when the tweezers retract.

Most tweezer-probes pull apart and have a metal solder tab inside. Run a cable strand through the hole in the cap, solder it to the metal tab, and then press the halves back together.

Tweezer quality varies dramatically among brands, we’ve used no-name probes that bend easily or don’t grip well. The X- series micro-hooks from E-Z-Hook are the Cadillac of tweezer-probes, we first used the XKM version that comes with the Saleae Logic. They’re intended to fit specialty test leads, but it’s easy to solder a wire to them instead. About $2 each, available directly from the E-Z-Hook website.

Conclusion

We highly recommend a cable with hook or tweezer-probes for secure connections without causing shorts. The right probe depends on the parts you use. Round test hooks work best with through-hole parts and wires. Flat test tweezers attach well to small, surface mount chips.

Please share any additional part sources in the comments. We did our best to provide a variety of sources, but there’s going to be some great places we’ve missed.

Friday, July 3, 2009 is the last day to pre-order a Bus Pirate. There’s only two days left to get your own Bus Pirate, fully assembled and shipped worldwide, for only $30.

Update, Saturday July 4th, 2009: All preorders are closed.

The Bus Pirate is a universal serial interface tool, we use it to test new chips without writing any code. It currently supports most serial protocols, including 1-Wire, I2C, SPI, JTAG, asynchronous serial, MIDI, and more. We added some other features we frequently need, like pulse-width modulation, frequency measurement, voltage measurement, bus sniffers, pull-up resistors, and switchable 3.3volt and 5volt power supplies.

The new v2 family adds USB power and connectivity to the best Bus Pirate design yet. We also reduced the part count and cost wherever possible. If you want to get your hands on some Bus Pirate USB goodness, Seeed Studio has assembled hardware for $30 (including worldwide shipping).

Read about the new design after the break.

Concept overview

The Bus Pirate connects to a PC USB port. The user send commands to the Bus Pirate from a serial terminal on the PC. Commands are translated to the bus protocols that control microchips. See our Bus Pirate page for full documentation.

The latest firmware supports 1-Wire, I2C, SPI, JTAG, asynchronous serial, MIDI, and PC keyboards. Bit-wise 2- and 3-wire libraries can interface most proprietary serial protocols.  More protocols are being added all the time, check out the source code on our Google Code SVN page.

Hardware

Click for a large image of the schematic (PNG). The schematic and board layout were made with the freeware version of Cadsoft Eagle. Download the latest files from our Google Code page.

PIC24F

A Microchip PIC24F series microcontroller generates the user interface and translates input into bus communications. V2 uses the same 24FJ64GA002 as the previous Bus Pirate versions. It’s cheap, has a ton of memory, a couple 5volt tolerant input pins, and the peripheral pin select feature lets us assign hardware modules anywhere we want.

The PIC (IC1) is powered by a 3.3volt regulator (VR2, C23). Each PIC power pin gets a 0.1uF bypass capacitor (C1,2). The internal 2.5volt regulator requires a 10uF tantalum capacitor (C20). The programming pins are brought to a five pin header (ICSP) on the edge of the PCB.

USB interface

The Bus Pirate is powered from the USB 5volt supply, which is first filtered with a ferrite bead (L1) and 10uF tantalum capacitor (C21). We used the small, still-not-quite-common, USB mini-b connector (J2).

Choosing a ferrite bead is a common hangup. Its purpose is to filter small power fluctuations, all the current for the circuit will go through it. We can guestimate that the Bus Pirate’s worst case current consumption is 525ma (3 power supplies @ 150ma, the FTDI chip @ 25ma, 2 LEDs @ 50ma max). Use a ferrite bead rated for at least 1000ma to be safe. We used this one, which is rated for 1500ma and costs 10 cents.

An FTDI FT232BL USB->serial chip (IC2) handles the USB connection. You might be familiar with this chip from various Arduino boards. FTDI has extensive driver support for most platforms, we used the virtual com port drivers.  This is the latest generation chip, and it’s only available in small SSOP and QFN packages. We had no problem hand-soldering it to a professional PCB, but it’s not for everyone.

The FT232BL is powered directly from the filtered, unregulated USB supply. C4 is a  decoupling capacitor for the FTDI232BL supply pin. A single LED (LED4/USB) indicates USB status and activity. The FT232BL RXLED pin sinks current, so we powered the LED from the 5volt USB supply through a 1.1K resistor (R3).

While the FT232BL runs at 5volts from the USB supply, its serial IO pins have an independent supply input – they can operate at another voltage. Since the microcontroller is 3.3volts, we just feed the FT232BL IO pins a 3.3volt supply and eliminate any funky translation circuitry. We used the chip’s internal 3.3volt regulator to supply the IO pins because it was the easiest trace to route. The IO pins get their own 0.1uF bypass capacitor (C5).

Switchable power supplies

The Bus Pirate has on-board 3.3volt and 5volt supplies (VR3, VR4) that can power a test circuit. The supplies are switchable, so we can reset the circuit from software when something goes wrong. To be extra safe, the supplies are held off until activated in the terminal.

[Nathan Seidle] at SparkFun recommended that we replace the  TPS796xx ($2.50) we used in The Bus Pirate v1a with a MIC5205-xxYM5 ($0.90). They supply just 150ma maximum current, compared to 800ma from the TPS796xx, but the cost savings and reduced part-count are worth it.

The regulators are fed from the 5volt USB supply. The 5volt regulator drops a few millivolts below optimal because there’s no headroom, but it’s within the minimum level specified by most 5volt parts.

The MIC5205 requires a large output filter capacitor (C22-24, 10uF), but no input capacitor. An optional small-value capacitor on the BP pin can decrease power supply noise, but we left this off because it didn’t make much difference in practice.

A small voltage on the EN pin enables the supply, we used a 10K pull-down resistor (R18, not shown) to ensure that the supplies stay off while the PIC initializes. LED3/VREG, with current limiting resistor R32, lights when the power supplies are active.

On-board pull-up resistors

Bus Pirate V2 has multi-voltage, software controlled pull-up resistors via the 4066 (PDF) quad bilateral switch (IC3). When enabled, the 4066 connects the four on-board bus pull-up resistors (R20-23, 10K) to any external signal on the Vpullup pin (0 to 5volts). When disabled, the outputs are high-impedance and have no effect on the bus lines.

The 4066 can’t switch an input voltage greater than the supply voltage. To give it the widest possible range, we powered it from the USB supply (5volts).

When operated at 5volts, it takes 4volts+ to enable the 4066. The PIC pins have a maximum output of 3.3volts, so we have a problem. We solve it with a 5volt tolerant PIC pin and a pull-up resistor.  We turn on the 4066 with a pull-up resistor to 5volts (R19, 10K), and then disable it by switching the connected PIC pin to ground.

For a brief instant at power-on, the PIC pin is high-impedance and the 4066 outputs are active because the pull-up resistor holds the control pins at 5volts. This is a concern if the Vpullup input is connected to an external 5volt supply while the bus is connected to a 3.3volt device – the brief exposure to 5volts might harm the device. If you’re worried about this, make sure there’s no active power supply connected to the Vpullup input before powering the Bus Pirate. This isn’t a concern if you use one of the on-board power supplies for the pull-up voltage because they’re disabled at startup.

Voltage monitoring

Four voltage dividers (R10-17, 10K), attached to analog to digital converters, allow the 3.3volt PIC to safely measure up to 6volts DC.

Two voltage monitors measure the switchable power supply output. One measures the Vpullup input voltage, and another connects to the external voltage measurement probe.

Indicator LEDs

Three LEDs indicate power, mode, and voltage regulator status (LED1-3). LED4/USB displays USB activity.

There are pads for resistors R30-32 and LEDs 1-3 on the front and back of the PCB. Only one set should be populated. We put pads on both sides so the board could be mounted with the indicator LEDs abutting the top of an enclosure.

V2a vs V2go

Click for large schematic (PNG) and layout (PNG) images of the version 2a hardware. The Eagle layout files are available in our Google Code SVN.

Bus Pirate V2a is a developer’s board. In addition to all the features of V2go, it includes a jack (J1) for an external power supply and an additional 5volt regulator (VR1).  A switch (S1) selects between USB power and the external supply.

The FT232BL chip on V2a is powered directly from the USB supply, and is not connected to the external supply. This is useful if you want to disable USB and use the Bus Pirate with a serial port on a PC or PDA.

The V2a 4066 enable pull-up resistor is powered by the switchable 5volt regulator. The 5volt regulator must be enabled for the 4066 to be active. Don’t forget to install the 4066 pull-up resistor (R19), located on the back of the v2a PCB.

PCB

The PCB is a compact, 2-layer design. We prepared gerbers and had PCBs made by our usual service, BatchPCB ($21, shipped to EU), and tried a new service offered by Seeed Studio ($32, shipped worldwide).

Seeed has a PCB service specifically for open source hardware projects. For $32 (including worldwide shipping) we got 5 small PCBs, and Seeed made a few extra to sell in their shop. We liked the idea that there would be extra PCBs available.

You might know Seeed Studio from their cheap, improved Seeeduino Arduino clone. They’re located in Shenzhen, a Chinese electronics manufacturing hot-spot. A bunch of notable bloggers recently visited the region and wrote about the huge electronic component markets.

The Seed order arrived in 14 days (left), the BatchPCB order arrived in 30 days (right).  Seeed and BatchPCB both make beautiful PCBs. Seeed has a much faster turn-around, and has better minimum trace widths and separation (8mil vs 6mil). BatchPCB has standard green PCBs, Seeed gives you the choice of green, black, or white; red, blue and yellow are $7.50 extra.

We really like the Seeed PCB service, extra Bus Pirate v2go and v2a PCBs from our order are available in the Seeed shop. BatchPCB remains the cheapest prototyping option if you want a single board, closed source work, or don’t mind the extra wait.

Parts list

Firmware

The latest Bus Pirate firmware for all hardware version is always available on our Google Code page. The code is written in C, and is compiled with the Microchip C30 demonstration compiler.

Bootloader

The biggest change in the latest firmware is the addition of a bootloader. Now the firmware can be updated through the USB or serial connection.

A bootloader is small program that sits at the beginning of the PIC program memory. It accepts updated firmware through the USB or serial port and saves it to the chip.

The bootloader comes from Microchip application note AN1157. We modified the bootloader to check for a jumper between the programming clock (PGC) and data (PGD) pins at power-up (update, above left). If there’s a connection, the bootloader takes over and waits for new code. Without a connection, the bootloader exits and runs the main program.

There’s a very minor chance of accidentally entering the bootloader with no jumper installed. This won’t damage the Bus Pirate, but you will need to connect it again.  You can prevent it by moving the jumper over one position,  between the ground pin and the inner programming pin (normal, above right).

Upgrading the firmware with the bootloader

If you’re using a fresh chip, first program it with the bootloader firmware (vxx-PIC Bootloader.hex) through the ICSP header using a ‘real’ programmer like an ICD2 or PicKit.

If you’re upgrading, follow this procedure or refer to the instructions in the firmware download.

• Disconnect the Bus Pirate from any power supply such as the USB cable.
• Place a jumper between the programming data and clock pins of the ICSP header. This will trigger the bootloader mode.
• Connect the Bus Pirate to a USB port (or, if applicable, power and serial cable).
• Start the MS Windows P24QP.exe programmer utility. You may need to modify the COM port (portindex=) in P24qp.ini to match your system.  Programmer source is available, and the simple bootloader protocol is documented in AN1157 if you want to write an app for a non-Windows system.
• Click the connect to device icon (#1). The program will connect to the PIC.
• Click the folder icon (#2) and open the firmware update file (vxx-Firmware for BL.hex).
• Click the erase device icon (#3) to erase the chip. DO NOT SKIP THIS STEP. Programming may not be successful if you forget to erase the chip.
• Click the write device icon (#4) to program the new firmware. Ignore any verify errors between 0×400 and 0xBFF, the bootloader lives in this region and doesn’t get updated.
• Click the green arrow icon (#5) to exit the bootloader and start the program. Click OK at the warning, we use the jumper to re-enter the bootloader.
• Remove the jumper from the programming pins, or move it over one position to connect the inner PGx pin to ground (GND).
• ***IMPORTANT*** Now restart the Bus Pirate by disconnecting and reconnecting the USB cable (or power cable). Some features won’t work until after a complete hardware reset.

Using it

USB device driver

You may need to install an FTDI virtual serial port driver for your platform.

On Windows, go to the Device Manager to configure the FTDI driver or check the COM port number.

Menus and Syntax

Use a serial terminal to communicate with the Bus Pirate. We like Tera Term.

The Bus Pirate works best with the terminal set to 115200bps, 8 databits, no parity, 1stopbit. Disable local echo in the terminal, and use CR for line breaks. Some modes also require Xon/Xoff software flow control.

In the serial terminal, press ? for the help menu. Read more about the Bus Pirate’s menu and syntax on the Bus Pirate page. There’s lots of demonstrations in our recent parts posts.

LED indicators

• PWR indicates power to the Bus Pirate.
• MODE is off when the I/O pins are in a safe, high-impedance state. MODE is lit when a bus mode is engaged, the pins may be active.
• VREG indicates that the on-board switchable power supplies are active.
• UR is a single USB activity indicator LED. It displays data coming from the PC to the Bus Pirate. You can probably change what this LED displays with the FTDI configuration utility.

Connections

Pin location diagrams: v2a, v2g0.

Notes: * TX moved from CS to MOSI in firmware v0g.

The 10 pin I/O block contains the data signals and power supplies that connect to a test circuit. Each pin is labeled on the back of the PCB, refer to the table above for a detailed description.

The pinout on V2 is similar to V1, but we moved the power supply output and Vpullup input to the cable bundle. We also eliminated the second, unused auxiliary pin.

Conclusion

If you want a complete Bus Pirate or a kit, here’s a couple options:

• Seeed Studio is accepting pre-orders for assembled Bus Pirate v2go hardware until the end of Friday, July 3.  An assembled Bus Pirate v2go is $30, including worldwide shipping.
• Seeed Studio also has the extra v2g0 ($5.90) and v2a ($6.50) PCBs from our order.
• Fundamental Logic sells a through-hole kit version of the Bus Pirate V1a ($29.50). ***v1a is serial port only***

Thanks to everyone who contributed to this project. The Bus Pirate wouldn’t be possible without a ton of great feedback from the comments. If you’d like to get involved, join the Bus Pirate project at Google Code.

Hack a Day review disclosure: We asked Seeed Studio to make our first order of PCBs for free. Since then, we’ve made several paid orders.

Spot welders are used in the fabrication of automobiles, PC cases, power supplies, microwave ovens, electrical junction boxes, Faraday cages, and various electronics. A spot welder is used because it produces a highly defined point of contact weld. The materials are welded without excessive heating, so working pieces are handled easily. The weld is also highly controlled and repeatable. In this how-to we cover the basics of a spot welder, and then show you how to build one from a microwave oven transformer.

A spot welder’s electrodes serve at least three functions. They transfer electrical energy to the material while also holding it together; this also controls resistance. The greater the pinch force the less the resistance, which results in decreased resistive heating. A lesser pinch force results in increased resistive heating. The electrodes also conduct heat away from the material, while in the off cycles, helping to cool and temper the weld. A resistive spot weld is commonly referred to as a ‘nugget’. Spot welders are generally confined to ferrous materials which somewhat limits their application range. Most produce a weld with low voltage and high current. The welder in this How-to operates from a secondary of 3vac. The primary is 120vac line voltage that should be treated with respect. The low voltage secondary makes the welder very safe, so the electrical shock hazard from the electrode is virtually non-existent. There is however the risk of burn due to the high temperatures as with any welder.

This particular welder is not intended to weld a body panel on your 1966 Jeep; it will not work well on material heavier than 20gauge sheet metal. The intended use is for small projects, for it is not capable of continuous operation. Possible uses are as follows: Welding electrode material for electrolysis cells. Working with the fine components of a vacuum tube. Building a light weight frame for a small robotic platform. Most of us have enough parts laying around to build a spot welder. If you have a microwave oven transformer (MOT) laying around, then you are half way there. On a related note, we had covered a microwave oven arc welder in 2006.

We also needed some heavy gauge copper wire. We used about four feet of 4AWG wire to build the spot welder in the photo. Other materials included scrap 2×6, 2×2, two copper screw type lugs, two copper welding cable lugs, two MIG welder tips, two 4″ x 3/4″ zinc plated corner braces, drywall screws, and three washers.

Pictured above is a working MOT. The first thing we had to do was remove the secondary coils. Namely the high voltage winding, and the low voltage winding. We used an angle grinder with cut off wheel while being careful not to cut the primary winding.

We cut the secondary flush with the MOT laminate core. Both sides of the MOT should be cut. Inspect the MOT for signs that the laminate has been welded. We have found that welded MOTs can handle a little more abuse than their sealed only counter parts. If possible try to keep the core insulation intact, where the secondary will be wound. Though it is not a show stopper if the insulation becomes damaged. The insulation makes it a little easier to wrap the heavy gauge secondary.

After removal of the secondary we had something that resembles the above photo. If the magnetic shunt material falls out be sure to replace it as it was before. The shunt keeps the core from transferring too much power to the secondary. A magnetic ballast if you will. The shunt acts to control the saturation of the core. A brute force project like this relies on such a shunt for proper operation.

Rewinding a MOT with 4AWG is no walk in the park. If you’ve damaged the core insulators, we suggest wrapping a layer of electrical tape in their place. This will help to avoid damaging the insulation on the wire as it is pulled through the core.  Our experience is that 3-4 windings is plenty. After all, this spot welder relies on high current and marginal resistance. Not high voltage.

We were careful to ensure that the secondary coil was wrapped in a helical manner to complete the secondary.

We mounted the MOT and 2×2 to the 2×6 base. This particular build used 12″ 2×6 with two 7″ 2×2. These dimensions may or may not work depending on the physical size of your MOT. The only critical part here is keeping the wire length as short as possible.

After the lower jaw was mounted, we also attached the corner braces. It was found that a spare piece of 2×2 as a shim worked well to align the upper and lower jaw. After the upper jaw was aligned we attached it to the corner braces with screws. This formed the hinged portion of the jaw.

The picture above shows the MIG welder tip and the screw type copper lug. This is an improvement from an earlier model we had built. Initially, we used copper tubing with a hole and a piece of 6AWG grounding wire serving as the welding electrode. The grounding wire was held in place by a screw that threaded inside the copper tube perpendicular to the electrode. It was very crude, but it worked. This new method is much more practical.

Here are the two electrodes ready to be fixed to the lower and upper jaws. We double checked the MIG electrodes to make sure they were tight. A loose connection will take heat away from the weld nugget.

Evenly aligning the welding electrodes, we were careful to keep the upper jaw in the natural position where it was mounted. This maintained a flat contact area for the welding electrodes. After we were sure that the electrodes had been properly aligned, the jaws were marked. We then drilled a small hole. Since we mounted with the grain of the 2×2 the holes helped to protect from splitting the 2×2.

With the electrodes mounted, we cut the wire to proper length. We never cut the exact amount we need. We always cut more than we need. This rule of thumb should apply to all electrical wiring. After all it is much easier to cut off excess than wrap a new secondary.

We bent the wires in to the approximate positions in which they were to be assembled and stripped the wire in preparation for the crimp type welding lugs. It is a good idea to strip more than is needed here as well. Simply cut off excess after sizing up the lugs depth. Never crimp insulation with the lug. This will create a potential problem area due to the loss of conduction.

Using a good non insulation crimp tool to secure the wire. We inspected the crimp and gave it the tug test. Simply tug on the wire if it is loose it will pull out. It if doesn’t pull out then an adequate crimp suitable for high current has been made.

The crimped wires were attached to the welding electrodes with screws. We were careful not to over tighten the screws. If a drywall screw had stripped out of the wood, we would have had to use a larger wood screw in its place. After both welding electrodes were fixed to the jaws, we aligned the electrodes. Using pliers we bent the electrodes so that they contacted each other evenly. The electrodes should be fairly close already since they were aligned before drilling.

We opened the jaws and wired the primary to an electrical cord and then tested the secondary. If the breaker trips, check for the following:

1. The secondary is  shorted (the jaws are closed)
2. The magnetic shunts are missing or not properly reinstalled
3. Faulty line wiring to primary or shorted primary
4. Too much load on the circuit of test or undersized breaker

We observed proper electrical wiring practices. It is also stressed that this is a welder and it should have a dedicated circuit as any other welder would have.

With the power physically disconnected we verified the welding electrode alignment with the material we intended to work on. Before connecting the power and performing an initial weld, we observed a few safety guidelines. This is a welder and will produce very high temperatures. Keep fingers away from the welding electrodes. Allow the material to cool prior to handling. Always wear eye protection. You may be interested in reading about spot welder parameters. There’s also the problem of combustible materials…

This Compaq used very thin aluminum to support the screen and connect the hinges. The metal broke and destroyed most of the lower plastic. We were able to make new supports from 22AWG stainless steel sheet metal. All the welds were made using the spot welder with a special power controller. The power controller will be covered in another how-to.

Dear Hack a Day,
Websites keep publishing poorly executed jokes today; how can I fix this?

We’ve been getting a lot of questions on the tip line like the one above, so we put together this one-step illustrated how-to. If you’re not the physical labor type, you can use [Steve Lambert]’s SelfControl.

[Related: Hack a Day goes autonomous, Craft a Day]

We use the Bus Pirate to interface a new chip without writing code or designing a PCB. Based on your feedback, and our experience using the original Bus Pirate to demonstrate various parts, we updated the design with new features and cheaper components.

There’s also a firmware update for both Bus Pirate hardware versions, with bug fixes, and a PC AT keyboard decoder. Check out the new Hack a Day Bus Pirate page, and browse the Bus Pirate source code in our Google code SVN repository.

We cover the design updates and interface a digital to analog converter below.

Concept overview

The Bus Pirate started as a collection of code fragments we used to test new chips without endless compile-program-run development cycles. We released it in a how-to and used it to demonstrate a bunch of serial interface ICs in our parts posts. This article introduces an updated design with new features and a bunch of improvements.

• Surface mount design
• Pull-up resistors on all bus lines with external voltage source
• Software resettable 3.3volt and 5volt power supplies
• Voltage monitoring of all power supplies
• An external voltage measurement probe
• Cheaper parts

Hardware

Click for a full size schematic image (PNG). The circuit and PCB are designed using the freeware version of Cadsoft Eagle. All the files for this project are included in the project archive linked at the end of the article.

Microcontroller

We used a Microchip PIC24FJ64GA002 28pin SOIC microcontroller (IC1) in this project. The power pins have 0.1uF bypass capacitors to ground (C1,2). The 2.5volt internal regulator requires a 10uF tantalum capacitor (C20). The chip is programmed through a five pin header (ICSP). A 2K pull-up resistor (R1) is required for the MCLR function on pin 1. Read more about this chip in our PIC24F introduction.

RS-232 transceiver

An inexpensive MAX3232CSE RS232 transceiver (IC2) interfaces the PIC to a PC serial port. This chip replaces the expensive through-hole MAX3223EEPP+ used in the previous version of the Bus Pirate. The serial interface will work with a USB->serial adapter.

Bus pull-up resistors

The original Bus Pirate has 3.3volt pull-up resistors on 2 pins, but most of our tests required additional external resistors. The updated design has pull-up resistors (R20-23) on the three main bus signals (data in, data out, clock) and the chip select (CS) pin.

A row of jumpers (SV5) connects each resistor to an external voltage supplied through the Vext terminal (X4). Through-hole resistors are used like jumper-wires to make the PCB easier to etch at home.

We couldn’t find an elegant way to control an arbitrary voltage pull-up resistor array from a 3.3volt microcontroller. If you have any ideas, please share them in the comments.

Power supply

VR1 is a 3.3volt supply for the microcontroller and RS232 transceiver. VR2 is a 5volt supply. Both require two 0.1uF bypass capacitors (C3-C6). J1 is a power supply jack for a common 2.1mm DC barrel plug. 7-10volts DC is probably the ideal power supply range.

The original Bus Pirate had dual power supplies, 3.3volts and 5volts, so most ICs could be interfaced without an additional power supply. A major annoyance was the lack of a power reset for connected chips. If a misconfigured IC needed to be power-cycled, we had to disconnect a wire. We got so tired of this routine that we added a software controlled reset to the updated design.

VR3 (3.3volts) and VR4 (5volts) are TI TPS796XX voltage regulators with an enable switch. A high level on pin 1 enables the regulator. A pull-down resistor (R13,R12) ensures that the regulators are off when the PIC isn’t actively driving the line, such as during power-up initialization. The datasheet specifies a hefty capacitor on the input (C23, C21) and output (C24, C22) pins, we used the same 10uF tantalum we use everywhere. An additional, optional, 0.1uF capacitor (C12,C11) can improve regulation.

The switchable regulators are powered by VR2, a 5volt supply.  We did this because the maximum input for VR3 and VR4 is 6volts, leaving the device with a narrow 5.2-6volt power supply range. VR2 will work well above 10volts, and provides an adequate supply for the other regulators.

VR3 (3.3volts) has plenty of headroom to operate from a 5volt supply. VR4 (5volts) will lose about 0.2volts, but 4.8volts remains well within the acceptable range for most 5volt chips. In practice, and under light loads, we see less than 0.1volts drop-out from VR4.

Voltage monitoring

Voltage monitoring is a new feature we’re really excited about. Has your project ever mysteriously stopped responding because of an accidental short circuit? The Bus Pirate’s power supplies are equipped with voltage monitoring that can detect a change in power levels.

Each monitored signal is connected to an analog to digital converter (ADC) through a resistor voltage divider. Two 10K resistors (R10,R11 above) divide the input voltage in half, making it possible to measure up to 6.6volts with the 3.3volt PIC microcontroller.

The Bus Pirate has four voltage monitors. The 3.3volt and 5volt power supplies are monitored, as is the external voltage fed to the pull-up resistors. A fourth monitor is connected to pin 9 of the output header to make a voltage probe.

PCB

Click for a full size placement diagram (PNG). The board is a quasi single-sided design, we etched ours in the lab on a single-sided photo-resist PCB. At the top, near C13, two jumper wires meet at a single via; we soldered one jumper wire to the other on the back of the board.

Part list

Firmware

The firmware is written in C using the free demonstration version of the PIC C30 compiler. Learn all about working with this PIC in our introduction to the PIC 24F series.

The latest firmware is posted on the Hack a Day Bus Pirate page. The latest source is in our Google Code SVN repository.

Using it

The diagram above shows the Bus Pirate pinout.

We made a cable with alligator clips on the end, and added labels to each wire so we don’t have to refer to this table every time we interface a new chip.

If you know of any cool connectors or cables, please link to them in the comments.

LTC2640 SPI digital to analog voltage converter

The Linear Technology LTC2640-LZ8 is an 8bit digital to analog converter (DAC) programmed over SPI. A DAC is essentially a programmable voltage divider. They’re useful for recreating waveforms, such as audio signals. An 8bit DAC has 255 even intervals between 0 and the reference voltage, the L part we used has an internal 2.5volt reference.

The LTC2640 only comes in a small SOT223-8 package, so we made a breadboard adapter in the profile of a DIP-8 chip.  Our LTC2640 footprint is included in the project archive attached at the end of this article.

The schematic above shows our test circuit for the LTC2640. It requires a 2.7-5volt power supply, we used the Bus Pirate’s 3.3volt supply. C1 is a bypass capacitor between the power pin and ground. Pin 8 is an active-low reset pin, tie it high for normal operation. Pin 7 is the DAC output, connect the Bus Pirate voltage measurement probe (ADC) here.

We connected the Bus Pirate to the LTC2640 as shown in the table. The LTC2640 doesn’t have a data output pin, this SPI connection remains unused.

The Bus Pirate’s hardware SPI library and software RAW3WIRE library are compatible with the LTC2640’s SPI interface. We used the SPI library; if you use the RAW3WIRE library be sure to choose normal pin output.

HiZ>m<–select mode
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. JTAG
7. RAW2WIRE
8. RAW3WIRE
9. PC AT KEYBOARD
MODE>5<–SPI or RAW3WIRE
900 MODE SET
Set speed:
1. 30KHz
2. 125KHz
3. 250KHz
4. 1MHz
SPEED>1 <–test at low speed
…
102 SPI READY
SPI>

Press M for the Bus Pirate mode menu, choose 5 for SPI mode. There are a bunch of configuration options for the SPI module, use the default options for all of them. After SPI mode is ready we need to configure the power supply.

SPI>p<–power supply setup
W/w toggles 3.3volt supply?
1. NO
2. YES
MODE>2<–use 3.3volt supply
W/w toggles 5volt supply?
1. NO
2. YES
MODE>1<–don’t use 5volt supply
9xx SUPPLY CONFIGURED, USE W/w TO TOGGLE
9xx VOLTAGE MONITOR: 5V: 0.0 | 3.3V: 0.0 | VPULLUP: 0.0 |
SPI>

p opens the Bus Pirate power supply menu. We use the 3.3volt supply but not the 5volt supply. The voltage monitor verifies that the power supplies are off.

SPI>W<–capital W (silly CSS) enables power supply
9xx 3.3VOLT SUPPLY ON
SPI>v<–voltage monitor
9xx VOLTAGE MONITOR: 5V: 0.0 | 3.3V: 3.3 | VPULLUP: 0.0 |
SPI>

Capital ‘W’ enables any power supplies selected in the previous menu, a small ‘w’ disables them. V displays the supply voltage monitor, which now shows 3.3volts output from the 3.3volt supply.

Now that configuration is finished, we can send commands to the LTC2640 over the SPI bus. The LTC2640 has a 24bit (3byte) interface protocol. The first byte is a command, followed by two data bytes. The LTC2640 is available in 8,10, and 12bit versions; the 8bit version uses the first byte to set the DAC value, and ignores the second byte.

SPI>[0b00110000 255 0]<–set DAC to full
110 SPI CS ENABLED
120 SPI WRITE: 0×30<–write DAC command
120 SPI WRITE: 0xFF<–DAC value
120 SPI WRITE: 0×00<–don’t care
140 CS DISABLED
SPI>

Every SPI command begins by enabling the chip select pin ([). The first byte is the command to update the DAC (0b00110000), followed by the value to output (255), and a third byte that's ignored (0). The command ends by disabling chip select (]).

We used an 8bit DAC with 255 even voltage steps, output set to 255 is 100%. We can use the Bus Pirate voltage probe to measure the output.

SPI>d<–measure voltage
9xx VOLTAGE PROBE: 2.5VOLTS<–DAC output
SPI>

D triggers a voltage measurement. The DAC output voltage is 100% (255/255) of the internal reference, 2.5volts.

SPI>[0b00110000 0 0] d
110 SPI CS ENABLED
120 SPI WRITE: 0×30<–write DAC command
120 SPI WRITE: 0×00<–DAC value
120 SPI WRITE: 0×00<–don’t care
140 CS DISABLED
9xx VOLTAGE PROBE: 0.0VOLTS<–DAC output
SPI>

The same command with a DAC value of 0 outputs 0% (0/255) of 2.5volts; 0volts.

SPI>[0b00110000 128 0] d
110 SPI CS ENABLED
120 SPI WRITE: 0×30<–write DAC command
120 SPI WRITE: 0×80<–DAC value
120 SPI WRITE: 0×00<–don’t care
140 CS DISABLED
9xx VOLTAGE PROBE: 1.2VOLTS<–DAC output
SPI>

A DAC value of 128 is about 50% (128/255) of the reference voltage, 1.2volts.

SPI>[0b01000000 0 0] d
110 SPI CS ENABLED
120 SPI WRITE: 0×40<–power down command
120 SPI WRITE: 0×00<–don’t care
120 SPI WRITE: 0×00<–don’t care
140 CS DISABLED
9xx VOLTAGE PROBE: 0.0VOLTS<–DAC off
SPI>

The LTC2640 has a low power mode, triggered by the command 0b01000000 and two bytes that are ignored. After the power down command we can verify that there’s output from the DAC. Write any DAC value to exit low power mode.

Taking it further

What’s the next step for the Bus Pirate? We’ll eventually make a final update to the design that includes USB on a professionally made, double-sided PCB. Power supply indicator LEDs were slated for this version, but didn’t get included. It would also be handy to have an AT  keyboard connector for debugging without a PC. Check out the roadmap and wishlists on the Hack a Day Bus Pirate page.

Download: buspirate.v1a.zip

Cadsoft Eagle is a multi-platform freeware circuit layout program. Lots of open source hardware is designed in Eagle, and it’s become a hobbyist favorite. We use it for all of our hardware designs.

There are several ways to turn an Eagle design into an actual printed circuit board (PCB). We’ll show you how to save Eagle designs as industry-standard gerber files that are accepted by any PCB manufacturer. You can use the gerbers to order a single prototype, or a full panel.

Introduction

Toner transfer is the beginners’ favorite way to make a PCB because the investment in materials is minimal. We’ve covered toner transfer before. Most PCBs in our how-tos are made with the photo-resist process.  The photo process makes nice boards, but requires a bit of equipment; sensitized boards, developer, and an ultra-violet light source.

Some board manufacturers, like Olimex, make PCBs directly from Eagle .brd files. Most require a minimum order of one eurocard-sized PCB (100mmx160mm). Good if you need a few boards, expensive for a single experimental prototype.

The cheapest option is to submit gerber files like the professionals. Any PCB manufacturer will accept gerber formatted design files. Gold Pheonix sells 155square inches of PCB panel for $110. If you’re looking for something smaller, services like BatchPCB and PCB-Pool combine small orders and submit them as a full panel. Either way, you’ll submit gerber files to the board house. This is the process we describe.

Process overview

• Prepare the design.
• Create gerbers, generic files accepted by any PCB fab house.
• Verify that the gerbers are correct.
• Send the design for production.

Prepare the design

We’re going to walk you through the process of preparing our digital picture frame PCB for production. This design requires a double-sided board with fairly small traces.

Download the project archive (ZIP) from last week. Open the .brd file with the freeware version of Cadsoft Eagle.

The ground fill is empty when the file opens. Press the ratsnest button (or Tools->Ratsnest) to fill in the empty polygons.

Board manufacturers publish specifications outlining their production capabilities, such as the smallest possible traces, spacing, and drill size. BatchPCB has 8mil minimum traces and spacing, and 20mil minimum holes.

Don’t torture the manufacturer. Just because they advertise 8mils, doesn’t mean it’s safe to make every trace 8mils. Slightly larger-than-minimum tolerances will reduce manufacturing errors. The digital picture frame has 8mil traces around the tiny LCD connector, shown above. The traces are 8mils only until there’s enough clearance to use 10mil traces.

Use Eagle’s design rule check to make sure your board doesn’t exceed the manufacturer’s production abilities. Download the SparkFun design rules (DRU) for BatchPCB, or the Olimex 8mil (DRU) or 10mil (DRU) design rules.  Click the DRC icon (or, Tools->DRC) and load the design rule file. Eagle analyzes the design and highlights any areas that violate the design rule parameters.

Correct any errors. Here, the spacing between traces is too close. Sometimes the spacing on a part footprint is too small to be manufactured. Sparkfun’s default footprint for the  Nokia LCD connector had pad spacing less than 8mils. We edited the part library to make the pads smaller, and the separation larger.

It’s helpful to include part numbers on the printed silkscreen layer. BatchPCB prints a silkscreen on both sides. Be sure to see what your board house offers, some charge extra. Use the smash tool to unlink obscured labels, then move them to a better location.

Create gerber files

Gerber files are the PDFs of PCBs. Gerber files describe a PCB exactly as it should appear, agnostic of the display hardware. It’s a final production format that isn’t intended to be edited. We created our gerber files in Eagle using the procedure outlined in SparkFun’s Eagle tutorial.

The Eagle CAM processor writes gerber files, open it from the menu under File->CAM processor.

SparkFun has a script (CAM) that configures the CAM processor to make gerber files. Load the CAM script using File->Open->Job…

By default, SparkFun’s silkscreen configuration only includes the place layer. Our parts usually have labels on the names and docu layers, activate these layers on the top and bottom silkscreen tabs to add them to the output.

Click Process Job to create the gerber files.

The CAM processor creates seven files that we need.

• Top and bottom copper (.GTL, .GBL)
• Top and bottom solder mask (.GTS, .GBS)
• Top and bottom silkscreen (.GTO, .GBO)
• Drill file, 2.4 leading (.TXT)

Verify that the gerbers are correct

Verify the CAM output in a gerber viewer to make sure everything was positioned correctly. We followed SparkFun’s suggestion and used Viewplot.

Load the seven files with Viewplot. Be sure to specify the drill file type as 2.4 leading.

Check for errant vias, mirrored layers, and alignment. We’ve noticed that text added to the silkscreen layer is usually bigger than it was in Eagle. Correct any problems and run the CAM processor again.

When everything looks good, the board is ready for production.

Send the design for production

Zip the seven gerber files and submit them to the PCB fab house. Remember to tell them that the drill file format is 2.4 leading.

BatchPCB is a pooled panel service that sells space by the square inch. Other manufacturers and batch services require you to order at least a full eurocard. We use BatchPCB for prototyping because we never need the extra board space of a full eurocard, and we don’t mind the average 20day wait.

At BatchPCB, $2.50/square inch buys a PCB with silkscreen on both sides, unlimited vias, and a huge range of drill sizes; stuff that usually costs extra. BatchPCB’s minimum traces, spacing, and drill are similar to other prototyping services. There’s a $10 per order setup fee, but an order can include multiple designs. Shipping, even internationally, isn’t outrageous.

If you need a lot of the same board, look at Gold Phoenix. They manufacture boards for BatchPCB. A 100 square inch panel is $100, a 155 square inch panel is $110.

Create an account at BatchPCB. Click upload to add a new design. Name the design and upload the zip archive containing the 7 gerber files.

Verify that the gerber layers were successfully detected.

Verify that the correct size was detected.

The BatchPCB rule check ‘robot’ will verify that your design meets production standards, and send an e-mail in a few minutes. Since we ran our own rule check prior to sending the design, we can expect that everything will be fine. Click continue and you’ll have the option to order the board. For more help, see the BatchPCB help and support forum.

Receive your boards

Boards arrive from BatchPCB in about 20 days. Check the boards for obvious errors before soldering. Some manufacturers test PCBs, BatchPCB doesn’t. We’ve ordered PCBs from two of the popular hobbyist board houses, Olimex and BatchPCB, and all the boards have been satisfactory.

Taking it further

It’s easy to order professional PCBs using gerber files. Why not build that awesome DIY project you’ve been putting off?

What has been your experience with PCB fab houses?

There are a ton of digital picture frame tutorials out there. Most are old laptops with crafty case reconfigurations that fit a photo frame profile.

We set out to build a 100% DIY, scratch-built digital picture frame. Our frame has a 12bit color LCD, gigabytes of storage on common, FAT-formatted microSD cards, and you can build it at home. We’ve got the details below.

Concept overview

The bitmap images are stored on common, PC-readable microSD cards. A PIC microcontroller reads the images over a three wire SPI bus. The PIC processes the image data and writes it to a color LCD over a unidirectional, 9bit SPI-like bus. A configuration file on the SD card defines the delay between images.

Hardware

Click for a full size schematic image (PNG). The circuit and PCB are designed using the freeware version of Cadsoft Eagle. All the files for this project are included in the project archive linked at the end of the article.

Microcontroller

We used a Microchip PIC24FJ64GA002 28pin SOIC microcontroller (IC1) in this project. We really like this chip because the peripheral pin select feature lets us put important features on the pins we want; this gives a smaller, simpler, more compact PCB. Each power pin has a 0.1uF bypass capacitor to ground (C1,2). The internal 2.5volt regulator requires a 10uF tantalum capacitor (C12). The chip is programmed through a five pin header, SV1. R1 is a pull-up resistor for the MCLR function on pin 1. Read more about this chip in our PIC24F introduction.

A 32.768kHz crystal (Q1) and two 27pF capacitors (C10,11) provide an oscillator for the real-time clock calendar (RTCC). These parts are optional, the initial firmware doesn’t use them. The RTCC could be used as part of a function that superimposes the current time on the screen. Buttons connected to the programming header could be used to set the time.

SD card

MicroSD cards are completely compatible with regular SD cards, microSD cards can be used in an SD card reader/writer with an adapter. We tested several microSD card holders, and settled on one from SparkFun Electronics. The microSD card requires a bypass capacitor between the power pin and ground (C3). An LED indicates microSD read activity, but its also useful for general debugging (LED1, R2).

Color LCD 128×128 Nokia knock-off

This project is designed around SparkFun’s $20 color LCD panel. The LCD logic runs at 3.3volts and requires a decoupling capacitor (C4). The LED backlight requires a separate 7volt supply, and appears to have an internal current limiter because example designs don’t use external resistors.

The LCD has a separate input for the 3.3volt display supply. Many report noise in the display if this voltage isn’t clean. We used a ferrite bead (L1) and 0.1uF capacitor (C5) to filter the supply, and haven’t experienced any problems. This even worked on a dirty home-etched prototype. The ferrite bead type isn’t important, we used one left over from our tiny web server project.

The small connector is easy to solder on a professional board with a solder mask, but buy several as insurance. SparkFun has a PCB footprint for this part in their Eagle parts library, but the spacing between the pads is smaller than Olimex or BatchPCB will manufacture. We fudged it by decreasing the pad size to get more space between.  Don’t depend on the connector to hold the LCD in place, use tape to hold it down. We used sticky-tack to attach the LCD temporarily.

We prototyped an LCD carrier board prior to sending the final design for manufacture. We recommend against using a ground fill under the connector without a solder mask.

Power supply

A 3.3volt supply, provided by an LD1117S33 (IC2), powers the PIC, microSD card, LCD logic, and LCD display. IC2 requires a 0.1uF bypass capacitor (C6) on the supply side, and a 10uF capacitor (C13) on the output. We used the same tantalum capacitor that we used for the PIC internal regulator.

The LCD backlight is powered by an LM317 adjustable regulator (IC3) configured to 7volts with 240 (R5) and 1100 (R6) ohm resistors. C7 and C8 are 0.1uF bypass capacitors for the LM317.

J1 is a SMD power jack for a common 2.1mm DC barrel plug. C11 is a 10uF electrolytic capacitor that smooths any lag in the supply voltage. C11 has a maximum 16volt input rating, so the supply voltage is best kept under 12volts. 9-12 volts is probably the idea power supply range.

PCB

Click for a full size placement diagram (PNG). L1, C5, and the LCD are on the opposite side. We can’t prototype two-sided boards in mom’s basement, so we sent this design to BatchPCB. Next week we’ll show you how we did it.

Partslist

Firmware

The firmware is written in C using the free demonstration version of the PIC C30 compiler. Learn all about working with this PIC in our introduction to the PIC 24F series. The firmware is included in the project archive at the end of the article.

FAT12/16/32 disk library

Microchip’s FAT 12/16/32 library gives us easy access to files stored on SD cards. We gave a detailed description of this library in our web server on a business card project. If you’re having trouble reading a card with the library, check that it was formatted in a digital camera or using Panasonic’s SD card formatter.

Nokia 6100 LCD driver

SparkFun has a basic 8bit color driver (ZIP) for the Nokia 6100. We ported it to the PIC, and updated it for the 2byte-per-pixel 12bit color mode. With a small amount of added complexity, the pixel write rate could easily be increased by using a different 12bit mode that delivers two pixels using 3 bytes.

The LCD uses a 9bit protocol, one bit more than most SPI hardware will handle. The first bit tells the LCD whether the next 8bits are data or a command. On the PIC 24F it’s impossible to manually bang in the first bit, and then use the SPI peripheral to send the remaining 8bits. We lose direct control of the pins when hardware SPI is enabled. The data entry has to be completely bit-banged, which dramatically reduces the screen refresh rate.

Reading Bitmaps

There are a ton of bitmap formats.  Windows compatibility keeps everyone using the ancient Windows v3 format. We created two C structs to read the V3 bitmap data.

Bitmap files start with a 14byte file header. The first two bytes are the letters ‘BM’, indicating a bitmap.  If the first two bytes are correct, the firmware loads the information header. The last four bytes indicate the beginning of bitmap data, but the current firmware just assumes it will begin at the end of the headers.

A Windows V3 bitmap information header is 40bytes long. The firmware verifies that the header length (offset 14) is 40, indicating a V3 bitmap. If the width (132), height (132), color depth (24), and compression (0) all check out, the image data is processed and output to the screen.

Bitmap images have uncompressed, 1:1 representations of pixel data stored in three byte sequences.  The data starts at the lower right-hand corner of the image; first the red value, then green and blue. Wikipedia has a complete bitmap walk through.

If the color depth of a bitmap image (24bits) is greater than the LCD can display (12bits), we need to discard the least significant bits of color data. To convert from 24bit color to 12bit color, we just chuck half the color data; an 8bit value of 11110011 is pushed four bits to the right, giving 1111.

Firmware walk-through

1. Init PIC, SD, LCD.
2. Read config.ini, create if it does not exist.
3. Use first character of config.ini to set between image delay.
4. Look for images, open next image.
5. Read and check bitmap file header for proper format.
6. Read and check bitmap information header for version, size, color.
7. Read and display each pixel value. Adjust bit depth as needed.
8. Delay, then repeat from 4.

Preparing images

To keep this demo simple, the photo frame only displays the most common bitmap format. Images must be sized to 132×132pixels, with 24bit color.

1. Open a picture with an image editing program.
2. Draw a square selection box over the part of the image you want to use, usually using shift and drag.
3. Crop the image.
4. Size the image to 132×132pixels.
5. Save the image as a windows bitmap, 24bits of color depth.

Other image sizes and formats could be supported with a firmware upgrade (PNG, JPG), especially with a pin-compatible microcontroller upgrade to a giant dsPIC 33F.

Using it

Put images in the root directory of a FAT formatted SD card. Depending on the last device to format the card, it might need to be formatted with a digital camera or the Panasonic SD formatter.

Optional: make a config.ini file with a text editor. Enter a single digit, from 0-9, to set the between picture delay. Save the file. If you don’t create your own config.ini file, one will be created for you with a 1 second delay.

Put the card in the socket, and plug in the digital picture frame. Images will cycle on the screen with the defined delay.

Taking it further

We see a lot of potential in this simple digital picture frame. Many features can be added with a firmware upgrade, some are the basis for future hardware.

• Display other image formats, scale images
• Random fades and wipes
• Display time and date over image, set with buttons connected to programming pins
• Extend the configuration options in config.ini to include longer delays, fade or wipe type
• Use a sub directory for images because there are some file limitations to the root directory of a FAT formatted SD card.
• Add an ethernet connection for networked display updates.

Download: dpf.v1.zip

Complex programmable logic devices (CPLDs) contain the building blocks for hundreds of 7400-serries logic ICs. Complete circuits can be designed on a PC and then uploaded to a CPLD for instant implementation. A microcontroller connected to a CPLD is like a microcontroller paired with a reprogrammable circuit board and a fully stocked electronics store.

At first we weren’t sure of the wide appeal and application of CPLDs in hobbyist projects, but we’ve been convinced. A custom logic device can eliminate days of reading datasheets, finding the ideal logic IC combination, and then waiting for chips to arrive. Circuit boards are simpler with CPLDs because a single chip with programmable pin placement can replace 100s of individual logic ICs. Circuit mistakes can be corrected by uploading a new design, rather than etching and stuffing a new circuit board. CPLDs are fast, with reaction times starting at 100MHz. Despite their extreme versatility, CPLDs are a mature technology with chips starting at $1.

We’ve got a home-etchable, self programming development board to get you started. Don’t worry, this board has a serial port interface for working with the CPLD, and doesn’t require a separate (usually parallel port) JTAG programmer.

Intro to CPLDs

When to use a CPLD

Consider using a CPLD when a design calls for more than one 7400 series logic ICs. A CPLD will be cheaper, faster, and can be programmed with your ideal pin-out configuration for simpler PCBs.

Use a CPLD in tricky designs that might require several iterations. It’s easier to design a new circuit in software and upload it to the CPLD than it is to design, etch, and stuff a new circuit board.

For maximum speed and instant response, choose a CPLD. The difference in speed is amazing; CPLDs start at a 100MHz, while microcontrollers respond to interrupts at a few MHz. CPLD designs form circuits that react to external stimulus, reactions occur almost instantaneously. A microcontroller executes code to react to events, even interrupt routines have comparatively high latency.

CPLD vs FPGA

FPGAs are better known than CPLDs, but they share many characteristics. This analogy isn’t perfect, but we like it: where FPGAs are a reprogrammable processor core, a CPLD is a reprogrammable circuit board or breadboard. FPGAs replace microcontrollers, memory, and other components. CPLDs absorb logic ICs, and work well with a microcontroller.

Manufacturers

Altera and Xilinx, the biggest CPLD manufacturers, are better known for their FPGAs. Lattice Semiconductor is another large CPLD manufacturer with less community following. Atmel makes pin-compatible versions of old industry-standard CPLDs.

If you plan to work at 5volts, your options are limited. Xilinx XC9500 CPLDs are still available as new old stock, but cost four times more than newer 3.3volt equivalents. Atmel’s ATF1502 series works at 5volts, but they don’t offer a free development environment.

At 3.3volts there’s more options, but new CPLDs increasingly have a core that runs at 2.5volts, 1.8volts, or lower. The Altera MAXII and the Xilinx XC9500XL series are probably the most popular 3.3volt CPLDs. Xilinx also makes the CoolrunnerII CPLD, but it only comes in a TQFP package and requires a separate 1.8volt supply for the core.

Packages

Most manufacturers offer one or two CPLDs in a hobbyist friendly PLCC 44 package, though this is starting to disappear. PLCC is an SOIC-sized surface mount chip with pins on all four sides. PLCC44 sockets are commonly available in through-hole and SMD versions. Unfortunately, newer CPLD families are starting to eliminate the PLCC package and offer only 44 pin and larger TQFP chips, such as Xilinx’s CoolrunnerII.

Development environments

Most manufacturers offer a free development environment that supports design entry using simple schematics, as well as Verilog or VHDL. Many won’t support the latest FPGAs in the free version, but we only need the CPLD parts anyway. Altera has Quartus, Xilinx has ISE, and Lattice has ispLever. Atmel has ProChip Designer for the ATF15xx series, but they only offer a 6month trial license — which they wouldn’t actually give us.

Programmers

The development board we present doesn’t need a separate JTAG programmer because the PIC microcontroller already programs the CPLD.  If you want an external programmer, the cheapest are the parallel port programmers: Parallel Cable III for Xilinx and BytleBlaster for Altera. Inexpensive clones, and schematics, are available at SparkFun.  The OpenOCD is a generic USB JTAG programmer that will work with many CPLDs, FPGAs, and ARMs.

Our choice

We eventually settled on the Xilinx XC9500XL series because it had a cheap development kit we could use to test our JTAG programmer prior to implementing an entire design.

The DO-CPLD-DK from Digilent includes a XC9572XL, a CoolrunnerII, and parallel port programmer. Nu Horizons has some old non-ROHS models for $40, but due to sloppy variable type handling in their credit card processing scripts, we couldn’t complete an order online. We tried to do it over the phone but they refused to take such a small order on the phone, even during a website malfunction. In the end, it was cheaper to pay full price at Digikey (#122-1512-ND) after including New Horizon’s exorbitant shipping charges. We wouldn’t normally mention this, but with only two places to buy the board it’s probably worth noting our experience.

CPLD development board

Click here for a full size schematic image (PNG). The circuit and PCB are designed using the freeware version of Cadsoft Eagle. All the files for this project are included in the project archive linked at the end of the article.

Circuit

A PIC 24FJ64GA002 microcontroller (IC1) provides the user and programming interface to the CPLD. We use this $4 PIC in a lot of projects because the peripheral pin select feature makes board routing really easy. Check out our introduction to the PIC24F for more details. The PIC needs to communicate with a PC serial port, so we added an inexpensive MAX3232 RS232 transceiver. The serial interface should work with a USB->serial adapter.

Our choice of CPLD (IC3), a Xilinx XC9572XL (PDF), is connected between the PIC and several other components. We can create an endless variety of circuitry between the PIC and other chips using the reprogrammable logic inside the CPLD. The PIC will program the CPLD with code sent from a PC serial port, but we still brought the JTAG pins to a header for easy external debugging.

A DS1085 digital programmable oscillator (IC4) generates clock frequencies between 8KHz and 133MHz, at 10KHz increments. This is very similar to the DS1077 we covered earlier, but it has even steps between all frequencies. The DS1085 requires a 5volt supply (VR2). The I2C interface also runs at 5volts, so we connected it to 5volt tolerant PIC pins. It’s possible to use the 3.3volt 66MHz 1085L instead, and remove the 5volt supply.

We used a cheap 3.3volt SOT223 voltage regulator (VR1) to power most of the circuit.  The 5volt supply (VR2) can be excluded if you use a slower 1085L 3.3volt oscillator.

CPLDs are commonly used as a memory controller, so we included 32K of SRAM (IC5) on the development board. A 3.3volt latch with 5volt tolerant inputs interface the memory inputs to a wide range of external voltages (IC6). The latch inputs are held low with a 1Mohm resistor network (RN1). We’ll discuss this section extensively in an upcoming article.

PCB

The board is a quasi one-sided design. We made several compromises so we could prototype this highly experimental PCB ourselves. We present the board ‘as is’ for other die-hards that might want to etch this board at home. If you send the PCB to a board house, try to correct these issues prior to producing a ‘real’ double-sided board.

One power pin of the CPLD is missing a decoupling capacitor entirely; there was no way to put a capacitor in that area. One CPLD decoupling capacitor, and the SRAM decoupling capacitor, are through-hole parts. Using these through-hole parts eliminated a few jumper wires.

The jumper wires on the back of the board are optimized for single-sided production, rather than good design practices. We faked a double-sided board by soldering the power bus on the back. A real double-sided board design should route the power bus to avoid crossing signal paths, and include the missing decoupling capacitors.

We used an surface mount PLCC chip socket, but a through-hole version is definitely a better idea. We though the SMD version would be easy to solder, but it turned out to be a nightmare. We really wanted the CPLD to be on the front of the board for the coolest possible presentation. A proper two-sided board with plated through-holes can have a through-hole socket on the front, but this wasn’t possible with our 1-sided prototype board.

Parts list

Click here for a full size placement diagram (PNG).

Firmware

The firmware is written in C using the free demonstration version of the PIC C30 compiler. Learn all about working with this PIC in our introduction to the PIC 24F series. The firmware is included in the project archive at the end of the article.

We wanted a super easy way to interact with the hardware on the board without endless compile-program-test cycles. We made a custom version of the Bus Pirate firmware that  provides a simple ASCII terminal interface to the DS1085 clock chip (I2C), the CPLD programing interface (JTAG), and a 3 wire (SPI) interface to the CPLD. Check out the Bus Pirate tutorial for background on the simple syntax used with the firmware.

The original Bus Pirate firmware handles several protocols that share the same pins. For the CPLD version, we changed the pin assignments to fit the connections on the development board. We also removed unused modules and options.

CPLD blinky LED examples

We prepared several designs in Xilinx’s ISE development environment. The schematics, pin placement files, and compiled designs (XSVF) are included in the project archive linked at the end of the article.  A full explanation of ISE is beyond the scope of this article; we found the help files sufficiently useful to make these examples.

The first design simply lights the LED connected to pin 8 of the CPLD.

Prepare the XSVF file

XSVF is a compressed JTAG programming format, as described by Xilinx in this application note (PDF). XSVF isn’t limited to programming Xilinx devices, and can be prepared for any chip that provides a common BSDL JTAG definition file.

Open the iMPACT programming tool from the ISE Design Suite project panel under Configure target device->iMPACT.

• Choose the option to create a boundary scan file,  and set the type to XSVF.
• Give the XSVF output a file name and then add a compiled CPLD image (ex1.jed) when prompted to add a device.
• You should see a JTAG chain that contains a single device.

Click on the device and choose program; iMPACT will record the programming sequences to an XSVF file.

With XSVF file in hand, it’s time to open up a terminal and program the CPLD. We like Tera Term and Hercules on Windows. You must enable XON/XOFF flow control in the client to use the JTAG interface. The default PC side setting for the development board terminal is 115200bps, 8N1.

HiZ>m <–select mode
1. HiZ
2. I2C
3. JTAG
4. RAW3WIRE
MODE>3 <–JTAG
900 MODE SET
602 JTAG READY
JTAG>(2) <–probe JTAG chain macro
xxx JTAG INIT CHAIN
xxx JTAGSM: RESET
xxx JTAGSM: RESET->IDLE
xxx JTAGSM: IDLE->Instruction Register (DELAYED ONE BIT FOR TMS)
xxx JTAGSM: IR->IDLE
xxx JTAGSM: IDLE->Data Register
xxx JTAGSM: DR->IDLE
xxx JTAGSM: RESET
xxx JTAGSM: RESET->IDLE
xxx JTAGSM: IDLE->Data Register
xxx JTAG CHAIN REPORT:
0×01 DEVICE(S)
#0×01 : 0xC9 0×02 0×06 0×9A <–XC9572XL responds
xxx JTAGSM: DR->IDLE
JTAG>

In the terminal we enter the mode menu (m), and choose JTAG (3). Macro 2 probes the JTAG chain, in our case this is just the CPLD.  The chain report tells us that the chip is connected and responding. Read more about the JTAG interface.

Now we can run the XSVF programmer, macro (3), and upload the XSVF file from the terminal in binary mode. The first example just lights the LED on pin 8. If the LED lights, we can verify that programming was successful. If your LED doesn’t light, don’t despair; sometimes the JTAG programmer sticks and a reset macro (1) will get the chip going.

LED at full brightness.

74LS32/4071 OR gate, blink at half rate (/2)

A major component of the CPLD development board is the 1085(L) frequency synthesizer connected to pin 7 of the CPLD. The next example uses a logic OR gate, like a 74LS32 or 4071 IC, to blink the LED whenever the clock signal is high. At even the slowest clock rate the blinking will be too fast to see, but we should get a nice PWM dimming effect compared to the first example.

JTAG>m <–select mode
1. HiZ
2. I2C
3. JTAG
4. RAW3WIRE
MODE>2 <–I2C interface to DS1085
900 MODE SET
202 I2C READY
I2C>(1) <–address search macro
xxx Searching 7bit I2C address space.
Found devices at:
0xB0 0xB1 <–found the DS1085 address
I2C>

Program the CPLD as before, and then switch to I2C mode to access the DS1085 clock. We could look up the device address in the datasheet, but we save a few seconds by running the address search macro; the report tells us the chip answers to 0xb0 (write) and 0xb1 (read).

I2C>{0xb0 0×02 0b00011111 0b10000000}<–max prescaler
210 I2C START CONDITION
220 I2C WRITE: 0xB0 GOT ACK: YES
220 I2C WRITE: 0×02 GOT ACK: YES
220 I2C WRITE: 0×1F GOT ACK: YES
220 I2C WRITE: 0×80 GOT ACK: YES
240 I2C STOP CONDITION
I2C>{0xb0 1 0b11111111 0b11000000}<–max divider
210 I2C START CONDITION
220 I2C WRITE: 0xB0 GOT ACK: YES
220 I2C WRITE: 0×01 GOT ACK: YES
220 I2C WRITE: 0xFF GOT ACK: YES
220 I2C WRITE: 0xC0 GOT ACK: YES
240 I2C STOP CONDITION
I2C>

The DS1085 is almost exactly like the DS1077 we covered earlier, but has a DAC controlled oscillator for even steps between all frequencies. We programmed the clock to the slowest frequency using the commands shown above. The LED is dimmed by the pulse-width modulation effect of the clock signal.

LED at half brightness.

74F269 16bit synchronous counter, blink slowly (/65535)

We just programmed the CPLD with a logic OR gate similar to a 74LS32. Now, we’re going to reprogram the chip with a 16bit counter like two cascaded 74F269s.  At $1.15 each, two 74F269 Ics are more expensive than the XC9572XL CPLD. A 16bit counter rolls over once per 65535 ticks, so a LED attached to the last bit will toggle once every 65535/2 ticks.

Now we can see the cool part of CPLDs. The CPLD is like a programmable breadboard; we just popped out the 74LS32 and put in a 74F269, without buying parts, reading datasheets, etching, wiring, etc. A microcontroller connected to a CPLD can reconfigure its own circuit board to fix errors, add features, or re-purpose it for entirely different applications.

We upload the new design as before, but now the clock is divided by 65535 and the LED toggles about once per second.

Taking it further
Next time we’ll look at discrete 7400-series logic chips, and implement a ton of them in the CPLD to make a high-speed bus sniffer and logic analyzer.

Download: bitclone.v1.zip

Our wallets are filling up with SIM and RFID cards that contain hidden information. Using our latest project, the Bus Pirate universal serial interface, we can dump the memory from many common smart cards. In today’s How-to, we show you how to interface common smart cards, and walk you through the data stored on a FedEx Kinko’s prepaid value card.

Background

The FedEx Kinko’s prepaid card is actually a SLE4442 smart card. There’s nothing secret about the SLE4442, it’s completely documented in the datasheet (PDF), and you can buy blank cards on the web.

The card is openly readable, we’ll be able to look at the contents without any sort of malicious intrusion. It’s protected from writes by a three byte password, with a ‘three strikes you’re out’ policy that renders the card useless after three failed password attempts.

Due to its wide-spread use, in Kinko’s and other capacities, the SLE4442 has been the target of several high-profile hacks.  At the ‘06 Toorcon, [bunnie] and [Chris Tarnovsky] hosted a discussion on the card. [Chris] examined the silicon die and suggested that shorting a trace might defeat the security measures. You can see high-resolution images of the die on his site. [Strom Carlson] went right to the source and snooped the password with a logic analyzer, as documented in his famous ‘06 Defcon presentation. The card even makes appearances in artwork.

We’re not planning on maliciously intruding on the card, but we can still look at the contents and demonstrate how to interface arbitrary protocols with our latest project, the Bus Pirate.

Connecting to the SLE4442

Grab the SLE4442 datasheet (PDF) if you haven’t already. The pinout is shown in the picture above. If you’re having trouble orienting the card, note that the large center pad connects to ground.

The card requires 5volts DC (datasheet page 27, table 3.2.2), we used the Bus Pirate’s handy 5volt supply. Interfacing at five volts is no problem because the Bus Pirate inputs are all 5volt tolerant.

A two-wire interface is used, with a clock line and bi-directional data line. We connected these to the Bus Pirate’s SDA and SCL pins. A third signal, reset, is required to initialize the chip; we used the Bus Pirate’s auxiliary output to control the reset line. The maximum clock frequency we can use to interface the device is 50kHz, with a 7kHz stated minimum (page 28, table 3.2.4:fCLK). The Bus Pirate’s raw 2 wire protocol runs at about 5kHz, but we didn’t have any problems interfacing the device.

The sle4442 has open collector outputs, and depends on pull-up resistors to hold the bus high. Instead of switching the data pin between ground and 5volts, it switches between ground and high-impedance states. High-impedance means that the chip exerts no state on the line, it lets it float, like a microcontroller input pin.

Each of the signal lines need to be pulled-up to 5volts with a 2K-10K resistor, the value isn’t particularly important.  Without the pull-up resistor, we’ll never see anything but 0 (ground) on the bus because the sle4442 doesn’t exert a voltage of it’s own. A benefit of this technique is that the Bus Pirate, which only switches at 3.3volts, will talk to the sle4442 at a full 5volts, in compliance with the 3.5volt minimum voltage for a high level (datasheet, page 27, table 3.2.3:Vih).

Initializing the card

Before we can read data from the card, we have to initialize it. This is done with a standard ISO 7816-3 Answer to Reset (ATR) command. After initialization, we can read from the card using a simple two wire protocol.

Setup raw 2 wire mode

The interface shares some characteristics with I2C, but it’s not compatible. We used the Bus Pirate’s raw 2 wire bus mode to interface the device.

RAW2>m
1. SPI
2. I2C
3. UART
4. RAW 2 WIRE
5. RAW 3 WIRE
MODE>4 <– raw 2 wire bus mode
900 MODE SET
…
SPEED>1 <– speed setting is ignored in current firmware
901 SPEED SET
1. High-Z outputs (H=input, L=GND)
2. Normal outputs (H=Vcc, L=GND)
MODE>1 <– high impedance output type
9xx OUTPUT HIGHZ
402 RAW2WIRE READY, P FOR PULLUPS
RAW2>

The Bus Pirate has on-board pull-up resistors, but they only pull to 3.3volts. We must use external pull-ups to 5volts, as shown in the picture. High-Z output mode is compatible with the bus, normal outputs would put 3.3volts on the bus, potentially damaging something.

RAW2>l <–configure MSB/LSB
1. MSB first
2. LSB first
MODE>2 <– LSB first
9xx LSB: LEAST SIG BIT FIRST
RAW2>

The card reads and writes each byte least significant bit first (datasheet page 10). We use menu option L to set the data mode to LSB first.

Send 7816-3 ISO answer to reset command

ISO 7816-3 “answer to reset” is a standardized command used among many smart cards. The ATR sequence is shown above: reset is held high, one clock pulse is sent, reset is released. The next 32 clock pulses (4 bytes) read a generic ATR header from the card. The header contains information about the card type and protocol. Multi-card smart card readers use this to determine how to read each card.

RAW2>@^arrrr <– aux high (highz), clock tick, aux low, read 4 bytes
952 AUX HIGH IMP, READ: 1
4xx RAW2WIRE 0×01 CLOCK TICKS
950 AUX LOW
430 RAW2WIRE READ: 0xA2 <–begin ATR header bytes
430 RAW2WIRE READ: 0×13
430 RAW2WIRE READ: 0×10
430 RAW2WIRE READ: 0×91
RAW2>

We issue the command @^arrrr to the Bus Pirate. @ puts the auxiliary pin in high-impedance input mode, the pull-up resistor holds the reset at 5volts. ^ issues one clock pulse, with delay. a returns the auxiliary pin to output and holds the reset line at ground.

r issues 8 clock pulses and displays the returned bits as a byte. This is one instance where the protocol is incompatible with I2C. I2C includes an additional acknowledge bit between each byte, the sle4442 outputs 32bits consecutively.

Page 25 of the datasheet explains the ISO7816-3 header. It’s easiest to interpret in binary. Rather than convert everything to binary, we set the Bus Pirate to binary display mode and issued another ATR command.

RAW2>o <–setup the output mode
1. HEX
2. DEC
3. BIN
4. RAW
OUTPUT MODE>3 <–show numbers in binary
903 OUTPUT MODE SET
RAW2>@^arrrr <–another ATR command
952 AUX HIGH IMP, READ: 1
4xx RAW2WIRE 0b00000001 CLOCK TICKS
950 AUX LOW
430 RAW2WIRE READ: 0b10100010 <–0xA2
430 RAW2WIRE READ: 0b00010011 <–0×13
430 RAW2WIRE READ: 0b00010000 <–0×10
430 RAW2WIRE READ: 0b10010001 <–0×91
RAW2>

The first 2 bytes are protocol header bytes according to ISO 7816-3 (datasheet page 25).

Byte 1 identifies the protocol type.

0b10100010
7:4 – Protocol type (1010=2 wire)
3:3 – RFU (0)
2:0 – Structure Identifier (010=general)

Byte 2, protocol parameters, tells us about the card if we didn’t have a datasheet.

0b00010011
7:7 – Supports random read lengths (0=no, read to end)
6:3 – Data units (0010=256units)
2:0 – Data unit bits (011=8bits per unit)

From the header we can tell that the protocol type is 10, a two wire bus. The card must be read all the way to the end before it accepts a new command. It has 8bits to a unit, and 256units; 256bytes total storage. The final two bytes are 7814-4 data, which seems uninteresting (see datasheet page 26).

Dump main memory (256 bytes)

Once the card is reset and the ATR bytes are read, we can send commands to the card. Commands are three bytes long; they begin with a I2C-style start condition, and end with an I2C-style stop condition. Start and stop conditions can be generated manually with \-/_\ and _/-\, but the raw 2 wire library also includes the shortcuts { and }. The start and stop conditions are the same as I2C, but they’re used at a different point in the transmission.

The read main memory command is 0×30, followed by a read start address (0), and a third byte that doesn’t matter (0xff).  After the stop condition, the card outputs data on every clock until it reaches the end of the memory.  As described by the ATR header, no new commands can be sent until the card reaches the last byte of memory.  Starting at read address 0, it takes 256*8 clock pulses to complete the read cycle.

RAW2>{0×30 0 0xff} 0r255 0r10 <–command
410 RAW2WIRE START CONDITION (\-/_\)
420 RAW2WIRE WRITE: 0×30
420 RAW2WIRE WRITE: 0×00
420 RAW2WIRE WRITE: 0×00
440 RAW2WIRE STOP CONDITION (_/-\)
431 RAW2WIRE BULK READ, 0xFF BYTES: <–bulk read of 255 bytes
0xA2 0×13 0×10 0×91 0×46 0xFF 0×81 0×15
0xFF 0×01 0×4B 0×03 0×00 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xD2 0×76 0×00
0×00 0×04 0×09 0xFF 0xFF 0xFF 0xFF 0xFF
0×7B 0×14 0xAE 0×47 0xE1 0×7A 0×94 0×3F
0×4C 0×46 0xC6 0×3B 0×00 0×00 0×00 0×00
0×20 0×08 0×03 0×04 0×09 0x** 0x** 0x**
0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×00
0×00 0×00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0×30 0×31 0×3* 0×3* 0×30 0×30 0×31 0×33
0×3* 0×3* 0×3* 0×00 0×00 0×00 0×00 0×00
0×00 0×00 0×00 0×00 0×43 0×61 0×73 0×68
0×20 0×43 0×75 0×73 0×74 0×6F 0×6D 0×65
0×72 0×00 0×00 0×00 0×00 0×00 0×00 0×00
0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×39
0×39 0×31 0×31 0×00 0×31 0×30 0×31 0×00
0×30 0×30 0×30 0×30 0×30 0×00 0×00 0×00
0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×00
0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×00
0×00 0×00 0×00 0×03 0×00 0×00 0×01 0×00
0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×00
0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×20
0×08 0×03 0×04 0×09 0x** 0x** 0x** 0×00
0×00 0×00 0×00 0×00 0×00 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0×00 0×00
431 RAW2WIRE BULK READ, 0×0A BYTES: <–again to get last byte (256)
0×00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
RAW2>

{ issues the bus start condition. 0×30 sends the read address, 0 is the start byte, and 0xff could be anything. } sends the bus stop condition. 0r255 clocks in 255 8bit bytes and displays them on the screen. The card actually has 256 bytes of main memory, so we issue an additional read command to get the last byte and verify that the bus returns to high after the read is over. We can’t use 0r256 because the Bus Pirate doesn’t understand decimal numbers greater than 255 (we should address that).

What does the data mean?

We dissected the card according the datasheet, [Strom]’s Defcon presentation, and this handy guide (PDF).

32byte Header…

0xA2 0×13 0×10 0×91 <–The first four bytes are a repeat of the ATR data
0×46 0xFF 0×81 0×15<–manufacturer tags, other junk
0xFF 0×01 0×4B 0×03 0×00 <–ICCF, IC card fabricator id
0xFF 0xFF 0xFF 0xFF <–ICCN, IC serial number, 0
0xFF 0xFF 0xFF 0xFF<– misc tags and lengths, 0
0xD2 0×76 0×00 0×00 0×04 0×09 <–application identifier (Kinko’s?)
0xFF 0xFF 0xFF 0xFF 0xFF <–all other bytes 0

The first 32 bytes are a permanently burned header with serial numbers, manufacturer codes, and other unique data (datasheet page 24). This header prevents exact duplication of cards, even if you have a blank card and a security code. Kinko’s didn’t have a custom serial number permanently burned into each card.

Now data….

0×7B 0×14 0xAE 0×47 0xE1 0×7A 0×94 0×3F <– IEEE-754 value, $0.02

This is the value stored on the card, in IEEE-754 format. You can use this utility to make it readable. 0×3f947ae147ae147b=$0.02.

…8 bytes of junk…
0×20 <– 0×20 after copy, 0×00 after computer time
0×08 0×03 0×04 0×09 0x** 0x** 0x**<–date/time purchased

This is the date and time the card was purchased, 2008 March 4, 9:**:**.**. Some digits have been obscured to protect the anonymity of our supplier.

…40 bytes of junk…
0×30 0×31 0×3* 0×3* <–Store number: 01**
0×30 0×30 0×31 0×33 0×3* 0×3* 0×3* <– SN: 0013***

The card serial number consists of the store number and a unique, seven digit number. Some digits obscured.

…more bytes…
0×08 0×03 0×04 0×09 0x** 0x** 0x** <– another time
…more bytes…
0xFF 0xFF 0xFF 0xFF 0xFF 0×00 0×00 0×00<– last 8 bytes on the card
0xFF 0xFF… <-not real data bytes

Dump protection memory (4 bytes)

The first 32 bytes of the data memory can be write protected. Each bit of the four byte data protection register (command 0×34) represents a byte of data memory. A bit set to 1 cannot be overwritten. We can read the data protection register and find out which bytes of the main memory are write protected. This is easiest to understand in binary, so we did this operation in binary output mode.

RAW2>{0×34 0 0} 0r4 <–command
410 RAW2WIRE START CONDITION (\-/_\)
420 RAW2WIRE WRITE: 0b00110100
420 RAW2WIRE WRITE: 0b00000000
420 RAW2WIRE WRITE: 0b00000000
440 RAW2WIRE STOP CONDITION (_/-\)
431 RAW2WIRE BULK READ, 0b00000100 BYTES:
0b00100000 0b11100001 0b00011111 0b11111000 <–data protection register
RAW2>

Each bit corresponds with one of the first 32 bytes of the card memory. If the bit is one, the corresponding byte is write protected. This register can be written, but only if you have the correct password.

Dump security memory (4 bytes)

The security memory contains a password verification attempt counter, and the three byte password. We can read the read the security memory without the password, but the password bytes will read as 0. The security memory address is 0×31.

RAW2>{0×31 0 0} 0r4 <–command
410 RAW2WIRE START CONDITION (\-/_\)
420 RAW2WIRE WRITE: 0b00110001
420 RAW2WIRE WRITE: 0b00000000
420 RAW2WIRE WRITE: 0b00000000
440 RAW2WIRE STOP CONDITION (_/-\)
431 RAW2WIRE BULK READ, 0b00000100 BYTES:
0b00000100 0b00000000 0b00000000 0b00000000<–bytes
RAW2>

The attempt counter starts at three (0b00000111), and counts down to 0. When the counter reads 0, the card is essentially destroyed. We used two access attempts to test the password commands, this card has one try left.

Taking it further

We’d like to demonstrate all the capabilities of this card, including password verification and data updates, but we need to buy a new card with a known security code.

Due to the range of interesting smart cards cards out there, it might be handy to add an ISO 7816-3 ATR command macro and reply decoder to the Bus Pirate.

UPDATE: New firmware with JTAG and more

We’re always excited to get a new chip or SIM card to interface, but our enthusiasm is often dampened by the prototyping process. Interfacing any chip usually means breadboarding a circuit, writing code, and hauling out the programmer; maybe even a prototyping PCB.

A few years ago we built the first ‘Bus Pirate’, a universal bus interface that talks to most chips from a PC serial terminal. Several standard serial protocols are supported at 3.3-5volts, including I2C, SPI, and asynchronous serial. Additional ‘raw’ 2- and 3- wire libraries can interface almost any proprietary serial protocols. Since this has been such a useful tool for us, we cleaned up the code, documented the design, and released it here with specs, schematic, and source code.

Concept Overview

The Bus Pirate is a serial terminal bridge to multiple IC interface protocols. We type commands into a serial terminal on the computer. The commands go to the Bus Pirate through the PC serial port. The Bus Pirate talks to a microchip in the proper protocol, and returns the results to the PC.

All pins output 3.3volts, but are 5volt tolerant. On-board 3.3volt and 5volt power supplies are available to power the connected chip. Software configurable I2C pull-up resistors complete the package.

The serial terminal interface works with any system: PC, Mac, Linux, Palm Pilots, WinCE devices, etc; no crapware required. We considered a USB device, but USB isn’t compatible with the huge number of hand-held devices that have a serial port. We also wanted a 3.3volt device with 5volt tolerant inputs, but most popular through-hole USB microcontollers were 5volt parts (e.g. the PIC18Fx550).

The Bus Pirate currently ’speaks’ three hardware protocols for high-speed interfacing, and has two software protocol libraries for easy bus manipulation. The theory and specification of each protocol is beyond what we can cover here, but check out some of these tutorials:

I2C

A slow 2 wire bus. Wikipedia is a great place to start for I2C background. I2C-Bus.org, Robot Electronics, Embedded Systems Academy, and Embedded.com have decent I2C tutorials.

SPI

A simple 3 wire bus. Wikipedia has background; Embedded.com has a great tutorial and comparison to I2C.

Universal Asynchronous Receiver Transmitter (UART or serial)

A clock and timing dependent serial protocol best known for its appearance as the PC serial port protocol. Wikipedia has background on asynchronous serial protocols.

Raw 2 wire

This is a generic 2 wire protocol library, similar to I2C but without an ACK bit. I2C and many proprietary 2 wire protocols can be formed using the bus manipulations available in this mode. Use this library to work with non-I2C 2 wire devices, like smartcards or Sensirion SHT11 temperature/humidity sensors.

Raw 3 wire

This is a generic 3 wire protocol library, similar to SPI but without the constraints of a hardware module. Use this library to work with devices that use non-8bit compatible 3-wire protocols, like the Sparkfun Nokia 6100 LCD knock-off. Many 3 wire protocols can be formed using the bus manipulations available in this mode.

Hardware

Click for a full size PCB placement image (PNG). Screw terminals connect to the power supplies. A row of seven pin headers connect to the IO pins. Despite the label, only 7volts DC is required.

This table shows the pin connections for each bus mode. Raw 2 wire mode uses the same pin configuration as I2C. Raw 3 wire mode uses the same pin configuration as SPI.

Click for a full size circuit image (PNG). The circuit and PCB are designed using the freeware version of Cadsoft Eagle. Download the project archive (ZIP).

PIC 24FJ64GA002

We used a PIC24FJ64GA002 microcontroller in the Bus Pirate; this is the same chip we used in our mini-server project. It’s fast enough to do everything we want (16MIPS), and the peripheral pin select feature allows the hardware SPI, UART, and I2C modules to share output pins. Each power pin needs a decoupling capacitor(C12,13), and the MCLR function requires a resistor (R7) between pin 1 and 3.3volts. The PIC has an internal voltage regulator that requires a 10uF tantalum capacitor (C3), though we used a plain electrolytic capacitor without issue. Read about programming and working with this chip in our PIC24F tutorial. If you don’t have a PIC debugger, several readers recommend the under-$40 ICD2 clones on eBay.

The PIC runs at 3.3volts, but the digital-only pins are 5volt tolerant for interfacing 5volt logic. Pins 14,15,16,17,18,21, and 22, are digital only, which we determined by looking through the datasheet and eliminating any pins with an analog connection type (table 1-2, pages 11-16). According to the datasheet, I2C pins are also 5volt tolerant. There’s a bunch of conflicting information on the web, but datasheet page 230, parameter DI28, clearly states that the max input for a 24FJ64GA002 I2C pin without analog circuitry is 5.5volts.

Pins 21 and 22 (RB10/11) can pull-up SDA/SCL through resistors R4 and R5.

MAX3223CPP

This chip converts 3.3volt serial output to +/-10volt RS232 signals compatible with a PC serial port. The MAX3223CPP is a 3-5volt version of the MAX202, with extra power saving features. MAX RS232 transceivers require four 0.1uF capacitors for a charge pump (C4,5,7,8), and one decoupling capacitor (C17). We used the same capacitors for everything.

We used a MAX3223CPP, which doesn’t seem to be available anymore. MAX3223EEPP+ is a pin-compatible newer version, available at Digikey for $7. Ouch! None of the 3223’s power saving features are used, so a cheaper, simpler 3.3volt RS232 transceiver should be substituted if at all possible.

Power supplies

Most chips can be powered from the Bus Pirate’s on-board 3.3volt and 5volt supplies. 5volts is supplied by a common 7805 regulator (VR2) and two decoupling capacitors (C9,10). An LM317 adjustable regulator (VR1) is set to 3.3volts using two resistors (R2,3), and requires two decoupling capacitors (C6,7). The circuit requires a 7-10volt DC supply (J1).

Part list

Firmware

The firmware is written in C using the free demonstration version of the PIC C30 compiler. Learn all about working with this PIC in our introduction to the PIC 24F series. Download the project archive (ZIP).

main.c – Handles the user terminal interface.

busPirate.c – Abstraction routines that convert syntax to actions on the proper bus.

uartIO.c – IO routines for both hardware UARTs.

m_i2c_1.c – Software I2C routines by [Michael Pearce]. We couldn’t get the PIC hardware I2C to work, so we used this helpful library. The software doesn’t take into account the I2C speed setting, and seems to work at about 5KHz.

SPI.c – Routines that drive the hardware SPI module.

raw2wire.c – Software 2-wire interface library.

raw3wire.c – Software 3-wire (SPI) interface library.

User input is held in a 4000 byte buffer until a newline character (enter) is detected. If the first character of the input is a menu option (see below), the menu dialog is shown, otherwise the string is parsed for data to send over the bus (see syntax). The code consists of an embarrassing number of switch statements and spaghetti code.

Terminal interface

Rather than write a junk piece of software to control the device, we gave it a serial command line interface that will work with any ASCII terminal.  The bus pirate responds to commands with three digit result codes and a short message. The codes are designed with PC automation in mind. We’ve included a table of result codes in the project archive (zip).

Menu options

Menu options are single character commands that don’t involve data transfers. Enter the character, followed by <enter>, to access the menu.

? – Show a help menu with commands and syntax.

M – Set the bus mode (SPI, I2C, UART, raw 2 wire, raw 3 wire). Followed immediately by a prompt for speed, polarity, and output state (mode dependent).

• Bus speeds: SPI:30, 125, 250, 1000KHz. I2C:100, 400, 1000KHz. UART: 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200bps. Raw modes: 1, 10, 50KHz.
• Inverse clock setting sets the idle state opposite of normal (normal SPI:idle low; normal UART:idle high): SPI:idle high; UART:idle low.
• Some modes have optional high-z output modes for use with pull-up resistors (Low=ground, High=input).

L – Toggle bit transmit/receive order: most/least significant bit first.

P – SDA/SCL pin pull-up resistor toggle (3.3volts). Only valid in I2C and raw 2 wire modes.

O – Set number output display format. The terminal can display numbers as decimal, hexadecimal, and binary ASCII values. A fourth format sends the raw, unprocessed byte for reading ASCII formatted text.

Syntax

A simple syntax is used to communicate with chips over a bus.  Syntax commands have generic functions that generally apply to all bus types.

A/a/@ – Toggle auxiliary pin. Capital “A” sets AUX high, small “a” sets to ground. @ sets aux to input (high impedance mode) and reads the pin value.

[ - Start data write. SPI/raw 3 wire: chip select enabled. I2C/raw 2 wire: start condition. RS232: open UART, discard received bytes.

{ - Start data write with reads. Same as [, except: SPI/raw 3 wire: show the read byte for each write. RS232: display data as it arrives asynchronously.

] or } – End data write. SPI/raw 3 wire: chip select disabled. I2C/raw 2 wire: stop condition. RS232: close UART.

R/r – Read byte. SPI/raw 3 wire: send dummy byte, return read. I2C: read byte with ACK. Raw 2 wire: read 8 bits. RS232: check UART for byte and return, or fail if empty. Use 0r1…255 for bulk reads up to 255 bytes.

0b – Write this binary value. Format is 0b00000000 for a byte, but partial bytes are also fine: 0b1001.

0h or 0x – Write this HEX value. Format is 0h01 or 0×01. Partial bytes are fine: 0xA. A-F can be lower-case or capital letters.

0-255 – Write this decimal value. Any number not preceded by 0x, 0h, or 0b is interpreted as a decimal value.

, or space - Value delimiter. Use a coma or space to separate numbers. Any combination is fine, no delimiter is required between non-number values: {0xa6,0, 0 16 5 0b111 0haF}.

Direct bus manipulation commands for raw 2 wire mode and raw 3 wire mode.
^ – Send one clock tick. Use 0^1…255 for multiple clock ticks.

/ and \ – Toggle clock level high (/) and low (\). Includes clock delay (100uS).

-/_ – Toggle data state high (-) and low (_). Includes data setup delay (20uS).

! - Read one bit with clock.

. - Read data pin state (no clock).

& – Delay 1uS. Use 0&1…255 for multiple delays.

Using it

Here are two examples that show the Bus Pirate in action. Terminals should be set to ASCII mode with local echo, we used the Windows serial terminal. The PC-side serial connection is 115200bps, 8N1. The Bus Pirate should respond to any single line feed type (0×0a, 0×0d), or both (Windows style).

.I2C/SPI – Flash 24LC1025 EEPROM

Microchip’s EEPROMS are popular permanent-storage memory chips, the 24LC1025 has 128Kbytes of storage with an I2C interface.  We can test this chip without bread-boarding a big circuit or writing code.

The picture shows an 24LC1025 connected to the Bus Pirate. The EEPROM works from 2.7 to 5volts, so we used the 3.3volt supply from the Bus Pirate to power the circuit. The on-board SDA/SCL pull-up resistors hold the I2C bus high, and eliminate the need for external resistors. A single 0.1uF capacitor decouples the EEPROM from the power supply.

Setup I2C mode

First, we setup the Bus Pirate for I2C mode and enable the pull-up resistors. Since the Bus Pirate currently uses a software I2C library, the speed setting doesn’t really have an effect.

SPI>m  <–enter m for mode select
1. SPI
2. I2C
3. UART
4. RAW 2 WIRE
5. RAW 3 WIRE
MODE>2  <–enter 2 for I2C
900 MODE SET
Set speed:
1. 100KHz (Standard)
2. 400KHz (Fast Mode)
3. 1MHz (High Speed)
SPEED>1 <–speed doesn’t really do anything…
901 SPEED SET
202 I2C READY, P/p FOR PULLUPS
I2C>P   <–enable the I2C pull-up resistors
205 I2C PULLUP ON
I2C>

Write to EEPROM (I2C)

All I2C operations begin with a start condition { or [, and end with a stop condition } or ]. A write begins by addressing the device (1 byte) and looking for an acknowledgment bit (ACK). If the EEPROM responds, we can send the data location to write (2 bytes) and data payload (n bytes). The Bus Pirate automatically checks for an ACK at the end of each write, and ACKs each read.

The 24LC1025 base address is 1010xxy, where xx is determined by the state of pins 2 and 3, and y is read (1) or write (0) mode. We tied pins 2 and 3 high, making the full write address 1010110.  We’ll start writing to the device at the first data location (0 0), and write one to thirteen using a mix of data input formats (1…13).

I2C>{0b10100110 0 0 1 2 3 4 5 6 7 8 9 10 0xb 0xc 13} <–I2C command
210 I2C START CONDITION <–bus start
220 I2C WRITE: 0xA6 GOT ACK: YES <–address sent and ACK received
220 I2C WRITE: 0×00 GOT ACK: YES <–write address
220 I2C WRITE: 0×00 GOT ACK: YES <–write address
220 I2C WRITE: 0×01 GOT ACK: YES <–data
…
220 I2C WRITE: 0×0D GOT ACK: YES
240 I2C STOP CONDITION
I2C>

Read from EEPROM (I2C)

Reading the 24LC1025 takes two steps. First, a write command with no data sets the address pointer. Second, a read command outputs data starting at the location set in step 1.

The first command is a write command, we use the hexadecimal equivalent of the write address (0b10100110 = 0xa6) to save a bit of typing. The address pointer is set to the location where we wrote our data (0 0).

I2C>{0xa6 0 0} <–set write pointer command
210 I2C START CONDITION
220 I2C WRITE: 0xA6 GOT ACK: YES
220 I2C WRITE: 0×00 GOT ACK: YES
220 I2C WRITE: 0×00 GOT ACK: YES
240 I2C STOP CONDITION

With the pointer set, we can start reading data. The read address is the device address, with the last bit set to 1 ( 0b10100111 or 0xa7). We used thirteen r commands to read the data, but we could have used the shorthand version: 0r13.

I2C>{0b10100111 rrrrrrrrrrrrr} <–read command
210 I2C START CONDITION
220 I2C WRITE: 0xA7 GOT ACK: YES <–chip ACKed the read address
230 I2C READ: 0×01 <–data byte 1
230 I2C READ: 0×02 <–data byte 2
…
230 I2C READ: 0×0D <–data byte 13
240 I2C STOP CONDITION
I2C>

We know the operation was a success because the output matches the data we wrote earlier.

UART – EM406 SurfIII GPS

The EM406 is a tiny 5volt GPS module that tracks up to 20 satellites. By default, it outputs NMEA formatted data from a serial port at 4800bps, 8N1. The output format is standard serial, but at 2.8volts it’s incompatible with PC serial ports. The Bus Pirate can interface this GPS without the need for a separate RS232 transceiver or 5volt power supply.

Setup the UART

First, we setup the Bus Pirate UART to receive serial data at 4800bps.

I2C>m <–setup mode
1. SPI
2. I2C
3. UART
4. RAW 2 WIRE
5. RAW 3 WIRE
MODE>3 <–UART
900 MODE SET
Set speed:
(bps)
1. 300
2. 1200
3. 2400
4. 4800
…
9. 115200
SPEED>4 <–4800bps
901 SPEED SET
302 UART READY
UART>

Enable UART and data reads

An important thing to remember about UARTs is that the data arrives asynchronously. Unlike SPI and I2C, where data transfer is controlled by the master, serial data can arrive at the UART at any time. The GPS is a great example of this because it spits out location data continuously, without user intervention.

We developed two read modes to cope with asynchronous data .  { echos all incoming data as it arrives.  New data will displace and garble data entry, but all input is still accepted normally.  [ opens the UART in a send only mode that discards incoming bytes. } or ] closes the UART, regardless of the mode.

UART>{ <–open UART with async reads
310 UART OPEN, } TO CLOSE
330 UART READ: 0×80 <–GPS data
330 UART READ: 0×78

Write to the UART

Type in values to send out the UART. Even if the input is broken up by incoming data, it will be processed on <enter>.  We sent 0×40 as an example, but this has no particular meaning to the GPS module.

330 UART READ: 0×80 0×40<–random byte to write
320 UART WRITE: 0×40 <–byte written

Close the UART

“}” followed by <enter> closes the UART.

330 UART READ: 0×78
303 UART READ: 0×60 } <–close UART command
330 UART READ: 0xE6
340 UART CLOSED
UART>

Don’t think you can use this GPS data to track us, we don’t actually get satellite reception down here in mom’s basement.

Taking it further

The Bus Pirate is an important development tool in our lab. We keep updating it as we use it, and we’ll release new firmware as we add protocols and features. Expect to see the Bus Pirate in future articles.

These improvements are at the top of our list. Do you have any suggestions?

• New protocols: One Wire, CAN, ???
• Controls for polarity and other settings
• Adjustable instruction delay
• Get hardware I2C module working.
• Enable protocol speed settings.
• Cheaper, easier to get RS232 transceiver

The project archive (ZIP) has everything you need to build your own Bus Pirate.

Now that we listen to MP3s, and watch XVIDs or x264s, a computer is the entertainment center in at least one room of most homes. Unless you have a special HTPC, though, you’re probably stuck using the keyboard to pause, change the volume, and fast-forward through annoying Mythbusters recaps. PC remote control receivers range from ancient serial port designs (who has one?) to USB devices not supported by popular software. In this how-to we design a USB infrared receiver that imitates a common protocol supported by software for Windows, Linux, and Mac. We’ve got a full guide to the protocol plus schematics and a parts list.

Design overview

Remote controls transmit data on an modulated infrared beam. An infrared receiver IC separates the modulated beam into a clean stream of 0s and 1s. The data stream is decoded by a microcontroller and sent to a computer over a USB connection. Software processes the codes and triggers actions on the computer.

Background

Computer infrared receivers

The oldest PC infrared receiver design uses a receiver IC to toggle a serial port pin, usually DCD. This design probably originated on Usenet, and it’s still the most popular on the web: Engadget, Instructables, etc. These aren’t true serial devices because they don’t send data to the PC. Instead, a computer program times pulses on the serial port and demodulates the signal. This is a super simple design, but it depends on direct interrupt access and timing precision that’s no longer available in Windows. Linux or Mac users can try this receiver, if you still have a serial port. We couldn’t get this type of receiver to work with the serial port on a modern Windows XP PC, and don’t expect the precise timing to transfer through a USB->serial converter.

Some more advanced infrared receivers are true serial port devices that measure or decoding infrared signals before sending data to the computer. The UIR/IRMan and UIR2 incorporate a classic PIC 16F84, but don’t provide firmware and/or source code. These devices should work on a modern computer, through a USB->serial converter if necessary. The USBTINY and USBIRBOY are native USB devices, but lack wide support.

Receiver software

Regardless of receiver type, the computer needs a program to listen for incoming remote commands and convert them to actions on the computer. Linux and Mac users have LIRC, which supports a bunch of different receiver types. Windows users are a bit less fortunate. WinLIRC is an abandoned Windows port of LIRC for simple interrupt-based serial port receivers; WinLIRC was last developed in 2003. Girder was originally a freeware PC automation utility, but has become expensive bloatware with a 30 day trial. Fortunately, the last freeware version of Girder (3.2.9b) is still available for download.

Working with IR remote protocols

Decoding IR signals

Remote controls encode commands in the spacing or timing of a 38KHz carrier pulse, [San Bergmans] has an explanation of the principals involved. An infrared receiver IC separates the data stream from the carrier. Our job is to decode the data stream with a microcontroller. There are dozens of remote control protocols, but Phillips’ RC5 is widespread and commonly used by hobbyists.

RC5 is stream of 14 equal length bits of exactly 1.778ms per bit time. A pulse during the first half of the bit time represents 0, a pulse in the second half represents 1. This scheme is called Manchester coding.

We used a logic analyzer to examine the output of a Happauge WinTV remote control, a known RC5 remote. The diagram shows two presses of the 1 button, and two presses of the 2 button; note that the output is inversed and the Manchester coding is backwards from the above description.

The first two bit times are start bits, followed by a toggle bit. The toggle bit inverses each time a button is pressed so the receiver can tell the difference between a hold and a repeated press. The next 5 bits are the address (0b11110=0×1E), followed by the command (0b000001=0×01, 0b000010=0×02). A backwards compatible extension to RC5 uses the second start bit as command bit 7.

Representing remote codes to the computer

Looking at previous designs, we saw three general methods of communicating remote commands to a computer:

• Protocol specific receivers decode one protocol, and send actual decoded commands to the PC
• A more general type of receiver measures the timing and spacing of each pulse and sends the full waveform to the PC for analysis.
• Some receivers create a unique hash for a signal, but don’t actually include enough data to fully recreate the waveform.

While our preference is towards the general hash method, our only remote uses RC5 and it was more interesting to build an RC5 specific decoder. We describe modifications for a more general version in the firmware section.

Computer interface protocol

We didn’t want to write our own receiver software or driver, so we looked for an existing, well established communication protocol to imitate. The UIR/IRMAN/IRA/CTInfra/Hollywood+ type receiver is supported by Girder and LIRC, and uses a simple serial protocol with handshake:

• The device is initialized by the DTS and DTR pins of the serial port. We don’t have these and don’t care.
• The computer sends “IR”, with an optional delay. The device replies “OK”. We’ll just send “OK” on every “R”
• Remote control codes are sent as a unique six byte hash. We’ll decode an RC5 signal and send the actual values, but a generic hash could be used instead.

This protocol is for a serial port device, but our USB receiver will appear as a virtual serial port and the program won’t know the difference.

Hardware

Click here for a full size schematic (png). Our receiver is based on a USB enabled PIC 18F2455 microcontroller, the smaller, cheaper version of the 18F2550. The 18F family is programmable with the hobbyist favorite JDM-style programmers if a diode is used to drop VPP to a safe level. The PIC gets one decoupling capacitor (C1), and a diode (D1) and resistor(R1) on the ICSP programming header. We exposed the serial port on a pin header for debugging or a mixed USB/serial port version using a MAX RS232 transceiver IC.

The USB peripheral requires a 20MHz external clock (Q1, C5,6), and a .220uF capacitor. We faked the capacitor using 2 x .1uF decoupling capacitors (C2,3). A 3mm LED (LED1) and a 330ohm current limiting resistor (R2) show USB connection status.

We used a TSOP-1738 infrared receiver IC which calls for a 4.7uF decoupling capacitor (C4). If you can’t find this particular IC, any receiver listed here should work. The TSOP-1738 output is the inverse of the received signal, it pulls to ground when a pulse is detected, so a pull-up resistor (R3) holds the pin high when no signal is present. Check if you use a different receiver, you may need to use a pull-down resistor and reverse the Manchester decoding routine in the firmware.

The circuit draws power from the USB bus, so we don’t need an additional power supply.

Parts list

Click here for a full size placement diagram (png). The PCB design is 100% through-hole and single sided. The schematic and PCB were made with Cadsoft Eagle, freeware versions are available for most platforms. All the files are included in the project archive (zip).

Firmware

The firmware is written in C using Microchip’s free demonstration C18 compiler. Firmware and source are included in the project archive (zip).

We used version 2.3 of Microchip’s USB stack to create a USB serial port using the default drivers already available on most systems. The USB stack has simple functions to enumerate the USB device and transfer data between device and host. It only took a few pin changes to get the CDC demonstration working on our custom hardware.

Our implementation of the UIR/IRMAN/IRA/CTInfra/Hollywood+ protocol simply responds to the letter ‘R’ with ‘OK’. This should satisfy the handshake requirements of any implementation of this protocol.

We chose to specifically decode RC5 (and RC5x) because it’s a widely used protocol, and the only type of remote we have to work with. Most of the decoding is done in the interrupt handler:

• The first signal change triggers an interrupt that starts a 889us (one-half bit period) timer.
• On each timer interrupt, one-half of a Manchester coded bit is sampled.
• Every other interrupt the measurements are compared, and the bit value is calculated to be 0, 1, or an error. Errors reset the decoding routing.
• At the end of each transmission the address and command bytes are decoded, and sent to the host with 4 buffer bytes(0). We discard the toggle bit because it would confuse the PC software into thinking every other press was a unique code. We append the second start bit to the command bit for RC5x compliance; this just adds 0×40 to non RC5x remote codes.

A more general version can be made by removing the Manchester coding step (3), and sending 48 sample bits (all 6 bytes) to the computer.

Installing the USB infrared receiver

Most operating systems already have drivers that support a virtual serial port device like the receiver. Windows XP has the required drivers, but needs help from an .inf file to properly associate them with our device.

Windows will show the new hardware dialog the first time you plug in the receiver. Choose to use a custom driver and point it to the .inf file included in the project archive (zip). This links the device to a driver already included in Windows, and adds the receiver as a COM port. You can check the COM port number in the control panel.

Mac and Linux users can use the receiver with LIRC, but Windows users will be faced with the choice of the old, freeware Girder, or the new, 30-day trial shareware version. We used the freeware version of Girder, but hope you guys can suggest a great, open source alternative that we overlooked.

Regardless of the computer-side control software you use, configure it for a UIR/IRMAN/IRA/CTInfra/Hollywood+ style receiver, and enter the COM port or serial address assigned to it. Our receiver is also compatible with any protocol options like ‘Fast UIR Init’ and ‘Skip UIR Init Check’, which shorten or eliminate the “IR”->”OK” handshake. Now test the receiver and add a remote according to the documentation for your software.

Manual terminal interface and debugging

If you have a problem with the receiver, or you’re just curious, try to interface it from a serial terminal. We really like the serial terminal on Hercules. Set the correct COM port, but the speed and configuration settings are ignored by the USB serial port driver.

A capital ‘R’ will prompt the receiver to reply ‘OK’. RC5 codes are returned as raw bytes, so be sure to set your terminal to show HEX values rather than interpret it as ASCII text. The first byte is the RC5 address byte (0×1E), followed by the command byte (0×41), and then four buffer 0s to comply with the UIR/IRman protocol. The image shows the handshake, and the output of a short press on the 1,2, and 3 buttons.

A free utility called Portmon logs COM port activity for review. This is helpful for spying on existing receiver protocols, and debugging the interaction of our custom hardware and closed/proprietary software. The image shows Girder sending the initialization string ‘IR’ (0×49,0×52), and the receiver reply ‘OK’ (0×4F,0×4B).

Taking it further

Our RC5x compliant receiver follows a widely used interface protocol. There’s a ton of possibilities for additional features in an open source infrared receiver:

• Support all remotes through a generic hash generator, like the original UIR/IRman hardware.
• Add additional remote protocol decoders, like RC6.
• Support multiple, configurable interface protocols.
• Implement the serial port I/O.
• Store configuration options in EEPROM, including protocol, interface mode, timing options, serial port, etc.

If you’ve never heard about electronic paper, crawl out from under that rock and read up on the Sony Reader and the Amazon Kindle. E-paper is a flexible display made of color-changing beads that mimic ink-on-paper for easy daylight reading. The revolutionary thing about e-paper is that after it’s set, it stays that way without additional power.

This sounds great in theory, but Esquire’s cover is the first time everybody can afford to hack an e-paper display. We took the cover into the Hack a Day lab to document, test, and hack. In the end, we recycled it into something useful that anyone can build. We’ve got all the details on how the display works and what it takes to use it in your own projects. Read about our e-paper clock hack below.

Background

The Esquire e-paper cover hit big on the net, but was quickly panned. NOTCOT has beautiful scans of the circuit board and e-paper. Popular Science posted instructions for reading the code with a PICkit2. [Slaxter] verified that the PIC chip can be read, and that the code protection fuses are off. [Matt] manipulated the e-paper cells directly with skillful soldering and an Arduino. So far, there hasn’t been a lot of interest in repurposing the e-paper, or reprogramming the existing microcontroller.

E-paper panels

The actual e-paper panels, manufactured by E-Ink, aren’t that exciting. Each panel has a set of predefined segments, 11 on the front panel and 3 on the rear Ford advertisement. This isn’t a matrix that we can reprogram into an e-reader. [just_mike] has a great set of ultra close-up shots of the individual beads that make up each segment.

Each e-paper segment has an individual connection, and a connection that’s shared with other cells on the panel. The segments become white or black depending on the direction of current applied to the cell. When common is low, any segment that is also connected high will darken. When common is high, each cell connected to ground will clear. The PCB uses 16 volts from five 3.3volt batteries to switch the cells, but [Slaxter] showed that 5volts was sufficient with his Arduino project.

Performance testing
We made several observations about the e-paper operating specifications.

First, it takes nearly 0.5 seconds to completely darken or clear a cell. In the video you can see the partial states created by switching the e-paper too fast. We’re not quite sure of the optimal change time, but between 0.25 and 0.5 seconds seems to be the minimum.

This also raised questions about the maximum change time. Does it damage the e-paper to apply current for longer than necessary? Does the e-paper continue to consume current as long as it’s applied, wasting the batteries? We took special care in our code to return all outputs to ground after a change to avoid a continuous current through the panel.

Clearing and darkening must be done separately. It takes two complete operations to fully refresh the screen; one to clear old segments, one to darken new segments. A smart programmer will think they can save a cycle when only adding or removing items, and not doing both. This is true to some extent, but continuous manipulation of one cell without refreshing adjacent cells causes color ‘creep’. In the video, a flashing background without updates to any other segments quickly drives the inactive segments to a mid-state between dark and light.

Driver board

The driver consists of an eight-pin Microchip PIC12F629, two 4094 shift registers, and some supporting components.

Click here for a full size pin diagram of the e-paper driver board(PNG).

Batteries

Esquire invited hacks of their cover with the rather lame suggestion of replacing the batteries. This makes sense, the covers were shipped all over the world in refrigerated containers to help extend the battery life. Even with that effort, Esquire says that the batteries will last a few months.

Batteries 1-5 are in series and provide a 15-16volt switching current for the e-paper. The sixth battery provides 3volts for the PIC. No word yet on which batteries die first. If you want to ‘replace’ your batteries, you’ll need to desolder the old ones, and provide a 5-16volt e-paper supply, and 3volt microcontroller supply, at the points indicated.

We eventually had to replace our microcontroller battery because we abused it a bit during development. A button battery holder with 20mm pin spacing will fit the existing holes. Mouser #534-106 will probably work, but this is unconfirmed.

4094 shift registers (IC1, IC2)

The shift registers switch the e-paper segment controls at 16 volts.

The two 4094 ICs are shift registers setup to cascade data from IC1 to IC2. This simple shift register is a slight variation on the 74HTC595 we used in our graffiti wall. The main difference is that the 4094 strobe line is normally low, and briefly pulled high to put new values on the output pins. We noticed that the 4094 requires long clock and strobe pulses. This could be due to lazy drive circuitry between the PIC and the 4094, or just the nature of the 4000 series.

4094 segment output map

12F629

Click here for a full size schematic drawing(PNG). An eight pin PIC12F629 drives the 4094 shift registers that control each e-paper segment. Two pins are unused (GP4, GP5).

The MCLR feature is enabled with resistor R8. The design doesn’t include a diode to protect the PIC from the 13volt programming current. Microchip recommends this, but there’s no other sensitive ICs sharing the circuit so perhaps the designer felt a resistor was sufficient protection.

Three pins drive the data, clock, and strobe lines of the 4094 (GP0, GP1, GP2). The 4094 has to be interfaced at the same voltage it switches, 16 volts, so the PIC switches the interface pins through transistors. As far as we can tell, the 4094 control lines are pulled high with a resistor. The PIC switches a transistor on, and it pulls the line to ground. The interface to the 4094 is backwards. A PIC high pin is seen as low at the shift register, and low is seen as high. The interface won’t work unless reversed.

The programming pins are brought to a header at the top of the PCB. We soldered standard .1″ pin header into the holes provided (Mouser #571-41033290). The two programming pins, PGD and PGC, are shared with the circuitry that drives the shift registers. We were able to read the device with an ICD2 debugger. We couldn’t reprogram it though, probably because of the shift register driver. Has anyone had success? Regardless, the shared pin arrangement makes it impossible to do in-circuit debugging on this device.

PIC pin connections

Tap the board

It’s easy to tap into the board and use it with your favorite microcontroller. All but one of the required interface signals are already brought to a header. The strobe line can be tapped through the via indicated by the arrow. You don’t want the PIC to interfere with your new controller, so remove it or deactivate it by severing the power pin.

Interface library

Our first effort to drive the board involved our PIC24F-based mini web server. It was handy, and the PIC24F is easy to work with. We perfected our interface library on a low-power MSP430. Both versions are in the project archive(ZIP), but the MSP430 version of the library is more mature.

The library includes a software bit-bang routine, functions for interfacing the board, and address definitions for the segment and common lines. Options in esquire_eink.h enable a bit-bang delay and set its length; we found the 4094 lazy and in need of a lengthy clock pulse. The initBang() function sets the direction of the pins, and should be changed to suit your microcontroller. Call it, or set your IO pins to output elsewhere:

bangInit(); //set bitbang pins to output

The setSeg() function sets the passed segments dark (1) or clear (0):

setSeg(FRONT_BOX_GUY+FRONT_BACKGROUND, 1); //set(dark) these segments
setSeg(FRONT_21ST_CENTURY,0);//clear (light) these segments

The setSeg() function includes a color change delay defined by EINK_DELAY in esquire_eink.h. At the end of the delay it returns the shift register pins to ground. We want to avoid damaging to the e-paper or wasting the batteries, though we don’t really know if this is necessary.

One thing we noticed about setSeg() was that manipulating single cells causes adjacent cells to regress toward a mid-color. We developed the setDisplay() function to combat this by fully refreshing the display every time. setDisplay() includes a pause for each change, and then returns the shift register outputs to ground. Just pass the segment arrangement for a fully refreshed display:

setDisplay(FRONT_ESQUIRE+BACK_LEFT);//XX dark, everything else clear

You can access the shift registers directly with the bangIt() function, but consider returning the shift registers outputs to ‘0′ after the e-paper color change is complete. You could damage the e-paper or cause excessive current drain if you leave it on, if that’s actually ‘a thing’.

bangIt(0b1110000000000000);//all back panel segments on
pause();//wait for the color change
bangIt(0x0000);//return all outputs to ground

To port the library to your microcontroller, just check the pin configurations in esquire_eink.h, and the pin setup function bangInit() in esquire_eink.c. Keep in mind that the pin directions are reversed by the interface transistors.

Putting it to use, an e-paper clock

We wanted to do something useful with the first cheap consumer e-paper panel. It had to be something pretty easy so that lots of people can recycle this cool piece of technology. We couldn’t resist doing what so many do with old display tech: make a clock. Schematics, firmware, and art templates are in the project archive(.zip).

There’s so few segments on the e-paper that we can only partially represent the time. Six segments show time, each fades to reveal the time to the nearest ten minutes past the hour. We also flash eye-candy on the non-time segments of the panel. Here’s the custom bezel we created. This bezel, and a template to make your own, are included in the project archive(ZIP). We printed our bezel mirrored so the ink is protected from scratches.

Hardware

We were inspired by the low-power properties of e-paper to use Texas Instruments’ MSP430 line of 16-bit microcontrollers. With the right configuration, the MSP430 draws so little power that it’s only limited by the shelf life of a battery. We can even give the original designers a run for their money, and see if we can make a lower power device.

The best thing about the MSP430 is that you can buy a kit with a USB programmer/debugger and breakout board for only 20 bucks. It comes with a free C compiler limited to 4K, but the F2013 only has 2K of memory. This is a complete development tool, no soldering involved. Learn more about working with the MSP430 in this how-to.

This schematic shows how we connected our MSP430 to the e-paper driver board. Click here for a full size version(PNG). The 47K resistor, MSP430, and an LED (not shown) are included on the breakout board.

We added a 32.768KHz crystal to keep time (Q1). Normally, we’d also add some capacitors to form an oscillator, but the MSP430 has built-in adjustable capacitors on P2.6 and P2.7.

We also added a button between P1.4 and P1.2 (S1). The internal pull-up resistor on P1.4 holds the button high, and we grounded it through P1.2. This isn’t the best arrangement, it would probably be wise to also connect P1.2 to ground.

We slid the MSP430 breakout board over the power and ground pins of the programming header. You can connect the clock and data pins to the header too, but we decided to route them all from the vias underneath. Remember to remove the PIC so it doesn’t interfere with signals from the MSP430.

Firmware

The clock software is written with the free demo version of the TI/IAR Kickstart C compiler included with the ez430 programmer.

The MSP430 is very low power. It uses just 220uA at 1MHz, but less than 6uA when sleeping. The key to long battery life is to keep the chip asleep as much as possible. Our clock code is written with this in mind.

We use timer_a with the 32.768khz crystal to create an interrupt twice each second. The first interrupt triggers code that configures the segments to be displayed, sends these values to the e-paper, and then sleeps for the next 0.5 seconds. While the MSP430 sleeps, all the ‘off’ segments have time to clear. The next interrupt flips the common lines the other way with a simple XOR, outputs the values, and goes to sleep for another 0.5 seconds. Next time the cycle will begin again. We don’t bother to reset the shift registers to the ‘0′ position because the refresh is constantly in flux. Segment creep isn’t a problem because we refresh every segment each cycle.

A button press triggers an interrupt that advances the time to the next 10 minutes. To set the clock, wait until the time is a factor of 10 minutes past the hour and press the button to show the correct time. A small debouncing routine ensures that only one hit is detected per button press.

Taking it further

There are some lingering questions about the e-paper panels that would be nice to answer. What is the optimal change time? Will continuous current damage the segments or waste battery power? Why did the designer use a full 16volts to trigger the panels when only 5volts are required?

Everything you need to build the clock and interface the Esquire cover is included in the project archive(ZIP). It should be possible to interface any microcontroller with the Esquire e-paper cover using the interface library and three IO pins. In a future project we plan to build a custom driver board for the unused e-paper module.

Movea has just released a version of Gyration’s wireless remote control for Windows Media Center computers. Other than the wireless mouse controls that the remote offers, one nice feature of the remote is the ability to control Windows Media Player (WMP) while your display is off.

The remote interacts with WMP, by downloading data to be displayed using it’s built in LCD screen. From here you can view songs by album or artist and even access your playlist. Prices for the remote range from $179.99 to $229.99 with an included keyboard.

After a little searching we found that Gyration had made a similar version of the remote for Dell that was packaged with the Dell XPS M2010 Based on this and a thread by [BENZONATE] on AVS Forum we put together our own remote using the following parts:

• Dell M2010 Premium Remote
• Dell RH515 wireless card
• Dell Thomson driver (EXE)
  
• USB Cable

We found our bare remote on eBay for $19.99. When we asked [Greg] at Gyration for some help on this project he explained to us that the M2010 remote will only bind (RF Connect) with the Dell RF module due to the way Dell has chosen to write its drivers; the remote will not work with any of their standard RF receivers. If you do buy the remote on eBay be aware that the remote will only work with the RH515 card.

While finding the remote was easy, trying to locate the RH515 was another story. After searching online and calling Dell’s business support staff we were able to locate and purchase the RH515 card for $10.99 including shipping on Dell’s outlet site.

Once we received our board we began to strip the wires on the included connector and paired it with our USB cable using the following:

• Red/Green to Black
• Yellow to Green
• White to White
• Black to Red

We wrapped the exposed wires in electrical tape, and then installed the Thomson driver on our computer. After plugging the board into an open USB slot, Windows quickly recognized the card and following the M2010 remote’s instruction for pairing the devices gave us a working gyration remote.

The remote’s basic Media Center functions work like any other remote, the gyration feature allows us to control the cursor as well as perform left and right clicks from the comfort of our couch. The best part is: the remote gives us the ability to select our music using the built in LCD screen.

We did experience some lag while scrolling down the list of songs, but this could have been due to our excessive button smashing. Other than the delay, the remote itself has performed great and all for less than the cost of the Movea remote.

Wondering what we did with our web server on a business card project from last week? It’s powering a giant LED graffiti wall. Animations can be user-submitted using the online designer. You can watch a live feed of user animations as well. The online interface runs on the Google App Engine for maximum scalability and resilience.

In today’s How-to we cover all the ins and outs of building your own networked graffiti wall.

Concept overview

Graffiti sequences are designed online with the JavaScript animation designer. Finished sequences are validated and stored in a database; we made database backends for PHP/MYSQL and Google Apps (Python). Sequences are syndicated from a simple datafeed API. Our mini web server retrieves animation sequences from the feed, and caches them on an SD card. Finally, the sequences are displayed on a giant LED matrix.

Large, low resolution displays
Our graffiti display is a 1 meter square, 5×5 matrix of LEDs. It’s inspired by the Daft Punk coffee table sold by Habitat a few years ago. The Daft Punk table spawned many DIY replicas, including this excellent Instructable on building a Daft Punk table. Over time, the trend morphed into several permutations, such as our “Daft Punk table” wall-hanging. Given the range of big, blinking furniture, we sought a better term than “Daft Punk table”. We came up with “large, low resolution display” or LLRD for short (pronounced ‘lard’).

The original Daft Punk table flashed randomly, or in time to music. [Mathieu Roncheau]’s replica table stored animation sequences in an EEPROM. Our first design took this a step further by storing the animation files on a FAT formatted SD card. Now, we’ve put the designer online so that we can fetch user-submitted animation sequences over the internet.

Online interface
Graffiti animations for the LLRD are created with a simple JavaScript sequence maker. Watch a live feed of user-submitted animations, or try it yourself. The graffiti sequence designer and data backends written, for PHP/MYSQL and Google App Engine, are included in the project archive.

The JavaScript graffiti sequence designer is easy to use:

• Click the boxes to toggle the LEDs shown in each frame of your animation.
• Use the arrow buttons to navigate between frames.
• The backup and restore tools provide an easy way to save your sequence locally in a text file.

“Add text frames” inserts character frames using a bitmaped font. If you hate the default font, just create a new one:

• Click the ‘edit font’ button to load the existing font.
• Make your modifications.
• Click ‘update font’ to replace the default font with the new frames.

The font array is a lookup table of bitmaps for the ASCII characters between space and Z (ASCII characters 32 to 90, ” !”#$%&’()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ”). To add a new font permanently, just paste the updated fontset in the JavaScript code following the ‘font=’ variable. The “font format” option in the backup box will generate variable formatted bitmaps that are ready to paste over the existing font.

When you’ve completed an animation, enter your name in the author box and press submit. The sequence code will be generated and sent to the server.

The online JavaScript-based graffiti designer is inspired by an offline version by [Mathieu Roncheau]. [Mathieu]’s Delphi source code and executable are archived here. Our JavaScript-based designer has a few extra features, is browser-based, and it doesn’t require you to run an unknown .exe file. Even though it’s intended to run on the web, the designer will also work from a local copy on your computer.

The script will work for any arbitrary matrix, just change the dptRows and dptCols variables to the dimensions of your LLRD.

The live viewer uses asynchronous HTTP (AJAX-ish) requests to show a streaming feed of user-submitted graffiti animations. It will try to set a cookie so that it can start with fresh sequences each time the page loads. If you don’t allow the cookie, it ‘ll just start over at 0 on your next visit.

Sequence bitmap format
The sequence builder outputs each column as an ASCII formatted bitmap. The bitmap for each column is separated by a space, and each full frame is terminated with a line feed (nr). This format was defined by [Mathieu Roncheau]’s PC sequencer program, we kept it to maintain backwards compatibility.

Bitmap data is zeroed on the upper left hand corner of the frame. The top cells of each column are bit 0, and the bottom cells are bit 4. It seems more logical to follow standard mathematical notation and use the bottom left cell as the origin, but we didn’t design the specification.

The value for each column is found by treating lit LEDs as 1 in a binary number, and converting to decimal. For example, the first column above is 10000 binary, or 1 decimal. The last column is 11111 binary, or decimal 31. You can verify our conversions using an online binary-decimal calculator.

Note that the column bitmaps are represented by ASCII equivalents of the actual decimal values. Numeric digits are encoded according to the ASCII standard, which is the actual value plus 0×30h. Further, multi-digit numbers are stored as individual characters; 24 in the example is stored as 0×32h,0×34h.

Server side
The backend is a simple piece of software that accepts animation sequences, does some validation, and saves them to a database. Stored sequences are accessible from the datafeed API.

Backend
We wrote two versions of the backend; both are in the project archive. The first is a simple PHP/MYSQL backend for low volume online LLRDs, the other is a Google App Engine/Python version that should be able to handle a bunch of Hack a Day readers.

It’s really easy to write a backend for your favorite platform. Change the graffiti designer’s submit form action to point at your backend; both versions currently POST to backend.php. Now, catch the ‘author’ and ’seq’ variables on your server and save them to a database.

Our backend performs a bit of validation to prevent attacks on the system. We implemented checks in phases so they don’t waste too many resources. First, the overall size of the submission is checked to make sure its within reason. Next, the sequence is split into individual frames and each is checked for form. If it passes validation, it’s saved to the database.

Feed API
Sequences are accessible through a simple datafeed API. The API has two variables:

http://graffiti-me.appspot.com/feed.php?max=1&last=0

• max – the maximum number of sequences to send.
• last – the last sequence read, only newer data is sent.

The datafeed begins each animation sequence with the character ‘#’, followed by an ID number and line feed. ‘#’ is an invalid bitmap value that alerts clients to the beginning of a new sequence. Clients can use the ID number with last variable of the API to get fresh sequences on each pull.

Hardware
Mini web server

We used our PIC24F mini web server as a TCP enabled client for this project. Read our previous articles to learn how to build the web server.

Daft punk table
[mrgalleta] has a great construction tutorial for the actual table part of a Daft Punk table replica. An LLRD can take many forms, though, such as our wall-hanging.

Most of Daft Punk table replica designs are controlled by a 74HCT595 (pdf) output expander and ULN2803A (pdf) transistor array. The driver board from this Instructable combines both into an easy-to-etch, through-hole PCB. Each driver board has two 74HTC595s, or 16 outputs; we needed two driver boards for our 25 cell LLRD.

The 74HCT595 is a serial output expander that’s controlled by an SPI-like interface. An update is initiated by dropping the latch line. The state of each LED (on or off) is put on the data line, followed by a pulse of the clock. Bits are put on the output pins once the latch signal returns to high. Data cascades from the data-output pin of one 595, to the data-input of the next. Read this 74xx595 tutorial for a detailed look at interfacing this device.

It’s important to note that we used the 74HCT595, and not the 74HC595. The “HCT” part works over a wide range of voltages, including the operating voltage of the mini web server: 3.3volts.

The 74HCT595 sources current, meaning we could probably run a single LED directly from each output at 3.3volts. Since most LLRDs have 2-8 LEDs per cell, operating between 5 and 24volts, we employ a ULN2803A transistor array to switch the larger load. The ULN2803A sinks current, rather than sourcing it; it switches the ground connection of the LEDs, rather than the power.

Our LLRD has two LEDs per cell, running at 20mA with a 5 volt supply and 56ohm resistor. We soldered the LEDs around a piece of cardboard, rather than etching 25 tiny circuit boards.

Connections

A 5 wire connection between the mini web server and the driver boards controls the LLRD.

Firmware
Our firmware is written in C using MPLAB and the Microchip C30 demo compiler. Learn more about programming and working with the PIC24F in our introductory tutorial. Two firmware versions are included in the project archive. The first just reads all *.seq sequence files from the SD card, the second version adds the Microchip TCP/IP stack for internet connectivity. Learn more about the Microchip SD card and TCP/IP libraries in our mini web server tutorial.

All graphics functions, including the TCP client, can be found in graffitigfx.c. The TCP client is based on the generic TCP client example that’s included with the TCP/IP stack. We followed Microchip’s cooperative multitasking approach and broke our code into small segments that share CPU time with the rest of the TCP/IP stack.

The client periodically connects to the datafeed and requests new sequences. New sequences are parsed for ID numbers, and appended to a temporary file on the SD card. The last ID detected is written to the very end of the temporary data file, and is appended to the last variable of the URL on subsequent datafeed requests. We record the ID at the end of the file to avoid repeated writes to the same sector on the SD card. Hopefully wear leveling inside a 1GB SD card is sufficient to avoid problems for the first few decades of use. If no network connection is available, the device plays any *.seq files in the root directory of the SD card.

A parser function decodes frames and sends them to the LLRD. The parser is fairly robust to errors. Bad data that makes it past the backend validation routine will be rejected at the device level without ill effect. If a few corrupt frames do manage to display, it’ll hardly be noticed amongst the other abstract patterns playing on the wall.

#define GFX_USE_TCP_CLIENT //include the TCP client
#define GFX_TCP_ONLY //only do TCP and read temp file, don't read other files on the SD card.
#define GFX_CLEAR_TEMP_ON_RESET //optionally delete the temp file on reset. good for Google App Engine...

Three defines at the beginning of graffitigfx.c control which features are included at compile time. GFX_USE_TCP_CLIENT compiles the firmware with the TCP client enabled, comment this definition for a SD card only version of the firmware. GFX_TCP_ONLY ignores any .seq files on the SD card, and only plays sequences downloaded from the web. The GFX_CLEAR_TEMP_ON_RESET option will delete the temporary sequence file on each reset; this is helpful for databases that have non-sequential record IDs, like Google’s datastore. In the future, these definitions could be changed to variables that are set by a configuration file on the SD card.

Taking it further
Our simple firmware is a stable starting point for an online graffiti wall. While we were working on this project we came up with a ton of additional features that didn’t make it into the prototype.

• Display IP address on startup.
• A configuration file on the SD card that sets the datafeed url, refresh frequency, and other variables.
• A telnet or web interface for remote configuration.
• A TCP server for direct access to the display; push animation frames from a remote PC.
• A mail client that reports errors and status information.
• Progress messages during startup and sequence downloads. SD card not present/full errors.
• Scrolling Twitter feeds.
• Your thoughts?

Don’t just read about this project, contribute some frames to the graffiti wall.

Next time we’ll introduce our final PIC24F project, an ethernet backpack for the tiny $20 color Nokia LCD knock-off from SparkFun Electronics.