On Thu, 5 Jun 2003, Wouter van Ooijen wrote:

> > I am curious about how people debug their code once they have
> > burned it
> > into the chip and it does not work correctly.  Would appreciate any
> > feedback I can get.
>
> It helps to have at least some debug output. And serial output or LCD is
> nice, but a row of LEDs or even a single LED might be enough. I debugged
> my Zero Pin Bootloader with 8 LEDs.

LED's work for relatively small projects. For bigger ones, you'll quickly
outgrow the 8 (or whatever states).

For the relatively big project that I'm working on now, I've resorted to a
combination of Serial Port "printf" debugging and simulation.

The serial port debugging is a little more sophisticated than printing
"HI". What I've done is created a rather large circular buffer into which
the program "prints" information and out of which an interrupt driven
soft-uart extracts info to send to a terminal program. The reason for the
soft uart is because the hardware one is already used. The reason for the
circular buffer is that it's simple.

For simulation, I either use special modules (gpsim not mplab) that mimick
the environment that I wish to simulate. I've also created special
simulation debug code to allow easy testing of boundary conditions.

I've also have setup the two tools to work together: the output of the
printf debugging can be used as an input to the simulator. This way I can
capture near "real-time" state information and feed it back into a
simulation where time can either be stopped or accelerated (gpsim runs
faster than my PIC).

If this project ever finishes, I'll share some of these debugging tools.

Scott

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu