My oldest daughter Alice has an occasional interest in electronics, and as her dad I try to encourage her without becoming too annoying. We’ve done some past projects like Snap Circuits experiments, building a Drawdio pen, and constructing an animated Halloween LED display. Recently we had a chance to build a Blinky POV from Wayne and Lane. Or more accurately I should say she had a chance to build it, since my role was limited to talking her through the steps and taking photos. It’s impressive what an 11-year-old can do with a soldering iron!

You’ve probably seen these POV blinkers before. It’s like a scrolling message display, but with only a single column of pixels. The eye’s persistence of vision reveals the message when the display is waved back and forth across your field of view. There’s not much to the hardware: just a basic microcontroller, some LEDs, and a few passive components. Wayne and Lane’s instructions are detailed and well-illustrated, and even for this relative beginner it took less than an hour to build. The microcontroller (a PIC 16F1823) comes pre-programmed with some sample messages, so you can start using it as soon as the assembly is complete.

hard at work soldering

the nearly finished board

The main reason I selected Wayne and Lane’s Blinky POV instead of another similar one was the novel method used to program it. Instead of a PIC programmer, a serial connection, or some other conventional interface, it uses a pair of photo sensors to program new messages using flashes of light. Go to the Blinky Programmer web page, design some pixel or text-based messages, and click “go”. A clever bit of javascript flashes two squares on the screen, and when the Blinky POV is held near these flashing squares, it reprograms the stored messages in about 30-60 seconds. In our experience this method was very reliable, and much less hassle than dealing with virtual serial ports or other wired interfaces. And it actually made programming fun – like magic! The web page interface is surprisingly versatile, too. You can design pixel art or text messages, adjust the scrolling speed, switch between multiple stored messages, and define what should happen at the end of each message.

reprogramming using photo sensors

This is starting to sound like a Wayne and Lane commercial, so I should probably add that I have no affiliation with them other than being a satisfied customer. If there’s a young builder in your life who might enjoy a simple but fun-filled electronics project, give Blinky POV a try.

I’m feeling pleased with myself today after fixing a dead hot air rework station. My technique? Whacking things with a wooden stick! I used the same method a few months ago to fix a dead Mac Plus, so it’s proven its worth yet again. What could possibly go wrong?

This technique is useful for electronics that were working fine, then became progressively more flaky, before finally dying completely. If you can coax a flash of life out of it by slapping the case with your palm, or rapping it with your knuckles, then you’re probably looking at a loose connection or a bad solder joint somewhere – but where? How do you find it?

In my case, I had a two year old Sparkfun Hot Air Rework Station that gave up the ghost. It started working intermittently, and would be fine one minute, but the next minute the temperature display would go dark and I’d get nothing but cold air blowing from the nozzle. For a couple of weeks I could usually “fix it” by tapping on the side of the case, but eventually it failed completely. I was prepared to throw it in the trash, but I decided to open it up first and see if I could diagnose the cause of the failure. Inside I found a lot of… parts. There was a PIC, and lots of discrete components, a transformer, and lots of cable harnesses. Nothing looked obviously damaged or burnt. Hmm.

Enter the hero of the story: a wooden stick. With the cover off, I turned on the power, and began gently tapping on all the different components. Do not use your finger or anything conductive to do this! You don’t want to short anything or electrocute yourself. When gentle tapping didn’t accomplish anything, I resorted to heavier force. Hey, it was already broken, so I couldn’t make it any worse! I finally discovered that if I gave U1 a hard shove (that’s the TO-220 just right of top-center in the photo), I could semi-reliably bring the hardware to life. The suspect was identified.

Fixing it proved to be another matter. After removing all the screws, that circuit board still wouldn’t budge. I needed access to the back side of the board to examine and troubleshoot the connections there. Again, I almost gave up and threw the thing into the trash, but persistence paid off. There are two large knobs on the front of the hot air station for controlling air flow and temperature, and it turned out that these knobs actually anchor the circuit board to the case. I had to unscrew the tiny set screw to remove each knob, then unscrew some nuts and other hardware, before I was able to get the board out. Sure enough, there was a cracked PCB trace right at U1. After a quick solder repair, the hot air station is now as good as new. Thank you, wooden stick!

