Tony Nixon wrote:
>>
>>James Newton wrote:
>>
>> I was wondering if the ISR could be setup to allow only one
>>instruction of the main code to execute when the ISR returns.
[snip]
>
>IRQ       bcf intcon,t0if
>          ; process anything here
>          clrf tmr0
>          decf tmr0
>          nop
>          retfie
>
>start     bsf status,rp0
>          movlw b'11000000'
>          movwf opton
...

Tony,

Your code idea looks interesting, but don't you need something like
b'11000001' (prescale TMR0 by 4) in the option register to make the
INT occur at the right time on return? Unfortunately this method
commandeers the most critical resource in the PIC - namely TMR0, but
might be worth playing with. It does clearly show how much overhead
is required to implement debug - 1 for execution, 10-to-20-to-50 for
overhead.
===============

James,

Your questions are answered. No need for fancy work-arounds. I looked
at the specs for the '87x chips, and Microchip saw the light and finally
implemented what I described yesterday was present in the 8088s since
birth - built-in debug mode.

The info is sketchy, but you set a bit in the config reg during program-
ming (like the trap flag on the 8088), load a Microchip-supplied module
in the last 100h bytes of code space (like the INT 1 ISR on the 8088),
and use RB6,7 for control (got to talk to it somehow).

When I built my own PIC Monitor chips, I specifically did not add any
Go/Step/Disassemble/etc commands like 8051 & other monitors use, simply
because the others can use external program ROM/RAM while the PIC cannot.
So instead, I built into the command set many of the other features
you've been describing the past couple of days - o'scope, logic analyzer,
reg/port read/write, PWM, generator, and pulse counter modes - and billed
it as a "1-Chip TestBench", useful for testing target hardware (external
to the cpu) before/while the firmware is being written.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom