It is difficult to find a design that does not include one or more lower-speed serial buses such as JTAG, I2C, SPI, CAN, LIN, FlexRay, RS-232, Mil-std 1553 or a proprietary variant. Furthermore, many products are incorporating higher-speed serial buses such as USB, MIPI and PCIe for data transport.
Protocol apps have become an important scope capability for good reason. With the right scope and protocol application combination, teams can gain quick insight to resolve issues. While all major scope vendors offer protocol decode and triggering applications, the applications vary in capability. So when evaluating an oscilloscope that will include a protocol application, here are seven attributes that should be considered.
1. What protocols are supported and to what degree?
If you have ever hand-decoded waveforms, you will immediately understand the value of real-time decode. Protocol apps are typically offered as software options, and can be added to an existing scope or ordered with a new scope. So when selecting a scope, check the datasheet to see what protocols are supported on a particular scope or a specific scope family.
The datasheet will also typically have good detail on the degree of support offered. Most vendors offer free short-term trial licences. Some vendors have a previously acquired example that you can quickly load, or hook up to your own target and try out.
Pull up the application on the scope, to determine how well a particular protocol is supported. For example, if you are using SPI, what is the fastest data rate that is supported? Does the application support 2-, 3- and 4-wire SPI, or just a subset? If you are using USB 2.0, does the application support low-, full- and high-speed versions of the spec as well as HSIC? If using I2C, does the application support I2C where the read/write bit is included in the address field?
Often, there is a need to look at simultaneous decode of more than one serial bus. How well does the scope allow you to set up decode of multiple buses, navigate between buses or change which bus is being used as the trigger source?
2. How easy is it to configure for decode?
Engineers excel at problem solving. Anytime too much brain power or time is required for a task, engineers will find another, less taxing method of attacking a problem. Setting up a scope to take a protocol measurement should be something that you can do in a minute or less.
Configuring the scope for protocol decode involves selecting which channels are probing specific serial signals, and setting the threshold value for determining when the signal is high and when it is low. While the concept seems simple enough, when setting up protocol decode for a serial bus with three, four or five signals, the task becomes more complex than originally anticipated. If decode is set up for multiple simultaneous serial buses, the task becomes even trickier.
One innovative feature that some vendors offer is ‘auto setup’ for decode. After the user assigns channels, the auto setup works a bit like autoscale. It determines the correct threshold level for each signal and scales the timebase appropriately. This feature is particularly effective for users who don’t make decode measurements frequently.
3. How useful is protocol decode display?
Decode display can vary from scope to scope to a high degree. Display protocol decode for the bus you are interested in on the scope you are considering.
Annotating waveforms with decode is the most common method of displaying protocol packets. Packet content is aligned in time with parametric signal detail. Some vendors colourise packets to make it easier to determine packet sequence even with larger timebase settings when packet detail is too compressed to see detail. Some vendors decode the entire acquisition memory, while others decode only what is on the screen. Decoding only on-screen info can be problematic. If the entire packet is not displayed on the screen, the scope would not decode any of the packets, or worse, may decode a partially displayed packet incorrectly.
