Favorite Logic Analyzer for Hobby Use

Oh, I get it - hobbyists need logic analysers. LOL

Cheers Terry

Reply to
Terry Given
Loading thread data ...

Look at the OP's signature.

Reply to
larwe

Then you're a whole lot better than I am...

I don't think I've ever had a bug, either hardware or software, that in retrospect didn't turn out to be a dumb error (as one of my professors said once when I was calling myself an idiot for using '=' when I meant '==' in a C program, "there's no such thing as a smart mistake").

But the vast majority have been found a lot faster by making a prediction of what the state of the system should be, comparing it with either a debugger (software) or scope (hardware), and using that to home in on where the mistake was. I could drink a lot of coffee while staring at a pile of code before I made the same progress.

And I still remember a race condition in a hardware design once that only manifested itself after the parts had aged several months (because the right signal had won the race very time until then); I don't think I *ever* would have found that one without a logic analyser.

--
Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
Department of Computer Science       FAX   -- (505) 646-1002
New Mexico State University          http://www.cs.nmsu.edu/~pfeiffer
                                     skype:  jjpfeifferjr
Reply to
Joe Pfeiffer

The best tool is called Ethereal, which is an IP packet sniffer. It works great on Linux, but Windows doesn't send packets across the interface if they're addressed to the local host, even if not addressed to 127.0.0.1, so there's no way to intercept them. Other than that, a combination of a good debugger and a whole lot of printf() statements.

The good news is that the problem shows up when I loop the program back on itself, i.e. have one group of xyz cells talk to another group via the network, even though both are running on the same host. That makes debugging less painful than if it only happened on a big cluster. My favourite debugger by far is the one that came with Visualage C++ for OS/2, which is the main reason why I still bother with OS/2 compatibility. (The other two reasons are sentimentality and cussedness.)

That's true, and it wasn't my first choice. The problem is that there is no EM code available anywhere that can do what I need to do--which is to design _and_optimize_ those little infrared antenna/metal-oxide tunnel junction gizmos that I've been trying to build for the last 3 or

4 years. The problem is that all the action happens down inside a 20-angstrom thick layer of nickel oxide, connected to a 1-um long antenna, connected to a 0.45 x 0.22 x 10-um silicon waveguide. (The action is a surface plasmon travelling wave going transversely to the tunnel junction, to minimize the effects of capacitance.) When you work out how many little boxes that needs, the number is not small, and neither is the run time. It has to handle metals and large dielectric contrasts, (e.g. silver on silicon, n=0.1+j10 on n=3.5+j0), so none of the nice efficient approximate methods work.

Then all of this number crunching has to be wrapped in an optimization loop, that adjusts the device geometry, load resistance, and so on to optimize the detection efficiency and modulation depth. (The manual for the SMP or uniprocessor version of the simulator is at

formatting link
if anyone's interested. I'm trying to get my mgt to let me open-source it, but without much progress so far.)

The good news is that I have good waveguides, good (optimized) antennas, and good (100 ohm) junctions all at the same time now, so I'm going to try to get some real optical data this week. If you hear happy shouting from the direction of NY tomorrow or the next day, you'll know it's me.

One of the things I love about my job is that I get to do a whole lot of different things, e.g. in the past couple of weeks I've done optical design, silicon fab, metal work, circuits, simulator-writing, evaporator overhaul, and a bunch of theory. One of the things I hate about it is that the rock doesn't move much unless I push it, and it's a _big_ rock.

Cheers,

Phil Hobbs

Reply to
Phil Hobbs

So your objection is "80 wires"? I usually build in a debug port to connect a logic analyzer, then depopulate it later. Xilinx also has some logic analyzer sorts of things that can be dropped into the FPGA. There are many ways to skin the "80 wires" problem, though usually not every address/data line is needed.

Monitors may be all that's needed (like an oscilloscope may be "all that's needed"), but using an emulator will increase productivity

10-100x. I can drive screws with a hammer too. Right tools, and all that... ;-)

Not always. Find a 1:1E12 signal integrity error. An analyzer used to trigger (or as part of) an oscilloscope can be invaluable.

I've done that sort of thing with no more than a scope (and emulator) too. Not all problems are as simple.

--
  Keith
Reply to
Keith Williams

LOL!

:-) Rich

Reply to
Rich Grise

Are you sure you don't mean "slap-and-tickle?" ;-)

--
Cheers!
Rich
 ------
"Women should be obscene and not heard."
Reply to
Rich the Newsgroup Wacko

Cheap at the price.

Jon

Reply to
Jonathan Kirwan

Seriously? You've never had to deal with a buggy part???