And here’s why all your circuits should have some kind of reverse-polarity or over-voltage protection: I nearly killed Nibbler yesterday. I brought the hardware to a friend’s house for a nerdfest party, but when I demoed it, I accidentally plugged in the 9V AC power supply from Mozart’s Credit Card instead of the normal 5V DC supply. I’ve gotten lazy with my circuit designs, preferring to use an external regulated 5V supply instead of including power regulation on the board. Nibbler has no voltage regulator, rectifier, reverse-polarity protection, or fuse, so the 9V AC went straight to the power pins on all the chips. Baaaaaad!

Fortunately my mistake didn’t release the magic smoke from the chips. The speaker buzzed and the LCD showed some strange lines, and at first I thought a wire must have come loose during transport. It only took me about 10 seconds to recognize my error, and luckily Nibbler was fine after switching to the right power supply. If I’d left the 9V AC supply plugged in for longer, I think the board would have been toast.

Square Pegs in a Round Hole

Once Nibbler was up and running, we tried the Mastermind program that I wrote a few months back. It was a hilarious example of how six very smart guys can take fifteen minutes and a lot of arguing to solve a single Mastermind puzzle, but it also exposed some subtleties in the rules of Mastermind that I’d never considered before.

Most readers are probably familiar with the game: a codemaker chooses a four-element secret color code , and a codebreaker tries to guess it. After each guess, the codemaker gives feedback in the form of black or white pegs: a black peg means some element is the right color and in the right position, while a white peg means some element is the right color but in the wrong position. But what does that mean exactly, and what elements does it refer to?

Imagine you’re the codebreaker, and your guess is yellow-red-blue-green:

The codemaker comes back with three black pegs and one white peg:

Depending on your interpretation of the rules, you may think this is an invalid result, and the codemaker has made a mistake. After all, if three of the guesses are the right color in the right position, then there’s only one incorrect position remaining. The color guess at that position must either be correct (which would result in a black peg) or incorrect (which would result in no peg at all). Right? Wrong!

The critical question is whether the black and white pegs reflect the codebreaker’s guess with respect to the secret code, or the secret code with respect to the codebreaker’s guess. It might seem that it would be the same either way, but it’s not. Translated into pseudo-code, the two possible scoring algorithms are:

Secret-centric algorithm:

for (i in the range 1 to 4) {
    if (secretCode[i] == guess[i]) {
        emit black peg;
    }
    else (for j in the range 1 to 4) {
        if (secretCode[i] == guess[j]) {
            emit white peg;
            break;
        }
    }
}

Guess-centric algorithm:

for (i in the range 1 to 4) {
    if (guess[i] == secretCode[i]) {
        emit black peg;
    }
    else (for j in the range 1 to 4) {
        if (guess[i] == secretCode[j]) {
            emit white peg;
            break;
        }
    }
}

If we assume the secret code is yellow-green-blue-green:

and with the yellow-red-blue-green guess shown earlier, then the secret-centric scoring algorithm will result in black-black-black-white, but the guess-centric algorithm will result in black-black-black.

I think most people play the game using the guess-centric scoring algorithm, without realizing it. It seems more natural, as the score pegs are a reflection of how closely the guess matches the secret code, not how closely the secret code matches the guess. But surprisingly, I can’t find any definitive answer to which algorithm is correct. The online descriptions of Mastermind rules that I’ve found are vague on this point, or contradictory. The Wikipedia description of the rules implies both of these scoring algorithms are wrong, but isn’t specific enough to define an alternate algorithm. This page sounds like the guess-centric algorithm in its text, but the provided example uses the secret-centric algorithm. Unfortunately the official Hasbro game rules for Mastermind to Go only gives one example, which is ambiguous as to which algorithm should be used. The Parker Brother game rules are also ambiguous, and don’t give any examples. But the published rules for Pressman Ultimate Mastermind (which uses five colors instead of four) uses the secret-centric algorithm.

