Searching \ for '[PIC]:Fitting pulses into a time slot' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/time.htm?key=time
Search entire site for: 'Fitting pulses into a time slot'.

Exact match. Not showing close matches.
'[PIC]:Fitting pulses into a time slot'
2002\09\02@235429 by

An application I'm working on needs a variable number of pulses
to be fitted into a 32ms window. The number of pulses can be
anything from 20 to 5000. The ideal is to completely fill up the
32ms with evenly-spaced pulses, but in practice, because this
has to be done every 32ms with new data, it is necessary to get
as close to 32ms without going over

For the first test I've tried simple division to find the pulse spacing,
but because the resolution is whole instruction cycle times, there
is a gap after the pulses. This isn't desirable because a servo in
the system stops dead at this gap and causes the mechanism to
shudder evry 32ms

As an example, take 1781 pulses to be sent out in 32ms. With an
F628 running at 18.432MHz, 32ms is 147465 instruction cycles (IC)
@ 217ns per instruction

147465 / 1781 = 82.798989 IC

1781 * 82 = 146042 IC = 146042 * 0.217ns = 31.691ms, or a 309us
gap before the first pulse of the next burst. 309us is too long

I'm thinking that if the number of pulses is broken down, say 19:1 then
this could reduce the gap eg

147465 / 1781 = 82.798989
(1781 * 0.95) * 82 = 138744 IC    (first set of pulses at 82 IC spacing)

147465 - 138744 = 8721             (find number of ICs left)

8721 / (1781 * 0.05) = 97.9887 IC    (1781 / 0.05 = 89)

If 97 is used then this takes 8633 IC, leaving a (88 * 0.217ns) = 19us gap
If 98 is used then this takes 8722 IC, too long

There is time to work out exactly how long the two batches of pulses
will take to send out, and if necessary some "fudge factor" could be
employed to get as close as possible to the 32ms. eg is one IC over
then cut one or a few out. Rounding and INT values will have to be
properly accounted for too. The inaccuracies become more likely
as the number of pulses increases, and at low numbers, say a few
hundred or so, a no-pulse gap may be indistinguishable from a
legitimate gap. The aim is to keep the pulsess coming regularly so
that the motor doesn't stop abruptly

I have a hunch that this approach will work, wonder if anyone has a

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

0.    I'll bring this up to the top

> 147465 / 1781 = 82.798989 IC
>
> 1781 * 82 = 146042 IC = 146042 * 0.217ns = 31.691ms, or a 309us
> gap before the first pulse of the next burst. 309us is too long

I think there is woolly thinking here.
It's fine to chop 82.798989 down to 82 (although upping it to 83 seems
better) BUT having done so you surely shouldn't stick with 1781 pulses -
surely you provide extra pulses in the same period. This MAY mean you have
too many pulses so your "servo" (which sounds more like  a stepper?) is past
its desired point, but can't you compensate for this when calculating the
next period? Which sort of brings us to 1. IF you did this the error left
over is, at most, slightly less than the length of a single current pulse.

1.    Why not have a "remainder" or a "borrow" which is factored into the
next period. I could expand on that if needs be but that may be enough to

2. I suspect that a sudden change at the boundary is less than ideal and
that grading the response part way through so that it approaches the next
value would be more useful than harmful. But maybe not. Say you were
producing 1781 x 18 uS pulse pulses and knew in advance that the next period
would need 21 uS pulses and that you would  also have a 309 uS period "left
over" at the end. At 309 cycles before the end you increase the pulse length
to 19 uS and 'eat up" the extra 309 uS a uS at a time.

3.    Mixing the above with your original example. If you have to hand about
for eg 309uS why not do it 1 uS at a time at the end of the last 309 pulses?
This could apply even if you were then going to SHORTEN the next set of
pulses. I would however think that it would be better to adjust your pulse
lengths in this set so that you stepped the last N of them up or down in
length in the same direction that you were going to go at the end of the
set.

If this is driving a moving mechanical anything then smoothly varying the
pulse length so it blended smoothly in to the mean length of the next set
would seem to make great sense. Even a linear ramping of the lengths would
seem to be much better than a sudden step.

But maybe I have got entirely the wrong bull by the horns ? :-)

Russell McMahon

