Internal vs external oscillator

northcove

The Propeller ProtoBoard & PropStick both use an external 5MHz crystal. The Propeller also has internal fast (~12MHz) and slow (~20KHz) oscillators.

Q1: Other than power economy, what's the advantage of using a external oscillator that's slower than the internal oscillator?

Q2: Is the fastest Propeller configured using an 80MHz external crystal like this?

  con
    _clkmode = xtal3 + pll16x
    _xinfreq = 80_000_000

Q3: Is lowest power Propeller configured using no external crystal like this:

  con
    _clkmode = RCSLOW

Q4: If current draw is directly proportional to MIPS, does RCSLOW mode consume orders of magnitude less power than xtal1+pll16x mode and an external crystal (assuming same number of active cogs, same current drawn from pin sourcing, etc.)

Thanks!

Leon

Frequency stability and accuracy! The internal oscillator has a nominal frequency only, and isn't at all stable to temperature changes.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Bobb Fwed

From my understanding _clkmode = xtal3 + pll16x _xinfreq = 80_000_000 would not work. This would put a x16 PLL on an external 80MHz crystal, resulting in 1.28GHz. This exceeds the 80MHz cap.
The best thing to do is a 5MHz crystal with the 16x PLL to achieve the 80MHz clock speed. You can also just use a 80MHz crystal with no PLL.

The benefit of the external crystal rather than the internal, is the precision. External crystal will typically be 20-30ppm which (+/- 0.00003%) , where the internal will vary wildly between chips and temperatures. So anything that is timing dependent (serial communication or frequency control) is very reliant on an accurate clock speed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

northcove

Bobb said...

From my understanding _clkmode = xtal3 + pll16x _xinfreq = 80_000_000 would not work. This would put a x16 PLL on an external 80MHz crystal, resulting in 1.28GHz. This exceeds the 80MHz cap.

That was my hunch and I was surprised to see xtal3 + pll16x listed in Table 2.4 as a valid clkmode expression & value. I should have guessed that if the Propeller had 1.28GHz capability everybody would know about it. Sounds like I'll need to use an external crystal because my code usually requires timing for serial I/O and will experience wide temperature ranges. Thanks!

northcove

Then a Propeller configured for PLL1X could theoretically draw 1/16th the power compared to in PLL16X mode?

Bobb Fwed

That is mostly correct. There is some initial overhead, then the clock speed will affect the amount of power used. The number of cogs running will also greatly affect the power draw.
When power consumption is an issue, highly optimized code, or PASM code, is a big deal. Profuse use of CTRs when possible will also help.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Proptest

How can one use an external canned oscillator with NO prop PLL? The Prop PLL's are useful, but their jitter is massive for a timing critical task. Can I push in an 80MHz clock and have the prop cores use it directly?

LoopyByteloose

One needs something with less that a 3% variation to get an asychronous serial port that other devices can deal with. The internal oscillator apparently doesn't meet that requirement. Also, time keeping will drift.

Crystals and resonators generally can get down to 1%. Futher precision requires a special crystal oscillator that is in a controlled temperature environment. Those are expensive.
++++++
Back when the Propeller was released, external crystals and resonators were SOP. But many newer microcontrollers have managed to include more precise internal oscillators that work fine with asynchronous serial.

Publison

Proptest wrote: »

How can one use an external canned oscillator with NO prop PLL? The Prop PLL's are useful, but their jitter is massive for a timing critical task. Can I push in an 80MHz clock and have the prop cores use it directly?

Yes. One of the Clock Mode settings is "XINPUT" which accepts an external clock-oscillator.

(Page 68 of the Propeller Manual Ver 1.2)

jmg

Proptest wrote: »

The Prop PLL's are useful, but their jitter is massive for a timing critical task.

Do you have measured numbers for the 'massive jitter' ?

Heater.

Loopy,

Come on...an XTAL oscillator will give do a lot better that 1 percent. Typically more like 100ppm or less. Watch crystals will get down to 20ppm or so. Oven controlled XTAL oscillators get down to about one part per billion.

Bean

jmg wrote: »

Proptest wrote: »

The Prop PLL's are useful, but their jitter is massive for a timing critical task.

Do you have measured numbers for the 'massive jitter' ?

I do precision freqency measurements (to the sub ppB) using the propeller with the PLL, there is very little jitter that I can detect.

If you go outside the lock range of 4MHz to 8MHz you will likely see much more than normal though.

Bean

