[ktownsend]

I guess it depends on the problem you are debugging. I rarely fire up my oscilliscope anymore (maybe once or twice the past year), but it's hard to replace a cheap logic analyzer when writing drivers for new sensors. You really want to see the signals going out, and the response coming in to understand if you have the I2C/SPI/I2S/etc. bus configured properly, or if the polarity is correct, etc.

A logic analyser is cheaper than a scope, and does a much better job displaying this kind of data in volume. I'd say a DMM + some equivalent to a Saleae Logic are the two tools I couldn't live without ... IF you ever have to write drivers. But so much of embedded is about interacting with other devices, and it's a common enough requirement to have to port a driver over to a new chip, etc., that I can't imagine anyone regretting buying one sooner rather than later.

You can get by with printf, clearly ... but an analyzer is worth it's weight in gold for the right problem.

[foldr]

Most of my projects are built around interfacing microcontrollers with I2C sensors. I've never had too many problems getting I2C communications working. I think a lot of it is psychological. Without a logic analyzer you can feel a bit helpless when you're not succeeding in connecting to an I2C peripheral. However, there's only a few things that plausibly can be going wrong with something as simple as I2C. (You have the wrong address, you have it wired up wrong, or you're misusing the uc's I2C peripheral.) It's quite feasible just to work through that list of possibilities until you find what's wrong. It does require a certain amount of faith, as you generally see no indication of progress at all until you get it working.

I'm not denying at all that a logic analyzer can be helpful. I'd just encourage people who can't justify the expense to have a try without one.

Edit: That said, I see that low-end logic analyzers are actually pretty cheap. I should probably get one!

[milesvp]

Low end analyzers are good for slow signals. 24Mhz is a common sampling rate for less than $30. Just remember that your bus needs to be less than half that speed, and even then the analyzer may lie to you if your bus speed is anywhere near half your sample rate. Also the timings in your bus can greatly effect what the logic analyzer will show vs what the cpu sees. I had a false positive last week when I should have just looked at the rx the cpu was seeing when trying to get an SPI peripheral working on a new chip.

So I may be in the market for a better analyzer soon. But all in all my $30 was a good investment, and has made it easier to setup new serial protocols.

[milesvp]

Word of warning. I lost several days of debugging what looked like a working serial bus using a logic analyzer. I was about to give up when a friend asked what it looked like under the scope. The problem jumped right out at me. Certain bit patterns would distort the signal and I wasn’t crossing a threshold. Solution was trivial to fix after that, just replace a pair of pull up resistors and the scope showed good squares again. Had a similar problem with an optocoupler after that. Logic analyzer hid the fact that the optocoupler was too slow, and none of the leading edges were ever square. Ended up replacing that outdated part with a similar priced newer part. My client at the time was strggling with a whole batch of these optos for a number of SKUs that were within spec, but the variance was so high that it was common to get a batch that weren’t good enough for his designs.

[HeyLaughingBoy]

Haha. I remember having exactly the opposite experience about a year ago. I was debugging serial communications with a scope and everything looked perfect. Couldn't understand why it worked at power up and stopped working a few seconds later.

However, looking at the data on a logic analyzer and being able to see several seconds of data at once showed that the external module I was trying to interface with was buggy. Turned out that the unit we had was a preproduction prototype!