Overview
My latest acquisition is the Salae Logic Analyzer. I was very tempted to get the top of the line model, the Logic Pro 16, but decided I might as well see how useful it was before splashing out that much more cash. A reasonable compromise seemed to be the Logic 8 model.
What is a Logic / Protocol Analyzer?
A logic analyzer is an instrument that captures and displays multiple signals from a digital system or digital circuit. They are used for testing or debugging digital or logic circuits. The device
connects to a PC over USB and uses the Saleae Logic Software to record and view digital and
analog signals. It operates by sampling a digital input connected to a device under test
(DUT) at a high sample rate. These samples are recorded to a sample buffer, and at the end of the
capture, the buffer is displayed in the software for review.
The following from the Logic 8 data sheet, explains where you would mostly use the device.
Logic analyzers are great for debugging embedded applications. In the most common case, a developer working on firmware for a microcontroller will write code to communicate with another component, possibly using protocols like serial, I2C, or SPI. To verify the functionality or
to diagnose errors in the firmware, a logic analyzer is connected to the digital IO used for
communication and records the activity during testing. The recording is then shown on the display
so the user can view the actual behavior of the firmware, and compare that with the expected
behavior to narrow down and identity the source of the issue – or verify that the operation is
correct.
Many oscilloscopes can perform a similar function, the advantage of the logic analyzer is that it can simultaneously display multiple signals (8 in my case) and relative timing information. The following from Radio Electronics, provides a good summary of the difference between a Logic Analyzer and an Oscilloscope.
- Provide a time display of logic states: Logic analysers possess a horizontal time axis and a vertical axis to indicate a logic high or low states. In this way a picture of the digital lines can be easily displayed.
- Multiple channels: Logic analyzers are designed to monitor a large number of digital lines. As logic analyzers are optimised for monitoring a large number of digital circuits, typically they may have anywhere between about 32 and 200+ channels they can monitor, each channel monitoring one digital line. However some specialised logic analyzers are suitably scaled to be able to handle many more lines, and in this way enable tracking and fault finding on much more complex systems.
- Displays logic states: The vertical display on the analyser displays the logic state as a high of low state. The signals enter the various channels and are converted into a high or low state for further processing within the analyser. It provides a logic timing diagram of the various lines being monitored.
Most Logic Analyzers don't allow you to analyse analogue data. The Logic 8 allows any of the 8 channels to be used for either analogue or digital analysis. The device expects an input voltage range of 0 to 5V but can handle a maximum of -25 to +25V. This is perfect for the Arduino and Raspberry Pi.
Note however that although the device wont blow up if you connect 25V, the analog input on Logic 4 and Logic 8 is limited to +0V to +5V, and will saturate (take on minimum or maximum value) outside of this range. Logic Pro 8 and Logic Pro 16 have an analog input limited to -10V to +10V, and will saturate outside of that range. So probably not so good for working with RS 232.
Protocol Analyzers decode data that has been encoded according to a particular protocol, such as SPI or I2C. The Logic software currently offers 23 different protocol analyzers. Each protocol analyzer needs to be set up to tell it what channels to use for what (e.g. SDA = channel 0, SDC = channel 1 for I2C).
Setting Up
Getting the unit working is pretty straight forward. Start by downloading the software from Salae. Then connect the unit via the USB port. One minor irritation is that you have to connect the test clips to the wire harness yourself.
This is just a matter of pushing the lead into the test clip but it requires quite a bit of pressure or it will just fall off again. I used long nose pliers to ensure that the leads stayed put.
Bandwidth vs Sample Rate
In order to accurately record a signal, the sample rate must be sufficiently higher in order to preserve
the information in the signal, as detailed in the Nyquist–Shannon sampling theorem. Digital signals must be sampled at least four times faster than the highest frequency component in the signal.
Analog signals need to be sampled ten times faster than the fastest frequency component in the signal.
Active Channels vs Maximum Sample Rate
The maximum sample rates for digital and analog recordings is limited by the available USB bandwidth.
Because of this, sampling at the maximum rate is not possible on all channels at once. Some example sample rate combinations:
- 3 channels, digital only, 100 MSPS
- 2 channels, analog only, 10 MSPS
- 8 channels, digital only, 25 MSPS
- 8 channels, analog only, 2.5 MSPS
Using the Logic Analyzer
The big question is what can I do with this kit and is it useful? To answer this question, I will use the Logic Analyzer in a few typical scenarios and see how it goes.
Test 1 - PWM
As a first test I will look at Pulse Width Modulation (PWM) on the Arduino. Actually I will use the STEMTera breadboard for this test, it is an Arduino built into a breadboard and is handy for prototyping and testing.
I've connected an LED across pin 9 and GND, with an appropriate current limiting resistor. The simple sketch below should produce a square wave on pin 9 with a frequency of 500Hz and a 50% duty cycle.
// PWM demo to test Salae Logic 8
//
// Arduino's PWM frequency is about 500Hz.
// A call to analogWrite() is on a scale of 0 - 255, such that analogWrite(255)
// requests a 100% duty cycle (always on), and analogWrite(127) is a 50% duty cycle
// (on half the time).
#define LED9 9
void setup()
{
pinMode(LED9, OUTPUT);
analogWrite(LED9, 127);
}
void loop()
{
}
Using channel 0 on the Logic 8 produces the following when I connect the probes across the LED.
As expected, we get a square wave with a period of 2 ms (1 / 500 Hz = 2 ms) and a 50% duty cycle. As a further check, I changed analogWrite(LED9, 64) to get a 25% duty cycle, and captured:
So for checking PWM duty cycle, this is a handy tool. The other thing that actually measuring the waveforms is good for is to test your assumptions. Initially, I was expecting the square wave to go from 0 - 5V, and if you disconnect the LED and measure from pin 9 to ground that is exactly what you get. However, with the LED in place and with our probes across the LED, the square wave goes from zero to approximately 2V. This is of course the characteristic forward voltage drop across the LED. To check this, I stuck the LED in the LCR tester which measured a Vf = 1.69V.
Test 2 - SPI
Next I will try out an application which uses the SPI protocol. This will test out the functionality of the protocol analyser and is something that you couldn't do as easily on a 2 channel DSO (since we are looking at 3 channels - DIN, CS and CLK).
We will use the Duinotech 8x8 LED Dot Matrix module described in a previous post. This communicates with an Arduino using SPI via the MAX7219 chip.
The Serial Peripheral Interface bus (SPI) is a synchronous serial communication interface specification used for short distance communication, primarily in embedded systems. The interface was developed by Motorola in the late 1980s and has become a de facto standard. Typical applications include Secure Digital cards and liquid crystal displays [Wikipedia].
The SPI bus specifies the following logic signals:
CLK: Serial Clock (output from master).
DIN: Master Output Slave Input, or Master Out Slave In (data output from master).
CS: Slave Select (often active low, output from master).
MISO: Master Input Slave Output, or Master In Slave Out (data output from slave) - not used in our application.
In our example, the Arduino is the Master and the LED Module is the Slave. As we are only connecting using 3 wires, communication is one way, from the Master to the Slave.
To begin communication, the master selects the slave device with a logic level 0 on the select line (CS). During each SPI clock cycle, a full duplex data transmission occurs. The master sends a bit on the DIN line and the slave reads it. For a 4 wire application the slave sends a bit on the MISO line at the same time and the master reads it. This sequence is maintained even when only one-directional data transfer is intended.
As described in our post on the 8x8 Led Matrix Module, we are controlling the module using the LedControl Arduino library. The first thing that we noticed when hooking up the Logic / Protocol Analyzer was that the clock speed appeared to be too slow. As expected, the CS line went low to kick things off.
The hardware SPI CLK on the Arduino is usually running at between 25kHz to 8MHz with a default of 4MHz. As shown in the screen capture below, we are measuring a clock frequency of about 64kHz.
This made me investigate the LedControl library in more detail. It turns out that the Library doesn't use the hardware SPI but emulates the SPI protocol using bit banging. In retrospect this is obvious since you can assign any digital input to the DIN, CS and CLK functions. Using hardware SPI these pins are set (see table 1).
A quick look at the LedControl source code shows that it is using the Arduino shiftOut() function to do most of the control of the logic lines. The syntax of the command is:
shiftOut(dataPin, clockPin, bitOrder, value)
It shifts out a byte of data one bit at a time. Starts from either the most (i.e. the leftmost) or least (rightmost) significant bit - MSB first for LedControl. Each bit is written in turn to a data pin, after which a clock pin is pulsed (taken high, then low) to indicate that the bit is available. So the clock speed will not necessarily be consistent, the pin transition happens when the data is ready - also not what I was expecting.
If you want to, you could trace every byte being transmitted to the LED module. For example the first byte of the "smile" image is 0x3C, you can see this being sent on the MOSI line in the screen shot below. The logic analyzer software allows you to search the decoded protocols which makes it easier to find a particular byte.
| Arduino / Genuino Board | MOSI | MISO | SCK | SS (slave) | SS (master) | |
| Uno or Duemilanove | 11 or ICSP-4 | 12 or ICSP-1 | 13 or ICSP-3 | 10 | - | |
| Mega1280 Mega2560 | 51 or ICSP-4 | 50 or ICSP-1 | 52 or ICSP-3 | 53 | - | |
| Leonardo | ICSP-4 | ICSP-1 | ICSP-3 | - | - | |
| Due | ICSP-4 | ICSP-1 | ICSP-3 | - | 4, 10, 52 | |
| Zero | ICSP-4 | ICSP-1 | ICSP-3 | - | - | |
| 101 | 11 or ICSP-4 | 12 or ICSP-1 | 13 or ICSP-3 | 10 | 10 | |
| MKR1000 | 8 | 10 | 9 | - | - |
Table 1. Arduino H/W SPI Pins
Conclusion
The question at the start was what can we do with a Logic / Protocol Analyser and is it useful? I have tested a couple of examples and based on this I think it will be very useful. If something is not working as expected, it may be because your assumptions were wrong. This was demonstrated very clearly above and I will be measuring my designs a lot more to ensure that the designs are doing what they should be.
Of course it also demonstrates that you don't need to understand how SPI works, to get an Arduino to talk with an 8x8 LED Module.
APPENDIX - Key Specifications - Salae Logic 8
- Eight Digital Channels
- 100 MSPS Digital Sampling (max)
- 25 MHz Max Digital Bandwidth
- Eight Analog Channels
- 10 MSPS Analog Sampling (max)
- 1 MHz Analog Bandwidth
- Recording Length Limited by Available RAM and Density of Recorded Data
- RGB LED, Customizable 24 bit Color
APPENDIX - Electrical Characteristics
