[sdiy] DsPIC timer issue when used as DCO!

[Neil Johnson]

Hi,

Colin wrote: 
> You're not looking at the output of a rising ramp.
> The waveshaper on the 3396 (and presumably the 397) 'folds over' the top of
> the wave once it reaches the upper limit.
> If you want a ramp wave, you apply a timing control voltage that causes the
> wave to just reach the fold over point at the end of a timer period, so you
> only get a rising ramp.
> If you want a triangle wave, you apply double the timing voltage for the
> ramp.
> That causes the wave to fold over and return almost to zero within the same
> timer period.

After pondering over this I think Colin is close.  Allow me to expand on my thoughts.

Lets refresh thanks to Tom's augmented diagram:

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

Start at the point where the triangle wave suddenly changes rate, at about 1s710.4ms.  I think that at this moment in time the control voltage, and hence integrating current, changes to a higher value, resulting in a much faster ramp rate.

A short time later, at about 1s710.5ms the wave folder kicks in and folds over the top half of the ramp to generate the triangle.

[You can see further evidence of the wavefolder at 1s707.5ms - that little dip is the ramp moving out of the wavefolder.  Also notice the slight curve at the bottom of the triangle - is this evidence of the internal current source running out of headroom (compliance?).]

At 1s711ms the folded-over ramp reaches its limit and can rise no more.  As this is folded over it looks like it has stopped at the bottom of the triangle.

Nothing happens now.  The gradual rising slope towards 0V we see is, I believe, due to the AC-coupling on the output - its your classic RC decay curve, for large R and large C.  You can see a little more evidence of this when the oscillator gets going again - notice a gradual change in the peaks after 1s725ms as the DC bias is slowly filtered out.

WHERE EXACTLY WAS THE SCOPE PROBE WHEN THIS MEASUREMENT WAS TAKEN..???  If we are looking at the final audio output on the back panel jack then we can definitely expect some AC coupling along the path.

Keep waiting.  At 1s723ms the timer reaches the 'old' period value.  If the timers are being used as a 32-bit timer then all that can happen is an interrupt or ADC being kicked.  Lets assume that is the case.

So given what seems to be happening in the diagram it is reasonable to assume that the interrupt handler itself toggles some external pin to reset the analogue ramp.  If it was also the case that the interrupt handler was also the ONLY place in the firmware that the timer was (re)configured then that would explain precisely why what happens happens.

This is not a bad thing in itself - at timer compare we know pretty much the state of the timer (its just reset, so pretty close to 0), so its a reasonable first step to getting the timer working without worrying about more complex corner cases.

If the timers are being used in 16-bit mode then the output compare module can be used to generate pulses to reset the ramp.  Except now we have even more registers to change every time the pitch changes.  I think the greater complexity would suggest it even more likely that the firmware only updates the timer/compare registers at the end of a timer period.  The minimal pitch increment would suggest whether the timer used was 16 or 32 bit.

At least, that's my interpretation on a Friday morning.  

Cheers,
Neil
--
http://www.njohnson.co.uk