Al Williams

Dr. Dobb's Bloggers

Logic Analyzers

January 22, 2013

I have always had a fascination with logic analyzers. I have bought and used many over the years.

My first real job designing embedded systems (an embarrassingly long time ago) was with a very small company. We had a few tools, including a much better oscilloscope than I owned at the time. What I always wanted, though, was a logic analyzer. In those days, that was a major purchase and it was simply out of the question.

The next job I had was with a big semiconductor maker. My lab had three logic analyzers in it. The fact that you couldn't possibly get enough little needles down on the die to make them useful didn't stop someone from getting them for us. Other than playing with them to learn how they worked, I never really used them in that job.

Maybe that's why I have always had a fascination with logic analyzers. I have bought and used many since. I even personally own several (including two giant Gould Biomation monsters from the 1970s or 80s that I would have killed for in that first job). Even today, the Gould machine is pretty useful if you have a lot of logic signals to look at and you don't exceed its 100MHz clock rate (which, in that time frame, hardly seemed likely).

There's two problems with these big logic analyzers. First, the Gould machines weigh something like 80 pounds and take up roughly the space of a midsize PC tower. You have to be pretty desperate — I mean motivated — to go drag one of these out and clear off a spot for it.

The second problem isn't specific to these old clunkers. I have several smaller logic analyzers (including a Sump-based one that is very similar to the $50 logic analyzer I've mentioned before. They also suffer from this second, more insidious, problem. I don't have much left to probe.

On that first job, I built a system based on a 6805 CPU (a veritable antique). It had external RAM and EPROM. It was a little shy on space, so the UART chip (yes, a separate chip) shared address space with a ROM that contained math routines. You could do math or you could talk on the phone via a modem. You couldn't do both. There was also an LCD display and a fair amount of real-world I/O, all handled by chips that connected to the address bus.

A logic analyzer would have cut at least 30% of the debugging time off that system. These days, I build much bigger systems, yet in a way they are also smaller. Even a tiny system now will have what would have passed for a lot of memory in those days. But that memory is wedged inside the chip. So are all the cool I/O devices — even the A/D converters. I don't need a 32- or 64-bit logic analyzer for these chips. I just need something to look at a few I/O devices.

Bigger systems? Anything I am going to do "big" these days will wind up on a board running something like Linux or VxWorks or some other operating system. The support tools at my fingertips are probably all I need, especially since I am unlikely to try to bootstrap up a new board — I'm just buying a commodity product.

I guess the logic analyzer vendors have noticed this too. The trend now is small (sometimes tiny) devices with fairly low clock rates and small I/O counts. There is also an emphasis on decoding the data so you can, for example, interpret serial data or read packets on a CAN bus.

Not to be left out, I went shopping for something like this the other day. The USBee is one contender. But with no supported Linux software that I could identify. The Saleae unit seems almost identical but does have Linux software. These analyzers are just the ticket for sniffing out an SPI bus or an I2C or TLL-level serial port. As I was shopping though, I got distracted as I often do.

I have written here before about a homebrew logic analyzer I built out of an unused Xilinx development board based on the Sump design. This is the same base the $50 OLS analyzer uses and there is an active software development effort for it. The LogicSniffer software is Java-based so it runs on Linux and presumably most other places. It has quite a few tools for analyzing data streams. Unfortunately, it only works with the Sump protocol or it can read from a generic file — more about this later.

You can see a few screen shots of a UART on an Arduino pumping out "Dr. Dobb's Journal" at 300 baud below. Why 300 baud? Because I hacked together some logic analyzer hardware out of a serial I/O board that happened to be on my desk and I didn't want to tax the sample rate. It took some experimenting, but I did get to where I could feed my own data into the software with only a little pain.

The other project that caught my eye was Sigrok. It is cross platform and supports lots of hardware including the USBee and even some scopes and digital meters. Combined with a plug-in architecture for decoding signals for many different protocols, it sounds perfect. Until you find that it has only very limited interfaces that are still works in progress.

The real way you will use Sigrok is to acquire data and then send it somewhere else to view. It can drop VCD files so if you are used to using GTKWave or something similar, you can feel right at home. It will even save files the LogicSniffer can read.

A great spare-time project would be to add a Sigrok input module to LogicSniffer so that you could get its very nice GUI combined with the Sigrok device support. Surely someone is at least working on this.

Do you use any logic analyzer tools? Next time I'll show you how I turned a serial I/O board on my desk into a simple 8-channel logic analyzer using the LogicSniffer software and some shell scripts. A bit later, I'll talk some more about Sigrok and what it can do for your next project.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!