piclist 2002\09\03\014301a >
Thread: Fitting pulses into a time slot
www.piclist.com/techref/microchip/time.htm?key=time
BY : Russell McMahon email (remove spam text)

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

<007b01c2530c\$e7c8ba80\$6d2900ca@lucy> 7bit