Analyzer was Re: KIM-1 repair advice wanted

Am 7 Oct 2005 9:29 meinte Dwight K. Elvey: It is after all a nice big hammer. Why waste time with other measures. Shure, when I originaly had my first KIM (does this sound like a book title or what?), all I had was a logic probe. I had an oscar at work, but somehow my superiors didn't feel comfortable with my intention to take it home. And yes, somehow I solved all my problems. And again yes, one could do it again like back then, but why? You already pointed out one of the real traps in ding it with just a hairpin and your brain: it takes time. Quite a lot of time. Now for the KIM, I'd just add an edge connector and clip on the probes, key in the important signal names, and at maximum 5 Minutes later I can go ahead and interpret what I'm seeing. construct some trap conditions and usualy the problem gets visible quite fast. Of course, as with every strategy to find a problem, I need to have an idea what I'm doing and what I'm looking for. I mean, checking simple things like power, certain outputs and clock signals are things to be done before. Again, without an idea what to do, a bigger hammer is only good for more pain when he hits your thump :) And there ar bigger hammers available - the next step after a LA are some ICE box, which in case of a dead KIM with an already socketed CPU might be my other coice, since it's standing right on the shelf ... and a programm run listing plus logic signal diagrams is a nice thing. In both cases, the more in information you get, the more you need to know what you're doing ... did I mention this already? To me it's the most important part. You need to know the basics, you need to know what your're doing. Otherwise all reading are senseless. A great tool doesn't make a good mechanic, and a good mechanic can still do a good job with poor tools. Still if you combine knowledge with good tools, you get a good result in less time with less effort. Comeing back to logic analyzers, I compare them on my own scale to modern programming environments. I mean, 25 years ago, I did read my flag lists (already on screen) and worked thru as many lines as possible before restarting the assembler. Today I just go for the first few lines, and when I see that there are several flags connected to the same mistake, I don't scan any further for other errors, but restart the assembler and look into the new flag list (if there's one). The new pass is shorter than the time I need to reload the output files. Now, for run time errors, I did sit down (in the old time) and tried to figure out what happens. Today, I do the same, but if I can't find a result fast, I add some debug output and see whats happening inside... Isn't that the same as with a logic analyzer? Interactive development. Not as ivory tower like as if you do everythin in your head, but usualy faster. Oh, and did I mention that you need to know what you're doing? I've seen more than enough 'programmers' adding debug lines and debug lines and searching for hours, just because they didn't have a glimps what the task was about? Always the same. Now, since I already looked onto as a whimp by most on this list, I can even top this: I do hardware development the same way. If some CPLD doesn'T work as I want, I just add debug output and attatch a logic analyzer:) Have a nice weekend Hans -- VCF Europa 7.0 am 29/30.April und 01.Mai 2006 in Muenchen http://www.vcfe.org/