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