[sdiy] DsPIC timer issue when used as DCO!

[karl dalen]

Hmm, the timers can trigger a ISR at rollover so it would
possible to wait for this and then change the shapers CV!

What do you think about that as a solution?
Is it possible to have that fast enough ISR's?

> 
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
> 


      __________________________________________________________
Låna pengar utan säkerhet. Jämför vilkor online hos Kelkoo.
http://www.kelkoo.se/c-100390123-lan-utan-sakerhet.html?partnerId=96915014