Logic Analyzer uses

[ae6up]

Hi Dave,

I just watched your two part tutorial on Logic analyzers (44-45 I think).  It was great! Thanks a lot.  Your explanations of the gotchas were particularly helpful.

This may fall into the "Man that would take a lot of work category" but I'd love to see a tutorial that describes a situation where an LA is useful and then show it in use.  Not having an LA I have no idea how it could be used.  Even an absolutely elementary example would get my imagination running.

Maybe using that new Agilent scope.  (I'm not sure the ones you have have the LA option...)

Thanks!
Matthew

[alm]

It's like a scope, but the vertical axis is either 1 or 0, not the actual voltage (like a digital signal), but you have more channels (at least 8, even in an entry level LA). This is really useful because even many serial protocols need more than two channels (SPI needs four), and you may also want to monitor something else (eg. input and output). Some (the streaming USB kind like the Saleae Logic and Usbee) have a larger memory depth (you can analyze longer streams of data, like a complete transmission). They also usually have more protocol decoding options (although this is also available in mid-end scopes for $$$). Even a basic LA will usually do SPI, I²C, Async serial (like RS-232) and 1-wire (used by the DS1820 temperature sensor). Most have more. Decoding means that the protocol is shown in human-readable form (eg. Read 0x42 or N-Ack, or the byte value for async), as opposed to just pulses.

You would typically use an LA if you have issues with the contents of your digital signal (eg. timing), or if a certain I²C slave sends an acknowledgement. You would use a scope for signal integrity issues like voltage levels, noise or ringing.

[Psi]

Simply put.. Quite often when you're programming a mcu to talk i2c or spi or any protocol (especially advanced ones) you will encounter a few bugs where your micro doesn't talk to the other device correctly. Trying to find where the bug is by looking at your code can be quite hard. It's much easer to connect up a LA and see a visual representation of all your i/o lines at once
(something an oscilloscope can't do as it only has 2,4,or 6 channels and you might have a 16bit parallel bus).
Quite often when you see all your data it's a lot easier to see where the problem is.
Since LA's can understand a lot of the protocols directly, they can decode the signals and show you exactly what hex values or commands your micro is sending or receiving. You can then easy check the a datasheet to see if they're the correct commands. You can also see the relationship in timing between all your digital lines and check if any are changing state too soon or too late with respect to other signals.

[alm]

I should also add that the traditional definition of an LA is slightly different. It is a device which you can hook up to a CPU. It has specific knowledge of that CPU family, and monitors the memory bus. This allows the LA to trace the execution (since the instructions are read from RAM/ROM), and they often have inverse assembly which allows it to decode the instructions. Many of the older 'boatanchor' logic analyzers by companies like HP and Tektronix were designed for this (although they can also show raw signals, not much decoding for serial protocols in the old ones, though). IMO this is not very relevant for hobbyists these days since external memory buses are fairly rare these days for low power CPU/MCUs. It's largely been replaced by on-chip debuggers (JTAG or debugging with something like a Pickit).