If you're new to the I2C bus (or SMBus or TWI), you're probably here because you're looking for resources to get you up to speed quickly.  The Web is a great place to look, because you can find not only overviews and tutorials, but resources about the trickier parts and how to avoid or solve problems.

One of the challenges with any new learning experience is how to phrase a question when you don't know all the terminology.  Where do you start?  Forums are ok, but you're often left 'waiting for the phone to ring' and hoping an expert comes along soon.

That's where Protocol Analyzers can help.

What is a Protocol Analyzer?


A protocol analyzer is a tool, usually consisting of both hardware and software elements, that acts as an 'expert' to figure out not just what is right, but more importantly what is wrong with the communications that are happening in the specific protocol being examined.

For example, if you have a system that incorporates several I2C devices, and the system is having intermittent problems, how do you isolate the source?  Many engineers have wasted days staring at oscilloscope traces without getting to the root of the problem.

Alternately, imagine you are programming a system that uses I2C-connected memories.  Once in a while, you observe an error in the system; maybe a configuration has changed slightly.  Is the problem in the I2C memory device, or is it in your code?  You need an independent observer to help you see exactly what's coming in from the bus, compared to how you are
using (or possibly modifying) that information.  On more than one occasion, I believed the data in a serial E2 device was getting corrupted, but it turned out that it was my software clobbering the data in RAM.  Validating what happens on the bus is a much faster way to identify or rule out possible trouble sources.

An I2C protocol analyzer will not only help you identify bad data, but other implementation errors as well.  For example, under certain circustances, is your code forgetting to send a STOP?  Are you implementing a Repeated START correctly?  What is the right way to interpret a particular bus error that you're seeing, so you can recover properly?  All of these questions can be answered with the help of your personal 'expert', the Protocol Analyzer.

Sounds great, but expensive...


They usually are, but newer technology allows advancement even in the capabilities of low-cost tools, such as for I2C.  As an example, the EasyI2C(TM) protocol analyzer (www.easyi2c.com) is only $99 US, but detects and reports all possible I2C bus error conditions.  Since it embodies expert knowledge of the protocol, its reporting of bus events enables you to rapidly acquire a deep understanding of both normal and abnormal bus conditions and sequences.  Other vendors of analyzers offer slightly different capabilities (waveform display, for example), but come at a significantly higher price for those features.  In reality, waveform displays are of little use to most engineers, since they are mainly interested in the bus states themselves, and not in the precise signaling patterns that represent those states.

How is it different from a Bus Monitor?


While the term 'bus monitor' is sometimes used interchangeably with 'protocol analyzer', the two are intended to be different.  A Bus Monitor is usually designed to observe the 'normal' activity on a communication bus, but is not capable of providing an in-depth analysis detailing precisely what error is occurring; it generally just reports that 'something is wrong.'

A true protocol analyzer will assist the engineer by validating the correctness of an implementation, as well as isolate the exact source of any problems.  With tools like the $99 EasyI2C(TM) unit available, it's now easy to be sure.

(Site contents Copyright (c) 2011 R. Fries, all rights reserved)