Variable Frequencies applied to XTAL1...

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was attempting to see what type of current drain I could get from the Mega324P while operating at 32.768KHz. Well, in the confusion, I lost control of the FUSE settings.

So, I fire up the Instek SFG02997 DDS based pulse generator and drove the Mega324P with an external 1.8432MHz TTL clock signal. This is the external crystal frequency that I've been using throughout the project.

No problem, I re-program the FUSE setting back to where they should be, and all is well.

But I just couldn't stop there...

I have heard that the AVR can't handle large steps in clock frequency at XTAL1, so I started messing around, putting all kinds of frequencies into the AVR - on the fly, without resetting the thing.

To my surprise, the Mega324P responded to every frequency step change - without any hang-ups. I was even able to step from 1KHz to 7.000MHz (the highest frequency my function generator can go) and the Mega324P responded flawlessly.

So, this raises some interesting possibilities. This means I can hang a programmable oscillator on XTAL1 and program the thing to what ever frequency I want - on the fly.

Has anyone else attempted, or run any experiments along these lines?

I see some interesting project features, if this holds true and is repeatable and reliable from device to device.

Comments welcome...

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most interesting. Thanks for letting us in on it.

If you think education is expensive, try ignorance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Microcarl:

One question, is how fast does your DDS gen change freq--is it in a single clock cyle (most DDS chip are capable of this). Were you stepping up and down in freq?

Also, the core processor itself might be unaffected, but perhaps suddenly applying the brakes might skew some peripheral functions such as the watchdog, A/D or other timers into never-never land. There may be buried PLL functions internally that might not appreciate a jumpy clock.

Atmel specs a 2% cycle-to-cycle variation limit, but does not provide further info on what happens when you exceed it. Maybe you win a prize :)

Hoyt

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My DDS function generator has both, a keypad entry and a variable control.

In the worse case frequency step, I started at 1.000KHz and programmed the step to 7.00000000KMz.

I also manually (read, continuously) varied the frequency in 1Hz steps, 10Hz steps, 100Hz steps, 1KHz steps, 10KHz steps, 100KHZ steps, 1MHz steps, up to 7MHz, which is the maximum frequency that my DDS function generator will output.

I have an LCD running in 4-bit mode, and timer1 interrupting at a rate of 100uS that establishes the timing and delays for the entire system. In addition, there are several I/O pins on each I/O port that are use, including the A/D and channel zero, which is measuring the battery voltage. The only observable artifact was that things speed up and slowed down proportionally with the increase and decrease of the clock signal applied to XTAL1. Even the A/D read reliably, though it obviously responded a bit slower at the lower XTAL1 frequencies.

So, unless there are other hardware blocks that I didn't test that don't like large frequency steps, such as TWI, SPI, the USART, EEPROM, etc. I'm thinking that it is possible to do something like use the Mega324 (or other Mega flavor) in say, the divider/counter feed back chain in a Phase-Locked Loop and have all kinds of interesting frequency generation and control possibilities.

I saw no erratic operation - only the expected. That is, as the frequency was increased or decreased, the operation of the LCD and time intervals speed up or slowed down proportionally.

Maybe at higher XTAL1 frequencies, such as 16.000MHz and 20.000MHz things will flip out, but not up to 7.000MHz.

I do have another DDS based signal generator that will output from 1.000Hz to 20.000MHz, but it only outputs a sine wave of about 50mV. So, I don't know if that would be enough signal amplitude to reliably drive the XTAL1 input from 1.000Hz up through 20.000MHz. It would be interesting to find out, though.

When I finish my current project - for pay, I'm going to play with this concept some more - for sure...

EDIT:
One interesting thing I did notice, at 1.000KHz (and slightly higher frequencies), the initialization was quite long, and the controller took a few seconds to get around to initializing the I/O ports. Well, I'm turning an LED back-light on and off with a MOSFET capable of handling about 1 ampere - continuous. While the I/O pin driving the LED was still acting as an input, the LED back-light came on very softly, ever increasing in brightness, until it reached maximum intensity. I though this was pretty cool to watch. But I'm sure that linearly biasing the MOSFET to control back-light intensity will dissipate a substantial amount of power in the thing - especially as the LED back-light us drawing about 55mA at full intensity.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The interesting aspects to me are

1 How to retain the accuracy of the frequency, your XTAL1 clock (which btw is giving me a hard time at the moment) will obviously have to be controlled by another micro. Can you do so with the same micro - maybe using a reference clock.

2 The tradeoff between DDS and PLL based sig gens rises again with a new twist. Each has its pro-s and cons.

3 The M168 data sheet specifically warns not to change faster than 2% per clock cycle - don't know why if it is fully synchronous logic but they do warn you

4 The DDS needs a low pass filter on the output, usually set to about 1/3 of the clock frequency to remove aliasing type effects. Now the frequency is variable and you're down to the PLL based sig gen filter problem.

5 PLL doesn't (usually) do arbitrary waveforms which a dds can, you may have the best of both worlds here. Can your DDS do arb waveforms?

Sounds like fun!

