Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Al Williams

Dr. Dobb's Bloggers

Non-Pavlovian Triggers

February 05, 2013

I've been playing with an inexpensive logic analyzer and some open source software to drive it lately. In fact, one of the authors of Sigrok wrote to tell me that while he didn't disagree they had some work to do on the GUI portions of Sigrok, that the latest development effort was on PulseView, not on the GUI I had been using. PulseView works at least as well as the other GUIs and the development preview version appears to have some great new features, but I could not get it to build (some libusb version issue that I haven't had time to track down).

However, the fact that Sigrok emits files I can use with other tools means that while a full-featured GUI would be welcome, the lack of one isn't a deal breaker. The broad support for hardware and the sophisticated protocol decoding makes up for the lack of a great GUI.

As I mentioned, though, don't expect Sigrok with a $15 USB probe to match capabilities with a professional-grade piece of gear. My "real" logic analyzers, for example, have the ability to adapt to different logic levels. Many of them have some form of "glitch" detection as well.

The biggest differences, though, would be in the area of clocking and triggering. By their very nature, logic analyzers are synchronous devices. Some clock signals time their data acquisition. In an ordinary analyzer, that clock often comes from the system you want to observe. Alternately, the analyzer can usually generate an internal clock (which better be at least twice as fast as the fastest thing you want to observe). The USB logic analyzer I'm using doesn't allow for any external clock. You always sample asynchronously using an internal clock.

Sigrok's triggering ability on this analyzer is similarly limited. Some of this is the hardware's fault and some is Sigrok's (there are plans to enhance Sigrok triggering in the future). Essentially, you can ask Sigrok to trigger on a specific bit pattern on a specific probe or probes. This is better than nothing, but isn't really useful in a variety of situations either.

There is one mitigating factor, however. A classic logic analyzer has a certain capture depth and you want to make the most of it. Selecting a good trigger and an appropriate clock rate means you can get the most visibility in the data you will collect post-acquisition.

With these cheap USB analyzers, it isn't such a big deal since your PC-based memory buffer is nearly infinite in practical terms. Sure, it isn't always handy to sort through a huge buffer looking for the exact segment of data you want. On the other hand, I can think of many times I was sorry I didn't set more (or less) of a trigger delay so I could see just a little bit more before (or after) the trigger event on a difficult-to-solve problem.

To illustrate, I decided to have a look at the Arduino pulse width modulation function (analogWrite). I connected the logic analyzer up to digital pin 3 (a PWM-capable pin) and digital pin 4. I wanted an easy way to mark when a PWM value changed so I toggled the bit every time through a loop that changed the PWM value. I also toggled the onboard LED. Here's the code:

void setup() {
  // put your setup code here, to run once:
  pinMode(3,OUTPUT);  // PWM
  pinMode(4,OUTPUT);  // Output for logic analyzer
  pinMode(13,OUTPUT); // LED

int i=0;

void loop() {
  PIND |= _BV(4);  // Toggle pin 4
  PINB |= _BV(5); // LED blink too
  analogWrite(3,i); // PWM output on pin 3
  i+=0x10;   // bump up by 16
  i&=0xFF;   // wrap at 255
  delay(100);  // 100mS to observe

I've mentioned before how I dislike the way Arduino obscures what's happening under the covers. Don't get me wrong, I understand that sometimes hiding a detail makes things easier. But in many cases the Arduino changes things just because it can. In this case, look at "pin 4" where the digital output comes out. It is actually bit 4 of PORTD on the chip and a fast way to toggle the pin is:

PIND |= _BV(4);

Of course, that just happens to work out that pin 4 is bit 4 on this port. Note that pin 13 is bit 5 on PORTB. This is the kind of thing that causes constant confusion. Why did I use the PIND register instead of the "correct" digitalWrite and a variable? I'll talk about that next time.

For now, back to logic analyzers. I asked sigrok-cli to grab 2 million samples at 2MHz from two probes and store them in a VCD file. I use gtkwave to look at Verilog simulation output, and I can use the same tool to examine the output of Sigrok, too. I've included the vcd file if you want to examine it yourself.

Here's the output (I aliased the signals for readability):

Notice the PWM changes on each edge of the trace signal. If you zoom in on the part where the PWM goes to zero, you'll see this:

As you'd expect, the trace width is just about 100mS. The PWM is almost always "on" with PWM output at 0xF0. Then it goes off completely at PWM value 0. The next loop will set the PWM value to 0x10 and the output goes mostly off with just a few high spikes. Zooming in further will show this even more clearly:

Not bad for a little box that cost less than a tank of gas (actually, lately I could buy four or five of these for the price of a fill up). And Sigrok certainly does the job, even if it is still a work in progress. I even coaxed it into reading from my Rigol scope, although it only outputs data from the scope in "analog" format. Here's a command line that allowed it to read the Rigol (note, you have to run as root unless you have user access to the usbtm device):

sigrok-cli --driver rigol-ds1xx2 --d timebase=500us:coupling=DC:triggersource=CH1 --frames 1 -p CH1 -O analog

The result is something like this:

CH1: 3.187500 V
CH1: 3.187500 V
CH1: 3.187500 V
CH1: 0.101562 V
CH1: 0.101562 V
CH1: 3.187500 V
CH1: 0.101562 V
CH1: 3.187500 V
CH1: 3.187500 V
CH1: 0.101562 V
CH1: 0.062500 V
CH1: 3.187500 V
CH1: 3.187500 V
CH1: 0.023438 V

It would be easy enough to write an awk script to convert this into something more interesting, or just drag it into a spreadsheet:

This was the result of opening a text file with space delimiters and creating a chart from the column B data. You could, of course, get fancier. Even more interestingly, you could do a lot of number crunching on the data. Then again, there are other ways to get scope data into the PC — what I will really be interested in is when I can tell Sigrok to interpret the data with its protocol converters.

I suppose that's it for logic analyzers for now. As inexpensive as these little boxes are, I can't imagine not having two or three sitting around for the time when I need one. They are also easier to loan out than scopes and if I don't get one back, it isn't a great loss. If you search the Web, you'll see that there are modifications to use these as signal generators as well. Granted, the I/O is probably not protected well, but blowing one of these up would be no great loss. If you have a high-power logic analyzer you still might find these convenient. If you don't have anything, these are much better than having nothing at all.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

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.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.