So how can we know which algorithm is the right one? I’m not sure we can. Mastermind is just a modern version of an old pencil-and-paper game called Bulls and Cows, which may date back more than a century. I couldn’t find anything definitive about the origins of that game or the correct rules. Ultimately it doesn’t really matter which scoring algorithm is used, as long as both players agree on it. For Nibbler I chose the secret-centric algorithm. Even though it’s less intuitive to me, it seems to be the most common choice among those people who pay attention to this quirk in the game rules. What do you think?

Here’s a handy trick I developed while searching for ways to reduce the cost and assembly time of Floppy Emu boards. The board has space for a 3 x 2 shrouded IDC header, where the AVR ISP cable should connect. But that connection is only needed once, the first time the AVR is programmed – all future software updates are loaded from the SD card using the bootloader. So why waste 75 cents and 30 seconds of soldering on a part that’s only ever going to be used once? It’s a small saving, I admit, but those savings add up.

OK, the programmer cable has a 3 x 2 female connector, and the board has an unpopulated footprint of 3 x 2 holes. Now what? My first attempt at a “no connector” solution was a straight 3 x 2 male header plugged into the cable connector, with the other end placed loosely inside the board footprint’s holes without soldering. By itself the fit was too loose, and the pins didn’t make reliable contact with the insides of the holes. If I pushed and twisted the connector with my finger, though, I could usually get all six pins to make contact long enough to successfully program the AVR. But as this only gave me one free hand, and didn’t work 100% reliably anyway, I gave up on that technique.

With board revision 1.1 I tried something new. Using Eagle, I created a staggered 3 x 2 header footprint, offsetting every other pin 5 thousandths of an inch from the centerline. I hoped this would help lock the pins tightly in place, keeping them pressed against the insides of the holes without solder and without my hand to brace it. But when the new boards came in, I was disappointed to find that while the staggered footprint was somewhat better than the original, it still didn’t work reliably. Sigh.

But every failure is just another step on the road to success! After more experiments, I finally hit upon a winning solution using a 3 x 2 right-angle header, with a small piece of scrap wedged under it for leverage. And I later found that the SD card holder is exactly the right size and in the right location to provide the necessary leverage, making for a quick and easy connection that’s 100% reliable with no soldering. I just plug one end of the 3 x 2 right-angle header into the programmer cable, and the other end into the holes in the board, with the connector and cable pressed against the top of the SD card holder. Once AVR programming is complete, I pull everything out and can re-use the parts for the next board. Hooray!

I’ve been looking at options for shipping to locations outside the United States. Wow, the choices are terrible! For comparison purposes, I’m assuming an 8 x 4 x 3 package that weighs 4.5 ounces (about 125 grams). I calculated hypothetical shipping charges to Canada, the UK, Norway, and Australia using the US Post Office, UPS, or Fed Ex. The results were not encouraging.

UPS and Fed Ex provide detailed tracking info for packages, but the costs are through the roof. The cheapest option through UPS is $104, and with Fed Ex it’s $84. These are both for 5 business day delivery – they don’t seem to offer anything slower. Hello? $100 for a four ounce package the size of my hand? Forget it.

US Postal Service Priority Mail Express International (I love these names) looks a little better, but it’s still bad. It provides package tracking information, with a cost of $33 for Canada and $48 for the other countries. Delivery is promised to be 3-5 business days. That’s a lot better than UPS and Fed Ex, but it still seems like too much money to ship a little lightweight box.

US Postal Service Priority Mail International (non-express version) is cheaper still, with a cost of $20 for Canada and $24 for the other countries if you use their small-sized flat rate box. It promises delivery in 6-10 business days. But for reasons unknown, the small-sized box is ineligible for package tracking. You have to step up to the medium-sized flat rate box for that, which then costs more than Priority Mail Express International. Thanks, but no thanks.

That finally brings us to lowly First Class Mail. This is just plain old mail, with no fancy features, and no promise of delivery speed – though anecdotally the speed is essentially identical to Priority Mail International (6-10 business days). It’s just $8.55 for Canada and $12.75 for the other countries, but there’s no package tracking or insurance. If your package disappears into a black hole in some foreign mail sorting facility, too bad.

I’m thinking that the best option may be to self-insure, charging something like $20 flat rate for international delivery and shipping via US Postal Service First Class Mail. Then I could make good on any lost deliveries out of my own pocket. Of course there’s the risk that some unscrupulous person could order 20 units delivered to Burkina Faso, then claim they never arrived, and I’d be out a lot of money.

Or I think it’s possible to get delivery confirmation with Priority Mail International, but only for some countries. And delivery confirmation isn’t the same as package tracking – if the package gets lost, it’s still lost. But at least it would protect against the guy in Burkina Faso claiming he never received his delivery.

This stuff is hard. Now I understand why real businesses use shipping logistics services!

I’ve been aware of the Bus Pirate for several years, but never had a clear understanding of precisely what it is, beyond being a serial adapter of some sort. Its name suggests a black-hat hacking tool, or maybe something for defeating DRM locks. The official home page only says “The Bus Pirate is an open source hacker multi-tool that talks to electronic stuff”, but that one sentence explanation doesn’t help very much. Links to the Bus Pirate Manual just show an advertisement, and the few “Bus Pirate for Dummies” style of guides I found weren’t super helpful either. I finally got curious enough that I decided to just buy one, and get the sense of the Bus Pirate through hands-on experimentation.

My conclusion is: it’s great! Imagine every hardware programmer, debugger, serial cable, and interface tool you’ve ever used, rolled into one. That’s the Bus Pirate. But it’s even better than that, because the Bus Pirate also offers interactive diagnostic features those other tools never dreamed of. If you like to tinker with digital electronics, the Bus Pirate is the tool you’ve always needed, without realizing how much you needed it. Here’s some of what it can do:

• program or read an AVR microcontroller (replaces the AVRISP mkII)
• program or query CPLDs, FPGAs, ARM micros, and other JTAG devices (replaces tools like Altera’s USB Blaster)
• connect to serial devices over a USB to serial connection (replaces the FTDI USB-to-serial cable)
• read or write Flash and EEPROM memory chips
• communicate with virtually any SPI- or I2C-based chip through an interactive command line console or a binary API
• passively sniff the SPI or I2C bus while other chips are using it, and record traffic
• other goodies like a low-speed logic analyzer and oscilloscope mode, raw digital (bitbang) mode, and more

To be fair, the Bus Pirate probably isn’t the best tool for any of these purposes – it won’t replace your high-end logic analyzer or expensive JTAG debugger – but it offers an amazing breadth of functions in a single device.

History

The Bus Pirate was originally developed in 2008 by Ian Lesnet for Hack a Day, and his post introducing the Bus Pirate remains the best overall summary of what it is and what it does. Ian later founded Dangerous Prototypes and took the Bus Pirate with him, releasing the design into the public domain, but continuing to improve the hardware and software with the help of others. Making it public helped build a robust community around the Bus Pirate, and today there are several companies selling variants of the Bus Pirate hardware, including Seeed Studios and Sparkfun.

Unfortunately, the public nature of the design has led to fracturing of the hardware, and some neglect of the software and documentation. For example, Dangerous Prototypes and Sparkfun use different naming conventions when describing versions of the hardware, leading to confusion when reading that a particular feature is available in version 3.5. And depending on whose Bus Pirate and cables you buy, the mapping of wire colors to signals may be backwards relative to other hardware versions. Be careful if you’re using somebody else’s color-coded wiring diagram! To confuse things further, there are also two major versions of the hardware in simultaneous development:  3.x and 4.x. The 4.x version is supposed to be the “new” Bus Pirate, but despite having been released in 2010 it’s still officially beta hardware, and new users are encouraged to buy the 3.x version. In practice, the community seems about evenly split between 3.x and 4.x hardware users.