Just in the past few years, I've had to hunt down and then work aroudn bugs in an Ethernet controller, two UARTs, an IIC controller, and two DMA controllers.

--
Grant Edwards                   grante             Yow!  I have seen these
                                  at               EGG EXTENDERS in my
                               visi.com            Supermarket... I have read
                                                   theINSTRUCTIONS...
Reply to
Grant Edwards

;-)

I wish such a thing were built into the trigger circuitry of a scope. It would make things a bunch simpler (delayed trigger and such).

I've seen such problems mostly with communications between subsystems. Same difference, I guess.

--
  Keith
Reply to
Keith Williams

"I think someone should produce a simple box that allows you to combine

about 10 logic lines and some state-machining into an external trigger for an oscilloscope. It would be extra nice if it was low enough in cost that you can buy more than one and had some method to hook them together. "

Then who would buy logic analyzers? ;

Reply to
Too_Many_Tools

In article , Keith Williams wrote: [....]

But .. but .. but .. The hammer *IS* the right tool for driving screws.

I think someone should produce a simple box that allows you to combine about 10 logic lines and some state-machining into an external trigger for an oscilloscope. It would be extra nice if it was low enough in cost that you can buy more than one and had some method to hook them together.

I've had to chase down cases like where changing something in software makes the ADC get noisier.

--
--
kensmith@rahul.net   forging knowledge
Reply to
Ken Smith

Yes, if you designed all the parts of the system. How about a device that is hooked to a generic PC through the parallel port? I have a line of products that connect that way, using the IEEE-1284 protocol (EPP mode). I have found all sorts of bizarre defects in motherboards, such as some where the CPU fails to go into a wait state until the handshaked 1284 transfer completes! No way I can fix that, you just have to tell the customer he needs a different motherboard. The symptom was that the data presented by the PC would change in the middle of the cycle, before the slave device had given the handshake signal. This only happened on every 2% of the cycles

But, how will you tell that a commercial, off the shelf product is hopelessly defective, and can't be fixed by any external software or hardware hack? I found this out in about 10 minutes with a logic analyzer, and was able to move on to another problem that I could solve.

Jon

Reply to
Jon Elson

Yup, that'a another one I NEVER would have found without a logic analyzer. It was a microprocessor-driven controller for an editing video recorder, that I made as a product. Came back from the customer after working fine for a year. With the LA, it was clear in about 5 minutes that the load immediate instruction of the CPU was no longer moving data to a register (any register, I think). I could see the CPU fetch the instruction, then fetch the immediate data, then fetch an output instruction, and then always send a zero with the output strobe, no matter what the actual immediate value was. OK, clearly the CPU, so I replaced it, tested the unit and returned it to the customer.

Jon

Reply to
Jon Elson

Always. The more time and effort spent here, the less (at generally several times the cost) in debug.

True. However, not always are there 80 parallel connections. Sometimes a logic analyzer is handy just for tracking CLK, CS, DI and DO...

A train wreck, perhaps, but an astonishingly widely used one...

Sometimes, no amount of careful design can avoid implementation problems, especially when the available documentation is poor. I once spent several days trying to understand why an Oki codec wouldn't produce valid data at some of the bit rates the data sheet claimed it would. With a logic analyzer, I was able to figure out why - JapGlish documentation (translation problems).

More and more, I'm finding that a mixed-signal 'scope is a pretty handy tool. I'm using the digital trigger condition features of my scope fairly frequently now; I still use the ancient Tek 475 a lot though, too.

-- Mark "I prefer heaven for climate, hell for company."

Reply to
Mark Moulding

I've got an old HP 54201D scope that is exactly as you wished for. Got it at a swap meet for $50, replaced one resistor in an input channel, and now it's my primary scope. 300 MHz bandwidth, dual trace, all the usual digital trace capture/analysis stuff, and a 27-bit logic analyzer-style trigger section, including missing- and extra-bit detection. Most of the time I use it as a normal scope, but once in a while, that trigger section is *really* handy!

Reply to
Mark Moulding

This is true but the RTOS where I had found a bug thanks to an emulator was used extensively at that time. Even when I provided them with the correction I had applied they refused to implement it since as they said it would have involved too much testing.

We could not change the RTOS because the device was in a late stage of development.

Reply to
Lanarcam

If we are talking COTS procurement, then you should have at least generated some list of criteria for potential units to fulfil as a minimum. Such criteria would include performance measures and be quite specific about what was expected. If the unit (treated as a black box) did not match up to the minimum criteria, then you reject it surely.

Anyway, aside from that, I have a link, from Jack Ganssle, that may prove interesting for the participants in this thread, if you are really after logic analysers or clever scopes.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/********************************************************************
Reply to
Paul E. Bennett

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.