> > When you don't have a depth of understanding, then
> guesswork is all you
> > have.  It has a low payoff, but what else can you do?

When all else fails, you can always bisect (ok, not realy always). Just
cut your program in half, identify the half in which the problem occurs
and half that part again. Proceed untill the remaining code is so small
that the problem is obvious. Sometimes the problem does not occur in
either half, that might be usefull information, or you must just make a
different cut.

I used this method a lot. It is particularly usefull when the problem is
not what you expect, like (in increasing order of difficulty):
- an interaction
- a compiler error
- a hardware logic error
- a hardware intermittent (more or less analog) error

An example of the last type: when writing to a certain memory location
the value of another location would be corrupted. This was caused by
some long address wires (~ 10cm) in combination with a high-impedance
'termination'. When some address lines were all changing from let's say
1 to 0 they would (for a short time) force a 0 onto another address line
that should have stayed 1. After some days of experimenting I reproduced
the problem in software with a few lines of code, without any clue of
the cause. With the aid of the guy who had designed the circuit and a
fast logic analyser we eventually nailed down the problem. I still
consider this the most difficult bug I ever found.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.