> An application I'm working on needs a variable number of pulses
> to be fitted into a 32ms window. The number of pulses can be
> anything from 20 to 5000. The ideal is to completely fill up the
> 32ms with evenly-spaced pulses, but in practice, because this
> has to be done every 32ms with new data, it is necessary to get
> as close to 32ms without going over

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

I think you can probably do it with an accumulator.  Then add in a number,
such that you generate a pulse each time the accumulator overflows.  The
remainders are taken care of automatically.
David

Jinx wrote:

{Quote hidden}

--
David Harris
Discussion egroup: http://groups.yahoo.com/group/OmniPort
Swiki:  http://omniport.swiki.net/1

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> I think you can probably do it with an accumulator.  Then add in
> a number, such that you generate a pulse each time the accumulator
> overflows.  The remainders are taken care of automatically

==============================================

One method I thought of for an F877 is to use Timer1 to generate
the space and T0CKI + Timer2 to count pulses (using the roll-over
flags). Presently with the F628 I use Timer1 and simple decrementation /
testing for the number of pulses. I'm not particularly fussy how it's done
as long as it's calculable, repeatable and reliable

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> > 147465 / 1781 = 82.798989 IC
> >
> > 1781 * 82 = 146042 IC = 146042 * 0.217ns = 31.691ms, or a
> > 309us gap before the first pulse of the next burst. 309us is too long
>
> I think there is woolly thinking here.
>
> It's fine to chop 82.798989 down to 82 (although upping it to 83 seems
> better)

It really depends on whether that takes it over 32ms. If not then I don't
see an advantage to either, as long as one knows what it is

> BUT having done so you surely shouldn't stick with 1781 pulses -
> surely  you provide extra pulses in the same period. This MAY
> mean you have too many pulses so your "servo" (which sounds
> more like  a stepper?)

No, servo. Position is critical. If baby wants 1781 pulses, baby gets
1781, no more no less

> its desired point, but can't you compensate for this when calculating
>  the next period?

You could, but what's to say you don't end up doing that every 32ms
and never catch up ? I'm sure the correct number of pulses can be
sent in the allotted 32ms. Even at the maximum expected rate of
5000 ( = 6.4us = 24.9 IC) this is plenty of time to make an adjustment
to the timing of a "fill-in" batch of pulses

> 2. I suspect that a sudden change at the boundary is less than ideal
> and that grading the response part way through so that it approaches
> the next value would be more useful than harmful. But maybe not.
> Say you were producing 1781 x 18 uS pulse pulses and knew in

Problem. You don't know in advance. Ramping up/down to the next
value would be wonderful and very desirable, if you knew what it is.
But I haven't got a crystal ball. My step-father has ceramic knees though

> 3.    Mixing the above with your original example. If you have to hang
> about for eg 309uS why not do it 1 uS at a time at the end of the last
> 309 pulses? This could apply even if you were then going to SHORTEN
> the next set of pulses. I would however think that it would be better to
> adjust your pulse lengths in this set so that you stepped the last N of
> them up or down in length in the same direction that you were going to
> go at the end of the set.

That's not a bad idea. As I said, there's time to work out how long
the pulses would take to send using an integer number of ICs. If
there were 1781 pulses to send @ 82 IC each and there would
therefore be 309us left to fill, then adding one IC @ 217ns to 1424
pulses would fill the time. One potential problem might be the
overhead of s/w within the pulse loop, but it sounds feasible

Yes, I am thinking of changing to a 20MHz crystal ;-)) 200ns is so
much easier on the maths than 217ns

> If this is driving a moving mechanical anything then smoothly varying the
> pulse length so it blended smoothly in to the mean length of the next set
> would seem to make great sense. Even a linear ramping of the lengths
> would seem to be much better than a sudden step

Exxactly. But as the next value is unknown there's no way to ramp
up or down to it. I think the best I can hope for is to supply as smooth
a train of pulses as possible with the minimum break between bursts
>
> But maybe I have got entirely the wrong bull by the horns ? :-)

No, you did very well. Apart from the looking ahead thing

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

>No, you did very well. Apart from the looking ahead thing

Is it not possible to delay the pulse train by a complete 32mS period? By
this I am thinking that if you got the data for the first 32mS pulse train,
and delayed sending that until the data for the second pulse train came in,
then you do the look ahead thing. Is a 1 time slot delay acceptable when
starting out?

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> Is it not possible to delay the pulse train by a complete 32mS period?
> By this I am thinking that if you got the data for the first 32mS pulse
> train, and delayed sending that until the data for the second pulse
> train came in, then you do the look ahead thing. Is a 1 time slot
> delay acceptable when starting out?