Klave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Carl, I'd need to go back and re-examine the dire warnings again. But IIRC they aren't quite so dire--the AVR ain't gonna croak, but the actual clock period used during the transition could be unpredictable.

Now, if it really were dire, than any drastic operation such as OSCAL load or CLKPRR load would violate the rules on what the AVR is really using for a clock.

IIRC you also see a line in the datasheets about "fully static operation".

Hmmm--I just read the dire warning again, and it does indeed sound quite dire. If the AVR is indeeed "fully static" how can one go from 0Hz to any other value without violating the 2% rule? Also in modes like power-down the clock is stopped; a re-starting crystal exhibits all kinds of interesting patterns.

Dunno. Since the dire warning has been there as long as I can remember perhaps it was the case on one or more classic AVR models. What do you think the chances are that Atmel will have an answer if you ask them?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Carl, I'd need to go back and re-examine the dire warnings again. But IIRC they aren't quite so dire--the AVR ain't gonna croak, but the actual clock period used during the transition could be unpredictable.
The DDS based pulse output seems to do quite well as moving from one frequency to the next. I think it's using one of the Analog Devices DDS IC's, but I don't know which on. One the DDS signal generator the I have that goes from 1HZ to 20MHZ, I see no aberrations when the frequency is changed in large steps either. I'd have to look in the data-sheet for the AD DDS generators to be sure, but I believe that the incoming frequency data is not only double buffered, but synchronized to zero crossing, as well. I could be mistaken on that second half of the statement, though. I'll have to study up a bit on the AD DDS IC's, to be sure.

theusch wrote:
Now, if it really were dire, than any drastic operation such as OSCAL load or CLKPRR load would violate the rules on what the AVR is really using for a clock.
Well, back when abcminiuser was developing the BUTT-LLOAD project, at the OSCAL part in particular, I was trying to grasp the rational regarding the 2% frequency change warning and the seemingly contradictory existence of the OSCAL function. I still think there is a contradiction, to this day.

theusch wrote:
Hmmm--I just read the dire warning again, and it does indeed sound quite dire. If the AVR is indeed "fully static" how can one go from 0Hz to any other value without violating the 2% rule?
Well then, I've always been a rule breaker. I don't think I'll be changing my ways at this late age.

theusch wrote:
Dunno. Since the dire warning has been there as long as I can remember perhaps it was the case on one or more classic AVR models.
But I'm thinking that the dire warning might be more applicable to the legacy AT90S AVR models.

theusch wrote:
Also in modes like power-down the clock is stopped; a re-starting crystal exhibits all kinds of interesting patterns.
And a good reason to have a gated oscillator on restart - instant square wave at enable time.

theusch wrote:
What do you think the chances are that Atmel will have an answer if you ask them?
I'd like to have some sound data and experiments before approaching Atmel. If I can accumulate some good experiments and supporting data, they may be compelled to change their mind-set.

You might remember my mentioning that I worked for a subsidiary of Fairchild semiconductor back in the mid-190s. We designed and manufactured "High-Speed " dynamic memory testers. These unit used ECL operating at 100MHz clock speeds for the bulk of the testing logic and TTL for the less speed demanding aspects.

One of the predominant control circuits was something that we called a "Period Generator ." This was basically a series of 10016 4-bit programmable binary counters that were daisy-chained and synchronously clocked. The output was a narrow sub-nanosecond pulse, whose period was programmable from 1nS to about 1 second.

I've always had this fetish to build something similar for my bench. The problem, though, is that ECL is very power hungry. I've tried 74Sxx logic, but with limited success - about 10MHz.

The advent of inexpensive micro-controllers becoming available to the hobbyist seemed promising but the limited range of 16-bit timers posed problems, as well.

Now, the fact that the AVR can generate square waves and PWM output pretty much unattended, has the possibility to opens may doors to other applications. My thinking is that if the AVR can perform reliably while undergoing large frequency steps or frequency sweeps, it wouldn't be too difficult to scheme up a 20MHz period generator with variable pulse width.

Yep! I have a couple DDS based frequency generators that will provide the frequency. But one only goes to 7.000MHz and the other, while able to output 1HZ to 20.000MHz, only outputs a 50mV sine wave. But if I can use the DDS generator that outputs the 50mV sine wave to drive the XTAL1 input of a Mega class AVR, then I can simply use an Analog Devices DDS being driven by say, a Tiny-something, and use the 50mV (or some reasonable amplitude) to drive a second Mega class AVR at any frequency I choose - stepped or sweaped. As the frequency component will then become detached from the duty-cycle of the PWM output, the range of the frequency and PWM become independent (mutually exclusive) to each other. With the AVR PWM generator, if the duty-cycle exceeds the period of the PWM output, the PWM signal goes solid high, or low, depending on the output settings. Also, just as an AVR PWM is seamless in it's transition from one PWM setting to the next, so would the period of the PWM signal be - and the period would be the range and resolution of the DDS output.

So, for the change of two independent variables, I'd be able to generate pulses of varying pulse-width and period - without the problem of the duty-cycle and period overlap.

I have no particular reason for wanting to do this, except that I get the frequency and PWM spans and resolutions I want, with minimal difficulty.

