Does anyone have any opinions/ideas on the following: I'm thinking of
creating a 1-wire serial protocol, unidirectional, for debugging PICs.
One pin on the embedded target can be spared for generic debugging
purposes but simple "blinky LED" or whatnot doesn't cut it very well.
I'd like to have at least one digit (hex, even) for display of the
embedded system's state to display on a 7-segment.  (I don't have a
logic analyzer, I don't want to hook the PIC up to my PC parallel port,
and I don't have an oscilloscope.)

So my idea is to create a real simple protocol to send, say, 4 bits
plus 1 parity on one wire, without a clock line, using different clocks
on the target and the 'debug PIC', and note that interrupts can NOT be
turned off on the target system (which is a 16F84-04) for more than a
few clocks at a time.  To make the 'debugger' even more useful it would
be nice to make it (slightly) clock independent, meaning that *unlike*
the ibutton/1-wire protocol I'd rather not define 60us delays or
whatnot in the protocol..

There are a couple ways I've already thought of implementing this..
        - require the target to send a 'syncronize' clock before each
                bit.
        - require the target to send a couple clocks as a 'start' so
                the debugger can 'measure' the operating frequency.
        - give up on the idea of disabling interrupts during the
                debug routine on the target PIC.
        - forget sending 'serial' data and send something else.
        - use an I2C-like pullup resistor so the target can sense
                when the debugger has received a bit (such as the
                debugger pulling the line low when it's ready for another
                bit to be sent).
        - if sending a couple bits works, go all the way and add a
                1-line LCD on the debugger..

There are some keys to this whole idea too..
        - speed required is only very slow, for user display
        - due to "some generic target"'s use of interrupts,
                it might be a 'very long time' before the debugger
                sees the next bit.
        - the debugger will hopefully use a PIC16F84-04.



This whole idea is kind of similar to the PIC-SPY, though more limited,
and PIC-SPY disables interrupts when transmitting (I believe).


Any thoughts on this are welcome (as are previous working
implementations!).



Jonathan Cline
jcline@ee.calpoly.edu