The software and documentation suffer from not having a clear owner or maintainer. Those things take a lot of work, so it’s not surprising that a public domain project has some hiccups there, but it does make things difficult for a new Bus Pirate owner trying to get oriented. There are tons of Bus Pirate wiki pages on the Dangerous Prototypes web site, but many of them are out of date or inaccurate, or duplicates of other pages, or contradict other documentation on the site. The software harbors a few more potential points of confusion, with different sets of files contained in each firmware archive, and much ambiguity about which firmware is the right one to use.

But ultimately these are just minor bumps in the road. It may take a bit of extra reading and experimentation to get everything configured, but once the Bus Pirate is set up, it’s definitely worth the trip.

Hands On

I bought the Seeed Studio version of the Bus Pirate, hardware revision 3.x, along with the female-to-female jumper cable. Other people seem to prefer the cable with grabber probes. Consider what you’ll be connecting to most often, and buy accordingly. Or get both cables – they’re cheap. I also purchased the optional clear acrylic case. Shipping from Seeed took about two weeks to the United States.

Nokia 5110 LCD

After connecting the Bus Pirate to my PC, and installing the recommended terminal software (TerraTerm Pro), I connected to COM4 at 115200 bps and was on my way! The interactive terminal was a little daunting at first. The basic idea is to use simple text commands to choose an interface mode like SPI, I2C, or UART, configure the options for speed, pull-ups, and such, then type in data values to be sent to the device. Any incoming data from the device is displayed in the terminal window as well.

After plowing through a tutorial, my first test was interfacing with a Nokia 5110 graphical LCD. This 84 x 48 LCD has an SPI interface, and I’ve used it on several past projects. The Bus Pirate can optionally supply 3.3V or 5.0V to the connected device, so I turned on the power supplies and connected 3.3V to the LCD. The LCD’s SPI pins were connected to the corresponding pins on the Bus Pirate, and its D/C (data or command) pin was connected to the the Bus Pirate’s AUX pin. Finally, I tied the LCD’s reset pin to 3.3V.

From past experience with this LCD, I knew the magic series of command bytes necessary to initialize the display. In Bus Pirate terminal mode, they translated to:

   a[0x21 0xBF 0x14 0x20 0x0c]

   a - set the AUX pin low (puts LCD in command mode)
   [ - asserts LCD chip select
   0xNN - data bytes to send
   ] - deasserts LCD chip select, ending the transfer

It worked! After a little more fiddling around, I was able to clear the display, set the cursor position, and print the “hello” message you see in the leader photo. In this case, my experimentation merely confirmed what I already knew about the LCD’s communication interface, but if I’d never used the LCD before, the Bus Pirate could have been a life-saver. Human-speed interactive communication with an unknown device like this is a much easier way of learning its behavior, compared to writing code for a microcontroller, or building a protoype PCB.

ADXL345 Accelerometer

My second test was an accelerometer module that I bought a few years ago, then put in a drawer and never used. Unlike the LCD, I had no prior experience with this chip. The ADXL345 can operate in either SPI or I2C mode, so for the sake of variety I chose I2C. Unlike SPI, I2C devices have a unique address used for bus communications, sort of like an Ethernet MAC address. Two addresses are needed: one for writing and one for reading. I could have read the datasheet to learn what addresses are used by the ADXL345, but I’ve got a Bus Pirate! So I connected up the pins, ran the Bus Pirate’s I2C address search macro, and voila! 0xA6 write address, 0xA7 read address.