Heater.

There has been mention here from time to time that the Props PLL driven clock is too jittery for building RF transmitters. Too many harmonics. Out side of that I can't see that anyone would worry about it.

On the plus side that jitter is put to good use in generating real random numbers on the Prop. A feat that no other micro I have heard of can do by itself.

Phil Pilgrim (PhiPi)

I think we may be confusing the source of jitter here. The master clock's PLL is virtually jitter-free. Where jitter raises its ugly head is when you use a counter (with or without PLL) to generate a frequency that's not a harmonic or subharmonic of the master clock. In such cases, the NCO edges align with those of the master clock, not with the edges of the desired waveform. Even with the NCO driving a PLL, the resulting edge displacement entails noticeable jitter and splatter across the frequency spectrum.

-Phil

Proptest

When using CTRA/B+PLL, 1 to 5 ns, worse when the '1's count is high as has been noted. But it never seems to get better than 1ns. And even with the PLL off (which visibly reduces jitter), even when the FRQ register is set to not induce single-clock cycle dither in the output frequency, there is still a ~1ns jitter that I figure is sourced in the main PLL that pumps up the external crystal by 16x (usual mode).

I'm just using a digital oscilloscope in equivelent time triggering on edges driven out a port by the cog counter.

Phil Pilgrim (PhiPi)

Proptest,

Maybe it's your scope's sampling that's causing the appearance of 1 ns jitter, rather than the Prop itself. Also, the PLL does not "pump up" the crystal frequency. It uses a VCO with a free-running frequency of about 120 MHz that's divided down to match the crystal frequency for phase comparison. The result of that comparison is fed back to control the VCO for phase locking purposes.

-Phil

Proptest

I can see the jitter on a CRT scope too, but you have to look for it by zooming in with a delayed sweep and turn the beam up to see the jittered rising / falling edges. Plus the external crystal being driven to oscillation by the prop , even though probing those pins is an unusual capacitive load, looks golden, no jitter at all.

I think I'm okay with how the PLL module works comparing the divided down version of its internal VCO with the external crystal reference. From my user point of view it takes a slower crystal and effects a faster main clock. "pump up".

Now are the other answers good, I could feed an external can oscillator in at 80Mhz?

Phil Pilgrim (PhiPi)

Proptest wrote:

I could feed an external can oscillator in at 80Mhz?

Yes.

-Phil

jmg

Proptest wrote: »

When using CTRA/B+PLL, 1 to 5 ns, worse when the '1's count is high as has been noted. But it never seems to get better than 1ns. And even with the PLL off (which visibly reduces jitter), even when the FRQ register is set to not induce single-clock cycle dither in the output frequency, there is still a ~1ns jitter that I figure is sourced in the main PLL that pumps up the external crystal by 16x (usual mode).

I'm just using a digital oscilloscope in equivalent time triggering on edges driven out a port by the cog counter.

Measuring jitter below 1ns is going to be challenging -
what numbers do you get, using an 80MHz Oscillator module ?
1ns jitter is well below the Prop resolution of 12.5ns so it is hard to see that mattering for instrumentation measurements, but I could see that fixed RF use and mixers may be fussier, but that is a niche.

Publison

Yes I already answered it in a previous post. Please go back and read the thread.

BTW. Welcome to the forum!
It's not a good idea to bring up such an old thread. You are better off to start a new one because things have changed over the years, and the info in the old thread may be, well old.

EDIT: I answered the question at 5:02AM EST this morning.

jmg

Proptest wrote: »

Now are the other answers good, I could feed an external can oscillator in at 80Mhz?

Sure, if you have one - see above.
Not easy to get 80MHz and low ppm at the same time, or does jitter matter more to you than ppm ?

You could also use something like Si5351 to generate 80.00MHz, and that can use a TXCO drive.

Proptest

Probelm not at all what I was chasing. Voltage regulator was oscillating a bit; running the prop right off the bench supply and got much better results. In NCO only mode, set up to divide down to 1/16th the system clock (5Mhz out), I only get 200ps jitter accumulated over 4 seconds. And that might be pushing the scope, an HP54502. Good enough for what I'm trying to do (homebrewed oscilloscope, > 300Mhz bandwidth using equivalent time sampling). Thanks for all the help!

Publison

Proptest wrote: »

Now are the other answers good, I could feed an external can oscillator in at 80Mhz?

Gee, didn't I already answer that?

Proptest

Yep, sorry. You all are great.