I would like to add that an extremely valuable debugging tool is to keep a spare I/O pin for debugging. If you want to check when a subroutine happens or how long an interrupt takes to process you can enhance a code sequence with..

CLR Px.y

..at the beginning and followed by a..

SETB Px.y

..at the end. Then using an oscilloscope it is VERY easy to gather valuable informaton about your program.

The port pin can also be used to find out if some piece of code is actually being entered through use of the above bit toggling in the questioned code path and then use a logic probe on the pin to look for a trigger pulse.

I have even used the port pin concept to relay even more information than a simple high / low level. For example it is possible to program one path of the code with:

CLR Px.y
SETB Px.y

...and another code path with:

CLR Px.y
NOP
NOP
NOP
SETB Px.y

The pulse width difference on a scope can help to evaluate the paths taken through the code.

The overall beauty of using the port pin for debugging is that the run time overhead is very small and as such it can be fitted into real time algorithms and interrupt routines with minimal impact on performance.

One last comment. On at least one project in the past I used a port pin as a serial debug output to see the value of a byte. In this case I had 2 port pins, one was a sync pulse and the other had a fast output of 8 bits of debug data sent out in NRZ manner. It was easy to trigger the scope on the sync and read out the serial value on the other port pin!

Michael Karas