uC clock question

[[email protected]]

Does there exist a uC of any kind where the clock source is selectable
from code? With the PICs you have to choose the clock source at program
time by burning fuses, and you are stuck with it. Yes the watchdog uses
an internal RC but when it counts down the PIC wakes up with the
programmed oscillator type.
Here's my dilemma: I am using the clock generated by a genlock PLL to
drive the PIC. When the video is gone, the PLL loses lock and its VCO
output is then unknown to me. However the fact that HSYNC is gone is
known, so I'd like to select an internal RC clock for the uC before the
VCO goes out of spec.
Yeah, it's not a great design, but it's a personal challenge to me and
it's not a commercial product.
Also (heh heh), since the PIC is being fed by the PLL, it is also
acting as the feedback divider... I like this clever (imho) way saving
of parts, and the clock is allowed to have jitter.

 

[martin griffith]

On 28 Apr 2006 09:27:49 -0700, in sci.electronics.design

Does there exist a uC of any kind where the clock source is selectable
from code? With the PICs you have to choose the clock source at program
time by burning fuses, and you are stuck with it. Yes the watchdog uses
an internal RC but when it counts down the PIC wakes up with the
programmed oscillator type.
Here's my dilemma: I am using the clock generated by a genlock PLL to
drive the PIC. When the video is gone, the PLL loses lock and its VCO
output is then unknown to me. However the fact that HSYNC is gone is
known, so I'd like to select an internal RC clock for the uC before the
VCO goes out of spec.
Yeah, it's not a great design, but it's a personal challenge to me and
it's not a commercial product.
Also (heh heh), since the PIC is being fed by the PLL, it is also
acting as the feedback divider... I like this clever (imho) way saving
of parts, and the clock is allowed to have jitter.

Have a look at the Elantec/intersil video sync products ISTR a
flywheel mode is in one of them, maybe a lost lock detector, as well

I think AVR or MSP430 have "funny " clock systems


martin

 

[Joerg]

Does there exist a uC of any kind where the clock source is selectable
from code? With the PICs you have to choose the clock source at program
time by burning fuses, and you are stuck with it. Yes the watchdog uses
an internal RC but when it counts down the PIC wakes up with the
programmed oscillator type.
Here's my dilemma: I am using the clock generated by a genlock PLL to
drive the PIC. When the video is gone, the PLL loses lock and its VCO
output is then unknown to me. However the fact that HSYNC is gone is
known, so I'd like to select an internal RC clock for the uC before the
VCO goes out of spec.
Yeah, it's not a great design, but it's a personal challenge to me and
it's not a commercial product.
Also (heh heh), since the PIC is being fed by the PLL, it is also
acting as the feedback divider... I like this clever (imho) way saving
of parts, and the clock is allowed to have jitter.

Check out the MSP430 series. Not only can the clock source be selected
but you might be able to simply leave it on the digitally controlled
oscillator (DCO) because it cannot stray too far from it's SW-selected
adjustment range.

Regards, Joerg

 

[colin]

Does there exist a uC of any kind where the clock source is selectable
from code? With the PICs you have to choose the clock source at program
time by burning fuses, and you are stuck with it. Yes the watchdog uses
an internal RC but when it counts down the PIC wakes up with the
programmed oscillator type.
Here's my dilemma: I am using the clock generated by a genlock PLL to
drive the PIC. When the video is gone, the PLL loses lock and its VCO
output is then unknown to me. However the fact that HSYNC is gone is
known, so I'd like to select an internal RC clock for the uC before the
VCO goes out of spec.
Yeah, it's not a great design, but it's a personal challenge to me and
it's not a commercial product.
Also (heh heh), since the PIC is being fed by the PLL, it is also
acting as the feedback divider... I like this clever (imho) way saving
of parts, and the clock is allowed to have jitter.

Im sure I came accros a PIC with a backup clock wich kicks in when the main
clock stops, I may be mistaken I was just scanning quickly through quite a
lot of datasheets looking for what I wanted, cant remember wich device it
was in though.

The PLL oscillator will usualy go to max or min frequency on loss of lock,
if you want to have a clock more accurate than this then you will probably
need an external crystal.

Alternativly you could use one of the timers wich has a seperate input to do
the dividing rather than count clock cycles in code (wich something you
realy dont want to do unless you have no choice) and have a fixed clock.

Colin =^.^=

 

[Luhan]

Does there exist a uC of any kind where the clock source is selectable
from code? With the PICs you have to choose the clock source at program
time by burning fuses, and you are stuck with it. Yes the watchdog uses
an internal RC but when it counts down the PIC wakes up with the
programmed oscillator type.
Here's my dilemma: I am using the clock generated by a genlock PLL to
drive the PIC. When the video is gone, the PLL loses lock and its VCO
output is then unknown to me. However the fact that HSYNC is gone is
known, so I'd like to select an internal RC clock for the uC before the
VCO goes out of spec.
Yeah, it's not a great design, but it's a personal challenge to me and
it's not a commercial product.
Also (heh heh), since the PIC is being fed by the PLL, it is also
acting as the feedback divider... I like this clever (imho) way saving
of parts, and the clock is allowed to have jitter.

Here is another way to genlock to a video signal...

http://members.cox.net/berniekm/tricks.html

(down near the bottom of the page).

Luhan Monat (luhanxmonat-at-yahoo^dot^com)
http://members.cox.net/berniekm/
"Reality: what a concept!"

 

[Anthony Fremont]

Im sure I came accros a PIC with a backup clock wich kicks in when the main
clock stops, I may be mistaken I was just scanning quickly through quite a
lot of datasheets looking for what I wanted, cant remember wich device it
was in though.

It's in allot of them now. For example, the 12F683 (8 pin) and 16F88
(18 pin) have the new INTRC oscillator that is switchable on the fly
(uncalibrated at 31kHz; calibrated (better than 2% over a large
temperature range) at 125kHz, 250kHz, 500kHz, 1MHz, 2MHz, 4MHz and
8MHz). They also have the a fail-safe clock monitor that will auto
switch on a detected clock failure. The OP needs to look again.

The PLL oscillator will usualy go to max or min frequency on loss of lock,
if you want to have a clock more accurate than this then you will probably
need an external crystal.

INTRC on the PIC is actually better than 1% at room temperature. It is
also tweakable on the fly by + or - 12% thru the OSCTUNE register.

 

[Luhan]

Does there exist a uC of any kind where the clock source is selectable
from code? With the PICs you have to choose the clock source at program
time by burning fuses, and you are stuck with it. Yes the watchdog uses
an internal RC but when it counts down the PIC wakes up with the
programmed oscillator type.

PIC16F818/9 has a selection of internal clocks from 8 MHz down to 32
KHz. These are selectable from software while the chip is running.

Will this get you what you need?

Luhan Monat (luhanxmonat-at-yahoo^dot^com)
http://members.cox.net/berniekm/
"Reality: what a concept!"

 

[Jim Thompson]

It's in allot of them now. For example, the 12F683 (8 pin) and 16F88
(18 pin) have the new INTRC oscillator that is switchable on the fly
(uncalibrated at 31kHz; calibrated (better than 2% over a large
temperature range) at 125kHz, 250kHz, 500kHz, 1MHz, 2MHz, 4MHz and
8MHz). They also have the a fail-safe clock monitor that will auto
switch on a detected clock failure. The OP needs to look again.


INTRC on the PIC is actually better than 1% at room temperature. It is
also tweakable on the fly by + or - 12% thru the OSCTUNE register.

Glad you like those oscillators. I redesigned those internal
oscillators in 2003-2004 ;-)

...Jim Thompson

 

[John Fields]

Does there exist a uC of any kind where the clock source is selectable
from code? With the PICs you have to choose the clock source at program
time by burning fuses, and you are stuck with it. Yes the watchdog uses
an internal RC but when it counts down the PIC wakes up with the
programmed oscillator type.
Here's my dilemma: I am using the clock generated by a genlock PLL to
drive the PIC. When the video is gone, the PLL loses lock and its VCO
output is then unknown to me. However the fact that HSYNC is gone is
known, so I'd like to select an internal RC clock for the uC before the
VCO goes out of spec.
Yeah, it's not a great design, but it's a personal challenge to me and
it's not a commercial product.
Also (heh heh), since the PIC is being fed by the PLL, it is also
acting as the feedback divider... I like this clever (imho) way saving
of parts, and the clock is allowed to have jitter.

 

[[email protected]]

Hey that's great, thanks! Those features are not readily apparent if
you just look at their comparison chart. I guess you have to find the
right part first, because the 12F629 I picked doesn't do that good
stuff. Boy things have improved since I messed around with the 12C508
back in the Cretaceous!
All I need is for the PIC to be able to set the PLL to /4 mode so that
the clock the PIC sees doesn't go beyond 20MHz when the lock is gone,
shut down the video IC properly, then shut off the PLL entirely and
wait for HSYNCs to start coming in again.
Weeee! Too bad the weather is going to be beautiful on the weekend, or
I'd actually read the datasheet!

 

[Anthony Fremont]

Glad you like those oscillators. I redesigned those internal
oscillators in 2003-2004 ;-)

Yeah, but they can be a bit confusing/overwhelming at first. OTOH, I
suppose that's comes with all the flexibility. I had to read that part
of the datasheet about ten times before it really started becoming clear
as to how it all worked together. I forgot to mention the two-speed
startup mode, pretty slick. Congratulations, it all actually appears to
work, you should be proud on the relative lack of errata....being a PIC
and all. ;-)