The sequence is -

(1) power-up
(2) sensor reading by PIC1 using 32ms IRQ
(3) sensor data ready within ~25ms
(4) at next PIC1 IRQ send data to pulse-generating PIC2
(6) back to (2)

The intention with data transfer is to dovetail bit-banging during
pulse spacing, with the desired result being that PIC2 can be
supplied new data concurrently with the outputting of the current
pulse burst. Delaying the data transfer by one more 32ms period
will probably be too much, even if that makes look-ahead possible,
as at 32ms the response of the motor to the sensor is already
retarded a little too much. Unfortunately the sensor does not have
a reliable "ready" time and 32ms is the minimum safe time to wait
and I'm stuck with it

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> a reliable "ready" time and 32ms is the minimum safe time to wait
> and I'm stuck with it

"minimum" should read "optimum". Faster IRQs can cause clashes
between the sensor responding and PIC1 trying to read it. Slower
IRQs mean too long a delay before data gets sent to the motor

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> The sequence is -
>
> (1) power-up
> (2) sensor reading by PIC1 using 32ms IRQ
> (3) sensor data ready within ~25ms
> (4) at next PIC1 IRQ send data to pulse-generating PIC2
> (6) back to (2)

Seems to me that some sort of predictive algorithm (which is partially what
I have been drivelling about already) will allow you to live in the past but
take note of the present in order to attempt to predict the future. Sounds
more like magic than engineering :-)

How would PID or a subset fit in here?

Also, someone mentioned an accumulator system. Here is perhaps one version
of what they had in mind.
1.    Calculate a number of cycle that you want to fill and place this value
in an accumulator.
2.    Work out how long each pulse must be in uS (or cycles or whatever),
set your timer to this value
3.    Until one processing period (32 ms) is over
Subtract X uS from the accumulator at each pulse.
4.    At the end of the cycle the accumulator will be positive or negative
(or zero if you are highly lucky). Get new value, calculate new number of
required cycles and add to accumulator. This adds to the error signal
remaining from last time. The new value depends on the new result and the
error from processing the old result.

2. again .... ie calculate the new pulse lengths required each time and
continue.

RM

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> Also, someone mentioned an accumulator system. Here is perhaps
> one version of what they had in mind.

> 1.    Calculate a number of cycle that you want to fill and place this
value
{Quote hidden}

OK, I thought I understood. But the new data arrives at exactly 32ms
intervals. If you had 1781 pulses @ 82 IC, the pulses would run out with
1423 IC left in the accumulator and no new data for another 309us after
the last pulse. ??????? Wouldn't that system work only if you delayed
output by a further 32ms so that you had two sets of data to work with ?

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> An application I'm working on needs a variable number of pulses
> to be fitted into a 32ms window. The number of pulses can be
> anything from 20 to 5000. The ideal is to completely fill up the
> 32ms with evenly-spaced pulses, but in practice, because this
> has to be done every 32ms with new data, it is necessary to get
> as close to 32ms without going over
>
> For the first test I've tried simple division to find the pulse spacing,
> but because the resolution is whole instruction cycle times, there
> is a gap after the pulses. This isn't desirable because a servo in
> the system stops dead at this gap and causes the mechanism to
> shudder evry 32ms

Sounds like the pulse rate controlls the speed of a servo (like a stepper
motor?), that the total number of pulses must be correct, that they should
come "smoothly", and that you get new speed information every 32mS.  Why not

Assuming the above is true, I would low pass filter the input value, and
adjust the pulse *frequency* several times per input value.  Since the pulse
generator is always running, it is always producing a continuous stream of
pulses.  Only its frequency will change occasionally.  These changes are
made less abrupt by filtering the input value, and by adjusting the output
frequency "often", like every few mS or so.  You also keep track of the
total number of pulses that should have been emitted minus the total number
that were actually emitted.  This feeds back into the filtered value to
guarantee no long term errors.  This scheme will instroduce a short lag in
the step response, but it should be possible to get that less than one 32mS
data time.  Since this is driving a mechanical system, it probably won't
matter, but you would have to decide that.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> Exxactly. But as the next value is unknown there's no way to ramp
> up or down to it.