Now, lets take Jespers DDS sine wave generator. If you can step or sweep any desired frequency into XTAL1 of his design that you want, Jespers DDS sine wave generator would move from a great device, to an exceptional device.

There are other uses, as well. Say that you want to measure the echo time of an ultrasonic transducer, in order to calculate distance. Well, over very large and very small distances, it would only require a simple frequency shift of the AVR XTAL1 clock source and changing one constant in the application program.

And what about velocity of say, a servo motor, whose rotational velocity ranges between zero and say, 35,000 RPM. Simple, just change the XTAL1 clock source being used as the timebase, and a matching constant.

Having the ability to step or sweep the XTAL1 input of an AVR micro-controller has some real potential, from my perspective.

I haven't even given any real though to phase detection or other things.

My ultimate goal would be to develop a building block that could have a wide variety of possible solutions.

All I'm doing is throwing out some food for thought...

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've done a bit more playing around. I fired up the 1Hz - 20MHz DDS signal generator.

Well, I was mistaken... That DDS signal generator outputs a 1 volt P-P sine wave, centered around zero volts. Just for the heck of it, I removed the crystal from the prototype board that I'm currently using and connected the DDS signal generator to it - even though the output swings 500mV to the negative.

The prototype board did crash when making frequency steps between 10MHz up to 20MHz and then back down to 10MHz.

I can't honestly say if the prototype crashed because of the fact that I was driving XTAL1 500mV negative, or that the 10MHz step was more then the Mega324P could handle. But stepping the output between 1MHz and 10MHz (and smaller) there were no hiccups to be seen.

In addition, I don't know where the where the valid operating point. That is, I'm running the Mega324P at 3.3 volts. At what voltage level does XTAL1 decide that the internal gate should transition from a logic 0 to logic 1 and back. I'm thing that maybe a buffer amplifier using an MPF102 JFET (Ft = 300MHz) will suffice as an amplifier and level shifter. I might build that up tonight and give it another try.

Then I connected the Instek SFG02997 DDS function generator to the prototype board with a full swing TTL clock signal. There were no hiccups with it, either. But, the largest frequency step I can make with the Instek SFG02997 DDS function generator is from 7MHZ to something lower.

So if I am to pursue this experiment further, I'm going to have to build a circuit to shift the output of the 1HZ - 20MHz DDS signal generator so that the 1 volt P-P signal is totally above GND, and I'll probably need to square off the sine wave, as well.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, given what is undoubtedly in your AVR bin there must be one with clock-out feature and 20MHz max spec. Use a ~20MHz or 24MHz crystal. Use CLKPRR to do /2 and /4 upon demand. That would give you 20/10/5MHz out. (I guess 24MHz would be beyond the specs of the AVR-under-test so would not tell us anything.)

Or use one of the AVR modesl with PLL and high-speed PWM. You should be able to step that around nicely by changing the OCR value or the prescaler.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Well, given what is undoubtedly in your AVR bin there must be one with clock-out feature and 20MHz max spec. Use a ~20MHz or 24MHz crystal. Use CLKPRR to do /2 and /4 upon demand. That would give you 20/10/5MHz out. (I guess 24MHz would be beyond the specs of the AVR-under-test so would not tell us anything.)

Or use one of the AVR modesl with PLL and high-speed PWM. You should be able to step that around nicely by changing the OCR value or the prescaler.

Lee

I've got a fairly good selection of AVRs. Most of them are TQFP, though I've got some Mega16/32/644s, Tiny2313s and Mega88/168s in PDIP.

I could use an existing project board to activate the CLKout. A simple EXOR combination and an R/C delay will double the output frequency. But a small one transistor amplifier would probably be a lot easier, as there would be no programming involved at all.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could simply use a potentiometer/preset (ends connected across Vcc and Gnd, wiper connected to XTAL1) and AC couple your generator to the wiper using a small capacitor (<.01uF).

If you think education is expensive, try ignorance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

emuler wrote:
You could simply use a potentiometer/preset (ends connected across Vcc and Gnd, wiper connected to XTAL1) and AC couple your generator to the wiper using a small capacitor (<.01uF).

I've though about that too. In fact, all I need is the center positioned potentiometer (or two resistors) as the output is capacitively coupled.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Microcarl:

By not heeding Atmel's very direct warning, you may have uncovered something you aren't supposed to know. Not you will undoubtably have to face the consequences, possibly being required to turn in your development equipment, chips & dips, least you might make further "discoveries". I wouldn't answer the door for awhile :)

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
Microcarl:

By not heeding Atmel's very direct warning, you may have uncovered something you aren't supposed to know.


Oh? Did I break something? Well then, I guess Atmel will have to confiscate all of our stuff!

avrcandies wrote:
Now you will undoubtably have to face the consequences, possibly being required to turn in your development equipment, chips & dips,

Na. Let'em try. Legend, a dog so big I can rider her, will chew them up for her desert, lest my equipment will be safe.

avrcandies wrote:
least you might make further "discoveries". I wouldn't answer the door for awhile :)

It would be nice to contribute something unique to the community, rather then the same old daily "Hum-Drum ."

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston