[sdiy] DsPIC timer issue when used as DCO!

[Tom Wiltshire]

On 10 Dec 2009, at 16:52, Colin f wrote:

> I haven't been following this thread...
> But that picture looks to me like the change of pitch applies  
> immediately to
> the CV for the waveshaper (the timing cap charges at the correct  
> new rate
> causing the triangle wave to complete its full cycle in the correct  
> time),
> but the timer generated reset of the cap doesn't happen until the  
> end of the
> period for the old pitch.
> Superimpose another cycle of the lower pitch triangle wave in your  
> head as
> it continues - the switch to the higher pitch occurs after that cycle
> completes.

I think you're on the right track, Colin:

http://www.electricdruid.com/P08Glitch.gif

I copied the image into a graphics package, traced the original  
triangle wave on the far left, then shifted the waveform across  
horizontally to match the other.
Surprise surprise, it's a good fit. Is this a fluke or vital  
information?

> This says to me that the new pitch period is being put into a reload
> register in the timer, when it should be written to the current  
> timer value.

As far as I know, there is no such buffering on the dsPIC timers.  
However, you might get a similar effect this way:

1) Start off with a low freq. This requires a large value for the  
timer to count towards. On dsPIC this goes in the PRx register.
2) Count up towards it, but don't quite get there yet.
3) Change to a high freq. This requires a small value in PRx.  
Unfortunately, our counter is already at a value larger than our new  
PRx value, because it was counting towards the old PRx value, which  
was much larger.
4) The counter keeps counting, since it hasn't matched (the new small  
value of) PRx. It wraps round, and then eventually matches PRx and  
resets.

This would also explain why the bug happens going up and not going  
down. Going up you go from large PRx values to small PRx values,  
which makes this glitch possible. Going from a small PRx to a larger  
PRx value, it can't happen. The bigger the difference between the two  
frequencies, the more likely you are to be in the zone where the  
effect occurs. There is a small zone at the beginning of the waveform  
where the timer value is *still* less that even the new small PRx  
value where the glitch won't occur, even for massive jumps.

The ideal solution would be to work out the equivalent phase of the  
waveform when changing frequency, and then set the counter to the  
equivalent value for the new PRx value ( e.g. if we were 50% through  
the old waveform at a low freq, then we want to be 50% through the  
new waveform at a higher freq). Unfortunately this requires a  
division, which is a slow and painful operation at the best of times.  
It'd look like this:

Timer value / Old PRx value = Old phase (expressed as decimal from 0  
to 1)
New timer value = Old phase * New PRx value.

Can anyone see a better way?

Thanks,
Tom