OK, to go further I did need to peek at the datasheet. I learned that internal register 0 is the product ID register, and should return the value 0xE5. To read an I2C register using the interactive terminal, the syntax is not especially intuitive. To read the product ID register the command was:

[0xA6 0x00 [0xA7 r]

You’re probably thinking something’s wrong with those mismatched brackets, but it’s correct as written.  [ sends an I2C start bit. 0xA6 0x00 identify the chip address and register number. [ sends another start bit, which is a restart, and is necessary for switching the chip from write to read mode. 0xA7 is the chip read address, and r reads a byte from register 0. Finally ] sends an I2C stop bit and ends the transfer. I ran the command, and saw happy 0xE5 come back as the read result.

Reading the datasheet a bit further, I found that the accelerometer XYZ axis data is in registers 0x32 – 0x37. It’s two bytes per axis, with the low byte first. See the screenshot for the data from my test. The first time I queried the registers, the module was lying flat on my desk, with gravity nearly aligned with the chip’s Z axis. The measured axis values were 0x0027, 0x000D, 0x00FD. For the second test, I stood the module on its edge, with gravity nearly aligned with the chip’s X axis. This time the measured values were 0xFF0C, 0x0005, 0x0001. Pretty neat!

XC9572 CPLD

For my final test, I decided to try some JTAG programming. There are three different ways to use JTAG with the Bus Pirate, so it’s easy to get confused. The first method is from an interactive terminal session similar to the SPI and I2C examples. This isn’t very useful in practice, and support for it has been removed in recent firmwares, but it’s still mentioned in the documentation. The second method is to use the Bus Pirate as a JTAG dongle with OpenOCD software. I didn’t try this, but apparently recent versions of OpenOCD have Bus Pirate support built in, but it only works if you’re running the right firmware. I used the third method: using the Bus Pirate as a stand-alone XSVF player. XSVF files are a type of pre-recorded JTAG sequence, created by the Altera and Xilinx development tools for programming FPGAs and CPLDs.

Here’s where things get a bit complicated. My first two tests were interactive terminal sessions, running Terra Term on my PC with the default firmware 5.10 installed on the Bus Pirate. The XSVF player isn’t an interactive terminal mode, though, but a binary-only API requiring different firmware for the Bus Pirate. That meant I needed to learn how to update the Bus Pirate’s firmware and replace it with something different.

Poking around on the Dangerous Prototypes site, I found links to various firmware tools and downloads, but no indication of which one I should use. My Bus Pirate shipped with firmware 5.10, which seems to be the standard, even though it’s quite old and the latest firmware is 6.3. I eventually found what I was looking for, hidden inside the firmware 6.2 download archive: a firmware image named bpv3-xsvf-vb.hex, which provides the XSVF player functionality on the Bus Pirate. But how do you talk to the Bus Pirate when it’s in XSVF player mode, and send it the XSVF file you want to play? This requires a Windows program that’s inexplicably not included with the corresponding firmware, but must be downloaded separately. One I grabbed that as well, I was finally able to get started.

I’ve had an old XC9572 gathering dust in my parts box for years, and I’ve never actually used it, because I don’t own anything that can program it. Or I didn’t until now! I used the Xilinx ISE to create a simple design for the XC9572 – just a couple of AND and OR gates to prove that it worked. I then exported this as an XSVF file, connected the Bus Pirate, ran the XSVF player, and I was in business. It wasn’t fast, taking about 30 seconds for JTAG programming what must be the simplest part in Xilnx’s entire product lineup, but it worked. I hooked up some LEDs and jumper wires to exercise my AND and OR gates and make sure everything was working as expected. Hooray, new life breathed into this old CPLD!

Conclusion

The Bus Pirate is a remarkable tool. It’s a shame that the hardware, software, and docs have become somewhat muddied and difficult to follow, but it’s worth the effort to dig through and get it working. If you’ve got a box full of single-purpose programmer/adapter devices, then this is for you. I expect the Bus Pirate will occupy the top spot in my electronics toolbox for a long time to come.