Bus Pirate review

Sparkfun Bus Pirate, top viewThe Bus Pirate: It sounds kind of shady, and maybe it is, but it is also a handy little tool. A few weeks ago, I received a Sparkfun Bus Pirate as a birthday present. This little board is a USB-to-nearly-anything serial adapter that can speak SPI, I2C, async serial (UART), JTAG, and several other protocols. It’s designed as a quick tool for easy exploration of new hardware and, yes, as a hacking tool useful for reverse engineering undocumented boards and communications protocols. It has a few limitations that hold it back from being everything it could be, but the low price makes it a worthy addition to a professional’s or hobbyist’s engineering toolbox.

The Bus Pirate was designed by Ian Lesnet at Dangerous Prototypes, and he sells his original version via his partnership with Seeed Studio. Since it is an open source hardware design, others are free to make their own versions, which is what Sparkfun opted to do. It appears that Sparkfun did their own layout, but the major components are in roughly the same locations. Both versions are electrically equivalent and run the same firmware, and both versions cost about $30 (at this writing).

Bus Pirate Hardware and Accessories

On unpacking the box, my first surprise was the Bus Pirate’s small size. That’s not a drawback in practice, but it looks more delicate than I expected. The board has a row of LEDs along the top edge for status information, a USB mini-B connector on the left side, and a header for the serial interfaces on the right side. The header is shrouded, which is a nice touch, because it makes sure polarized cables only go in one way.

Polarization is great for cables, except that different versions of the Bus Pirate orient the header in opposite directions! The Sparkfun version has the polarization notch on the outside, while the Bus Pirate documentation says that some Seeed Studio versions have the polarization notch on the inside. Although this inversion means that pin “1” moves from one end to the other, the layout of the PC board has not changed, so the pin in the lower left corner remains chip select (CS), regardless of which way the header is installed.

Bottom view of Sparkfun Bus PirateI am a little concerned about the durability of the board. One aspect is having small surface-mount components exposed, where they could get knocked off, taking their PCB pads with them. Another aspect is the choice of a USB mini-B connector. The mini-B has durability issues that has caused the USB Forum to deprecate it in favor of their other connector styles. A standard B connector would have been a better choice.
Another disappointment was the lack of PCB mounting holes, which are handy for screwing in standoffs to use as feet. holes would also make it easier to protect the board in an enclosure, such as a mint tin.  It appears that the latest Seeed Studio Bus Pirate boards (v3.5) have mounting holes.

Sparkfun and Seeed both sell breakout cables for the board. These cables aren’t strictly necessary, and in fact you might find a fistful of single-pin jumpers more useful for many purposes. The header has a few pins that can be jumpered for special purposes, such as configuring a pullup voltage in open-drain/open-collector mode. The the breakout cable may make that more awkward in some circumstances. I found the breakout cable handy, though, and I would recommend it as an accessory. The Sparkfun cable has single-pin sockets on its loose leads.  Seeed sells a version with single-pin sockets and one with mini-grabbers.

SPI Sniffing

Although I wanted a Bus Pirate for my basement hacking, the day after I received it, I took it to work. I was debugging a tough problem for which it would be useful to be able to eavesdrop on SPI traffic between a microcontroller and a peripheral. The Bus Pirate’s SPI sniffer mode seemed perfect. (I did have the option of using an Agilent mixed-signal oscilloscope, but who wants to read hundreds of bytes, in binary, from a ‘scope screen when an easier option exists?)

In principle, SPI sniffing can be done from a terminal, but in practice, an SPIsniffer utility that uses the Bus Pirate in binary mode is recommended. I downloaded the SPIsniffer and had a tough time interpreting the output. It appears that the latest version was released with debugging code that causes duplicated bytes in the output. I removed the debugging code, recompiled, and had somewhat better success.
The SPI sniffer formats its output as “[0xba(0x00) 0x5e(0x00) 0x00(0x1e)]”. The square brackets show when chip select is active, and the bytes are shown as the MOSI value followed by the MISO value in parentheses. This format is basic, but easy to read. Getting the chip select brackets in the right place is critical to interpreting SPI traffic. Many chips use the first byte after chip select as a command or an address, and the following bytes as data. Without having chip select in the right place, it can be impossible to decipher the data stream.

Unfortunately, in my application, the chip select indications were all over. When watching an initialization sequence, which should have shown chip select low for each of a series of two-byte packets, and high in-between, the Bus Pirate showed many one-byte packets and a few with up to 10 bytes. I looked for ground loop problems and other issues that might throw it off, without success. An oscilloscope showed the two-byte packets, as expected. As best I can figure, the Bus Pirate was simply unable to keep up with the data stream and got its chip select reads out of sync with its serial data reads. The Bus Pirate did not drop any data bytes, but without accurate chip select information, it was as useless as if it had.

Would The Correct Logic Level Please Stand Up?

My SPI sniffing also brought to my attention the Bus Pirate’s less than ideal logic level selection. The Bus Pirate is billed as working with logic levels “at any voltage“, and “above and below the Bus Pirate’s 3.3V supply“. I thought this meant it incorporated a level shifter that could input and output all of the major logic levels used today, from 1.5V on up. Unfortunately, the truth is that the Bus Pirate runs at 3.3V with 5V-tolerant inputs. It does have the ability to use open-drain outputs with a strappable pull-up voltage, which could be anything from 0 V to 5V, but that does not change the input thresholds, which remain at standard 3.3V CMOS levels. Unfortunately, that means that logic running at 2.5V and below is not guaranteed to be read correctly by the Bus Pirate. Logic with a 1.5V supply simply won’t work.  (In fairness, there are other pages on the Dangerous Prototypes web site that correctly describe the Bus Pirate as supporting 3.3V and 5V I/O.)

This problem could be solved by incorporating a proper level shifter into the board or, with some constraints, by replacing the 3.3V regulator with a lower voltage version. The hobbyist market for which the device was designed rarely uses I/O voltages below 3.3V, so many typical users will not notice this limitation, at least for the next few years. However, the problem makes it harder to use the Bus Pirate as a reverse-engineering tool and for developing low-voltage designs.

A USB UART

The Bus Pirate includes a UART mode that lets it communicate with asynchronous serial, just like RS-232, but at logic levels. Conveniently, I’m currently working on a project that uses asynchronous serial at logic levels, but at an unusual baud rate. This was a great chance to try out the Bus Pirate.

In addition to all of the standard baud rates, UART mode accepts direct programming of the PIC’s baud rate generator. It was a simple matter to compute the right value for my project.

Unfortunately, though I was able to generate serial at the right baud rate and verify it on a ‘scope, I wasn’t able to get the Bus Pirate to work on receive. I had some noise problems with the system, and that coupled with the I/O voltage mismatch meant the receiver picked up garbage characters. I was in the midst of bringing up a custom USB-to-async converter to fill the same role, so I didn’t have much incentive to spend more time getting the Bus Pirate to work. I have since taken the time to eliminate the noise, so maybe the Bus Pirate would work now despite the logic-level mismatch. In any event, the problems on receive were my fault, not the Pirate’s.

Documentation

The Bus Pirate “manual” is a wiki. The strong point of using a wiki is that it is easy for the developers to update. It has some drawbacks, too. Like much hypertext documentation, there is no obvious way to read it linearly like a textbook, and it can be hard to be sure you have found all of the material relevant to a particular topic. Maybe I’m showing my age, but I would have liked to be able to download and archive a PDF, or perhaps even print and bind a manual with complete instructions for the Bus Pirate.

The documentation is concise to the point of terseness at times, but I was able to find all of the information I needed. The diagrams, in particular, are well done and clearly show exactly what needs to be conveyed.

Terminal Software

For some reason, the Bus Pirate did not work well with Windows’ Hyperterminal. From the wiki and forums, it seems this is not unusual. Following the manual’s recommendation, I switched to Tera Term and did not have any further problems.

More Cool Features

So far, I have only sampled the Bus Pirate’s capabilities. Among its cool features are a bitbang I/O mode that let the PC command each pin individually. Even in the SPI and other modes, it has an auxilary output pin that might be useful for a reset, address, or secondary chip select.

The Bus Pirate has two power supply outputs, one each at 5 V and 3.3 V, on its connector. Commands from the PC switch the supplies on and off, and there is enough current available to power small circuits. Some applications require little more than a Bus Pirate, a breadboard, and the target chip.

Analog signals can be read with the Bus Pirate’s ADC input pin. Together with the power supplies, this means that the Bus Pirate can directly connect to some analog sensors as well as the more obvious one-wire, I2C, and SPI devices.

It can even speak JTAG for debugging or programming, albeit slowly. It was not designed for JTAG and has to emulate the protocol in software.

The Bus Pirate also has a logic analyzer mode. SUMP and other software compatible with the Open Bench Logic Sniffer can interface to the Bus Pirate to read a few logic channels, slowly. It’s really just a toy in this mode, but I would have loved something like it when I was a kid experimenting with 4000-series CMOS.

Conclusions

I’m happy with my Bus Pirate. It is described as being a hacker’s multitool, and I have to agree. I love my Leatherman, too! I’m going to need longer to fully understand the Bus Pirate than to grok a Leatherman, but I’m looking forward to finding new ways to use it. Especially considering the low price, the Bus Pirate is a worthy addition to any basement tinkerer’s toolkit.

Is the Bus Pirate ready for professional use? The answer is “maybe”. If you work on 3.3V or 5V systems, buy one. It’s worth having in your toolbox, and the $30 price is practically free compared to engineering hours. I’m not quite ready to order some for my bench at work, though, because everything I do is at lower voltages. The low cost may yet pull me in, though. Particularly when evaluating new parts, the Bus Pirate would be a faster and easier solution than either a microcontroller or a National Instruments DAQ.

Links:

FPGA Breakout Design Decisions

To get to my goal of a DSP-based ham radio using an FPGA as the DSP, I first need a way to prototype with an FPGA. Available FPGAs all use modern, small packages such as QFNs, QFPs, and BGAs. I can’t imagine soldering wires directly to a hundred tiny pins, so “dead-bug” construction, with the chip upside-down on a piece of copperclad board, is out. I need a breakout PCB that holds the chip and brings out its pins to something more reasonable to work with.

To get to my goal of a DSP-based ham radio using an FPGA as the DSP, I first need a way to prototype with an FPGA.  Available FPGAs all use modern, small packages such as QFNs, QFPs, and BGAs.  I can’t imagine soldering wires directly to a hundred tiny pins, so “dead-bug” construction, with the chip upside-down on a piece of copperclad board, is out.  I need a breakout PCB that holds the chip and brings out its pins to something more reasonable to work with.

Continue reading “FPGA Breakout Design Decisions”