By any chance, did you design the T1OSC in the 12F683? I've been
recently playing with that using a 32.768kHz crystal for timekeeping.
It seems to oscillate faster the longer the interval between TMR1
roll-overs. >60ppm variation by just changing roll-over intervals (by
preloading TMR1H with 0xC0, 0x80 and 0x00 for respective roll-over times
of 1/2, 1 and 2 seconds before waking up) By toggling an I/O pin in the
ISR and precisely measuring the period of the resulting square wave (1,
2 or 4 Hz), I could see that: the longer the sleep period, the shorter
the interval to the next wake-up; i.e. T1OSC seemed to speed up as the
length of the sleep interval increased. Here are my recently (last 10
minutes) measured results:

1Hz - period ~1000006 uS ( 6ppm slow )
2Hz - period ~1999950 uS ( 25ppm fast )
4Hz - period ~3999777 uS ( 56ppm fast )

Naturally, it appears that my measuring device is likely to be in error.
Therefore, I have verified its functionality by dividing the 1Hz output
using a binary counter chip and the results are precisely as they should
be. Probably the most fascinating thing about this is that I don't
really have to SLEEP. If I just loop in the main level without
sleeping, I get the same exact results. This seems to rule out CPU
noise as a source of interference. Now....I'd like to see someone
explain that behavior.

I have played allot with the capacitance parallel to the crystal, from
too little to oscillate all the way to wayyyyy too much. Nothing out of
the ordinary occurs, just a bit of overall frequency pulling.
Absolutely maddening, it's as if the T1OSC is affected somehow by the
values contained in the TMR1H register.

 

[[email protected]]

"Why not have another external oscillator as a clock source and
switch to it when HSYNC goes away? "
I don't know, bullheadedness? I decided to make a minimal parts count
design, not best performance or easiest to build... It's just fun to
use the clock that's already being generated. As long as there's video,
it'll work fine.
Besides, with all these new PICs, why bother? My motto is "specify,
don't design". Someone already went through all the trouble of figuring
out these things and working out the glitches. If I can get that for 2$
by choosing the right part, great!
BTW, aren't you supposed to be dead?

 

[Jim Thompson]

Yeah, but they can be a bit confusing/overwhelming at first. OTOH, I
suppose that's comes with all the flexibility. I had to read that part
of the datasheet about ten times before it really started becoming clear
as to how it all worked together. I forgot to mention the two-speed
startup mode, pretty slick. Congratulations, it all actually appears to
work, you should be proud on the relative lack of errata....being a PIC
and all. ;-)

I am only a ghost engineer... do the designs and leave ;-) I had
nothing to do with the documentation.

Only problems I had were youngsters trying to sabotage my work and
keep me from information I needed. Really pissed me off. About the
worst NIH/job-protection situation I've ever experienced.

By any chance, did you design the T1OSC in the 12F683?

I don't know what they were called. I don't think I even have a data
sheet.

Looking at the directories I find GRP1OSC, LPRC, and XTAL oscillators.

I've been
recently playing with that using a 32.768kHz crystal for timekeeping.
It seems to oscillate faster the longer the interval between TMR1
roll-overs. >60ppm variation by just changing roll-over intervals (by
preloading TMR1H with 0xC0, 0x80 and 0x00 for respective roll-over times
of 1/2, 1 and 2 seconds before waking up) By toggling an I/O pin in the
ISR and precisely measuring the period of the resulting square wave (1,
2 or 4 Hz), I could see that: the longer the sleep period, the shorter
the interval to the next wake-up; i.e. T1OSC seemed to speed up as the
length of the sleep interval increased. Here are my recently (last 10
minutes) measured results:

1Hz - period ~1000006 uS ( 6ppm slow )
2Hz - period ~1999950 uS ( 25ppm fast )
4Hz - period ~3999777 uS ( 56ppm fast )

Naturally, it appears that my measuring device is likely to be in error.
Therefore, I have verified its functionality by dividing the 1Hz output
using a binary counter chip and the results are precisely as they should
be. Probably the most fascinating thing about this is that I don't
really have to SLEEP. If I just loop in the main level without
sleeping, I get the same exact results. This seems to rule out CPU
noise as a source of interference. Now....I'd like to see someone
explain that behavior.

I have played allot with the capacitance parallel to the crystal, from
too little to oscillate all the way to wayyyyy too much. Nothing out of
the ordinary occurs, just a bit of overall frequency pulling.
Absolutely maddening, it's as if the T1OSC is affected somehow by the
values contained in the TMR1H register.

Looking at the schematics... to get all those "features" there are a
maddening number of analog switches in there, from previous versions,
that I had to adhere to.

One of those "fix it but don't change anything" projects :-(

...Jim Thompson