I'm curious about taking a look at code for existing, good
quality PI or PID control loop control over the DCO vs an
external 32kHz crystal. Not calibration code for constants to
use without change, but code runs continually to track
temperature and time variations and allows me to specify the
desired DCO rate and will hold the DCO tight up against that.

I've been using assembly code I wrote a few years ago for
locking the DCO against the 32kHz crystal source in the x2xx
family clock system using TACCR0. It's simple and it works.
The P-term and I-term constants are fixed by the shifts I use
in the code, though. Keeps the code short and fast, but I've
used it mainly in cases where I was driving 9600 bps rates
(without any UART peripheral, of course) and trying to hold
the bit times to below 1% or so variation using TACCR1. (The
9600 bps communications happens in the background.) The code
provides continuous lock, while driving the RS-232 bits on a
precision schedule, while also providing a general purpose
timer event for timing with a resolution determined by TAIFG
(4ms with the DCO rate targeted at 16MHz or so.) It fusses
with the desired DCO rate to make it an exact multiple of the
bit rate for the chosen serial rate (also selectable) so that
I'm not jittering that too... just the DCO itself. The faster
I allow the DCO to go, the less the jitter as a result. I've
been getting by fine so far (but I really should check the
errata, I bet.)

I'm interested in doing more, now. (Delta-q process
scheduling at a resolution finer than 4ms, for one thing.)
Before I go crazy recreating the work of other good people,
can anyone refer me to some decent quality examples of PI (I
may blanche at the mention of PID) closed loop control code
(in assembly or C) for the basic feature of keeping the DCO
in _accurate_ lock (yes, I am aware there will be unavoidable
jitter -- I'm caring more about long term, not short term
here) to the 32kHz crystal source?

Even more fun would be some kind of novel spread spectrum
design.... but that would just be a joy to see, not so much
that I'd use something like that right now. (Probably could
do that by making an underdamped PID loop that oscillates. ;)

Size is important, of course. Value line parts are short on
flash and ram. Later, once I check all this out I will
probably shift over to C because that's what most of the O/S
is in. And then I won't be talking value-line anymore. (Which
will push me over to CCS for a bit while I test it more --
not a bad idea.)

Mostly, I'm just curious if anyone has found (or written)
something that is impressively good in this area -- maybe
even takes into account errata on devices, etc.

Jon
Start a New Thread