How much of a lag can the system tolerate?  Can you always stay one value
behind so that you do know the "next" value?

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> OK, I thought I understood. But the new data arrives at exactly 32ms
> intervals. If you had 1781 pulses @ 82 IC, the pulses would run out with
> 1423 IC left in the accumulator and no new data for another 309us after
> the last pulse. ??????? Wouldn't that system work only if you delayed
> output by a further 32ms so that you had two sets of data to work with ?

No. Keep on subtracting so that you have sent too many samples. At the end
of the time the negative error in the accumulator reduces the amount you are
required to send next time. The new calculation is based on this result.

RM

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

On Tue, 3 Sep 2002, Jinx wrote:

> > I think you can probably do it with an accumulator.  Then add in
> > a number, such that you generate a pulse each time the accumulator
> > overflows.  The remainders are taken care of automatically
>
>
> ==============================================
>
> One method I thought of for an F877 is to use Timer1 to generate
> the space and T0CKI + Timer2 to count pulses (using the roll-over
> flags). Presently with the F628 I use Timer1 and simple decrementation /
> testing for the number of pulses. I'm not particularly fussy how it's done
> as long as it's calculable, repeatable and reliable

The accumulator, or more accurately phase-accumulator, works with the
reciprocal of the IC/pulse ratio.

For example, so far the discussion has been mostly around the number of
Instruction Cycles (IC) per pulse or IC/pulse. Using integer arithmetic
you'll quantize this ratio to an integer. Unfortunately, the tiny error in
the quantization accumulates into a large error after repeated additions.
So the phase accumulator works by keep track of these tiny errors, i.e. it
accumulates the error, and when the accumulated value reachs a threshold

In this particular application you present the example of 1781 pulses in
147465 instruction cycles (the total instructions in 32 ms for your
particular crystal). The instruction cycles per pulse ratio is:

147465/1781 = 82.79

As you noted in the original example, the .79 fractional part is a
nuisance. Now, suppose you look at the reciprocal:

1781/147465 = 0.0120774

You still have a fraction - but let's ignore that for the moment...

Suppose you were able to add 0.0120774 to a variable every instruction
cycle. If the variable (phase accumulator) starts off at zero, then in 82
cycles the count will be 0.99035 and in 83 would be 1.0024. When the phase
accumulator exceeds 1.0, toggle the pulse and subtract 1.0 from the
accumulator. Now the accumulator is 0.0024. Repeat this process. Most
pulses will be 83 instructions wide. However, occasionally the accumulated
error will bias the phase accumulator such that for some iterations the
pulses will be 82 cycles!

In this particular example, the 0.79 remainder in the division of
147465/1781 means that roughly 8 out of 10 pulse will be 83 cycles wide
and 2 out of 10 will be 82 cycles wide. For example, the first few
iterations of the phase accumulator would yield:

pw  phase
-----------
83   1.002427
83   2.004855
83   3.007283
83   4.009711
82   5.000061  <== shorter pulse

In other words, whenever the fractional portion exceeds 0.012077 you lose
one instruction cycle!

There are a couple of practicle issues here.

- dividing by 147465 (or however many cycles are in 32 ms ) can be
simplified by multiplying by the reciprocal - it's a constant

- Rolling over at "1.0" isn't too useful. It's easier to scale the
numbers so that you rollover at 2^n

- Getting single instruction cycle precision delays is tricky.
(see the PWM code on my web page). If you can use TMR1, then
you could write an interrupt routine that will reload the
period register at every cycle.

Scott

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

Hi-
This is what I had in mind.  Thanks Scott for doing a better job than I can!
David

Scott Dattalo wrote:

{Quote hidden}

--
David Harris
Discussion egroup: http://groups.yahoo.com/group/OmniPort
Swiki:  http://omniport.swiki.net/1

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

Scott Dattalo <scottDATTALO.COM> wrote:
> The accumulator, or more accurately phase-accumulator, works with the
> reciprocal of the IC/pulse ratio.

I, too, briefly considered proposing a DDS architecture. However, a few
quick calculations revealed that it probably isn't workable.

The highest freqeuncy to be generated, 5000 pulses / 32 ms = 156.25 kHz,
means that the sample rate of the DDS needs to be at least 312.5 kHz.
With an instruction rate of 18.432 MHz / 4 = 4.608 MHz, this allows only
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.

