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!).
> 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..
Manchester-type encoding could simplify the timing - though not eliminate
it.
If you want to minimize the timing effects, you may want to just send
edges for the data. For example a single transition could represent a
zero and a rapid double transition could represent a one. The 'zeroes' and
'ones' could be separated by delays that are guaranteed to be larger than
the rapid double transistion of a one:
Send_a_zero:
btfss line_level,0
bsf IOPORT,IOBIT
btfsc line_level,0
bcf IOPORT,IOBIT
comf line_level,F
return
and
Send_a_one:
btfss line_level,0 ;
bsf IOPORT,IOBIT ;if the line is low coming in, then drive high
bcf IOPORT,IOBIT ;drive line low
btfsc line_level,0 ;
bsf IOPORT,IOBIT ;If the line was high coming in, then
;make it high on exit too
return
the max delay (assuming interrupts are disabled) for the rapid transition
is only two clock cycles. So it would be fairly easy to ensure that the
delay between bits is larger than this. In fact, it would suffice to do
this:
btfsc data,0
call Send_a_one
btfss data,0
call Send_a_zero
btfsc data,1
call Send_a_one
btfss data,1
call Send_a_zero
...
btfsc data,7
call Send_a_one
btfss data,7
call Send_a_zero
Though it might be easier for the receiver if there was more delay...
(warning, beware of bsf's and bcf's on ioports...)
|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.)
The normal approach I use (though I do have an oscilloscope >:*3) is
to do something like this:
SendByte:
bsf C
rlf Data,f
SendBit:
bsf OUTPUT
btfss C
bcf OUTPUT
bcf C
rlf Data,f
movf Data,f ; Test if zero
bcf OUTPUT
btfss Z
goto SendBit
return
Note that RRF's may be substituted if lsb-first ordering is desired. On a
scope, the data will appear as a series of blips, with wider blips representing
"1"s and narrower ones representing "0"s. Since the total time of either type
of bit is constant, the display on the scope is stable.
For your application, you may want to strech out the pulses somewhat (a low bit
is represented by only a 2us pulse, and there's only 3us between the end of a
high bit and the start of the next bit) but this coding scheme is quick and easy
to implement, easy to look at with a scope, and easy to decode (wait for a risin
g
edge and then look at the data a few microseconds later).
----------
> From: Jonathan <.....jclineKILLspam@spam@ee.calpoly.edu>
> 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.
Jonathan
High volume production lines often have
need to enter a maintenance mode for either calibration or debugging.
Most of these modes are triggered by grounding a nominal output
pin and resetting the processor. The MPC compiler supports this
with the __STARTUP function. If present this function is called as
soon as the processor is stable before any global variable initialization.
Code can be written in this routine to test for maintenance mode
to examine variables change them and initiate the execution of code.
The exact protocol for sending the debug data can be anyone of
those suggested elsewhere and is not critical. Most production systems
are either bit bashed serial or SPI bus.
ee.calpoly.edu
