On Feb 28, 2008, at 2:12 PM, Tony Duell wrote:
      In the
context of a small microcontroller like the ones we're
 talking about, these things just don't have that much code space.
 Almost none of them allow self-modifying code.  Nearly all of them
 have small, simple instruction sets.  If the programmer NEEDS to
 actually trace the firmware to find a bug, I'd question that
 programmer's competency.  Seriously. 
 OK, so I;m an incompetent programmer. I'm happy to agree to that.
 Because
 I certainly deug firmware (where possible) by hanging a logic analyser
 off the address lines and seeing where the code is going. If you
 can do it without, great!. 
 
   So do I, when I can't find a bug by reading the source code.  My
point is that these smaller processors are so simple that it's damn
difficult to write a bug that's impossible to find without wanting to
probe the internal circuitry of the chip.
  Let me give you an alaogy. _I_ once tracked down a
logic fault in a
 P850
 by noticing some odd behviour of the front panel bulbs, in particular
 that half were brighter than the other half. Knowing that it's
 really an
 8 bit machine interlally made me suspect that one half of the data
 wasn't
 being latched properly. That lead me to a missing latch strobe signal,
 and so on.
 On the other hand, most of the time I use a 'socpe and/or logic
 analyser.
 I like to debug by figuring out what the unit is doing and
 comparing it
 with what it should be doing. And I like to debug firmware the same
 way. 
   Sure, that makes sense.  But for what we're talking about, you
honestly don't think that's overkill?  I too have a logic analyzer; I
use it with some regularity and I'm comfortable with it...but in such
a simple application, it'd likely take longer to hook up all the
logic analyzer pin grabbers to the circuit than it would to find a
bug in my own code running on a tiny processor with 1KB of program
memory.
   Goal-oriented methodology isn't always a sellout.
          -Dave
--
Dave McGuire
Port Charlotte, FL