> > about 14.75 instructions per iteration. There probably won't be enough
> > CPU bandwidth to generate the pulses and do all of the other work that
> > needs to be done as well.
>
> Maybe, maybe not. 14-instructions is limited, but there are tricks! For
> example, you don't have to compute every thing in the 14 cycles. It's

The PIC that reads the sensor currently calculates the number of pulses
and the spacing between them. It bit-bangs this over to the pulse PIC
in 5 bytes. The 5th byte at the moment holds just a direction flag, but
I've been thinking about other information it could hold. For example, if
the number of pulses is below a certain value then it could tell PIC2 that
Timer1 is acceptable as the space timer. If above, then a more complex
s/w system that can be adjusted on the fly should be used. However, it
doesn't look as though you can mix Timer and Accumulator usage, so
I'll have to pick a system and stick with it.

Scott, by "unrolling the routine" I assume that you mean it is worked
through progressively in between pulses. This how I intend to send the
data. This will work if there are enough pulses spaces in which to do it.
eg if there are only 20 pulses then you couldn't make the transfer 1 bit
at a time between pulses as there are 20 spaces to send 40 bits.
Obviously the spaces in this case are relatively huge so the whole 40
bits can be sent in one go quite comfortably. As PIC1 knows the
character of the pulse train, it can fore-warn PIC2 about how to expect
the new data to be sent

I have a feeling I will be doing a lot of IC counting today. BTW, I have
considered an AVR 2313 as "PIC2" to get the IC down to 125ns if the
calcs needed take too much time

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