Re: Why yes Mr. Goodwin, I am.
K_THE_FROG said:
That's exactly the task that's been set forth before me. Any suggestions. I thought that I had the timing figured out flawlessly.
The 20mS timing isn't at all critical, it's only the pulsewidth which matters, and they vary from 0.5mS to 1.5mS.
You basically need three simple routines, one to read the A2D (and scale it accordingly), one to generate the variable pulse, and one to generate the longer delay afterwards.
Presumably you already have the A2D readign sorted?, so that's the first bit done - scale the result to give from 50 to 150 (could do 0-100, then add 50).
Then use that value (50-150) as the index in a variable controlling a loop, so it executes the loop the number of times in the variable. Inside the loop have a 10uS delay, this will give the required 0.5-1.5mS delay, with 1% resolution. Before calling this section make the output pin high, and after the section make it low again. If you wanted you could make the loop 100-300, with a 5uS delay, to give 0.5% resolution (or any combination you wanted?).
The third section just delays to make up the extra time for the 20mS, you can quite happily use a full 20mS here, like I said, it's a VERY uncritical time. You then loop back and read the A2D again, and repeat the entire loop continually.
If you wanted to get really technical, you could calculate the long delay to give an accurate frame time, adjusting it accordingly as the pulse width varies - but there's no need, it would make no difference at all to the operation of the unit.
If you wanted to get even more technical?, you could use timer driven interrupts to generate the pulses - but it's more complicated.