-- Dave Tweed

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

On Tue, 3 Sep 2002, Dave Tweed wrote:

> Scott Dattalo <scottDATTALO.COM> wrote:
> > The accumulator, or more accurately phase-accumulator, works with the
> > reciprocal of the IC/pulse ratio.
>
> I, too, briefly considered proposing a DDS architecture. However, a few
> quick calculations revealed that it probably isn't workable.
>
> The highest freqeuncy to be generated, 5000 pulses / 32 ms = 156.25 kHz,
> means that the sample rate of the DDS needs to be at least 312.5 kHz.
> With an instruction rate of 18.432 MHz / 4 = 4.608 MHz, this allows only
> 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
possible to distribute processing across many 14-cycle slots. I assume
that a minimum 16-bit arithmetic will be required. 6-cycles will be
required for the phase accumulator and addition 2 (or three) for examining
roll overs. 2 more cycles are required for looping. This leaves only
3-cycles! However, if you unroll the loop then the 2-cycle loop overhead
can occur once for every, say, 32 accumulation intervals. This give
roughly 5-cycles per accumulation interval for doing other stuff.

Here's an extreme example of only 1-cycle available per iteration:
www.piclist.com/techref/microchip/pulsewidth-sd.htm
(it's pulse width measurement and not a pulse generator, but the same
conceptual programming approach is applicable.)

Scott

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> > 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
piclist-unsubscribe-requestmitvma.mit.edu

part 1 499 bytes content-type:text/plain; (decoded 7bit)

Hi Jinx!

I have a stupid question:
For what heck do you use timers in Timer mode?
Use them as counters. Calculate next value using
"Hardware 8x8 Multiplier", then poll this value
of timer(in counter mode). Do not want polling,
use CCP with TMR3. Max gap value would be about
few instructions.
Sorry if I'm wrong: it's too deep night(or too
early morning, I don't know).

Mike.
-------
PS: I assume 18XXXX are delivered to Australia
by this time.

part 2 2230 bytes content-type:image/jpeg; (decode)

part 3 105 bytes
--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

>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

or maybe an 18F452 at 40MHz ?

--

> I have considered an AVR 2313 as "PIC2" to get the IC down to
> 125ns if the calcs needed take too much time
>
> or maybe an 18F452 at 40MHz ?

AFAIK supply is a potential hurdle - last time I looked (for part
of this job actually) 18F were on a fairly long lead time and also
not available singly, unlike AVR. Whilst I'd like to move on to the
newer PICs, now is not the right time to outlay on a tube. I'll be
fails then I'll go to something faster

--

> > or maybe an 18F452 at 40MHz ?
>
> AFAIK supply is a potential hurdle - last time I looked (for part
> of this job actually) 18F were on a fairly long lead time and also
> not available singly, unlike AVR. Whilst I'd like to move on to the
> newer PICs, now is not the right time to outlay on a tube. I'll be
> fails then I'll go to something faster

www.voti.nl/shop/products.html#PIC-18F452
http://www.phanderson.com/ordering_1.html
http://www.dontronics.com/cat_hard_micro_pic.html

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--

Jinx <joecolquittCLEAR.NET.NZ> wrote:
> > > 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

Yes, I thought about that as well. One of the best examples of that is the
PIC weather station (http://www.dtweed.com/circuitcellar/caj00032.htm),
where a single PIC16C56 takes wind measurements and generates an NTSC video
signal on the fly to display the results.

> 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.

Ah, I didn't catch on to the fact that there are two PICs. I thought one
was doing everything. If one is dedicated to doing the pulses, then the DDS
is probably a very viable approach.

> 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.

Not between pulses, but rather between iterations of the DDS algorithm,
which runs at a constant rate.

If the DDS code requires, say, 10 out of every 14 instruction cycles, you
could "unroll the loop" by making something like 32 copies of the 10
instructions, placing 4 NOPs between adjacent copies to make the timing
come out right (except after the last copy, where you have two NOPs and a
GOTO to the top of the loop).

You end up with a loop of 447 instructions, 126 of which are NOPs. Now, you
start replacing the NOPs, one for one, with the instructions that do the
other work that needs to get done. You have to be really careful about how
you do conditional branching in order to keep the DDS timing consistent.
Sometimes you need to make extra copies of some of the iterations in order
accomodate the program logic.

-- Dave Tweed

--