What DOES "fully-static operation" really MEAN?

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

Some of the new AVRs are advertised as having "fully-static operation". What does that really mean?

I was kind of the impression that it (theoretically) meant you have complete, absolute freedom to clock the AVR at any arbitrary speed -- constant, lurching, or random -- from moment to moment. In theory, you could stop the (external) clock for seconds, minutes, hours, or longer... then resume without skipping a beat as long as the AVR remained powered up... or even go so far as to mount a pushbutton to another AVR and run a program on it that debounced the switch and toggled an output pin used to clock the (allegedly) fully static AVR each time you pressed the button... occasionally, giving it a random burst of N pulses at X megahertz just to keep it on its toes and see whether it's paying attention.

Others here have speculated that maybe you could get away with it with regard to the processor core itself, but only if most/all of the i/o and timers were disabled, and possibly THEN only if the core were in deep sleep.

Has there ever been official word from Atmel as to what it actually means, what its guaranteed behavior is supposed to be, and what limits (if any) apply to its real-world use?

There's no place like ~/

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

Some of the early micros used dynamic logic, much like DRAM. I think that the Intel 4004 and 8008 were in this category (which were the first ones I ever saw). It had a specific minimum clock rate. If the clock rate was below this, the stored charge in gate would be lost and registers would "forget" their values.

My concept of "static" in this context means that registers, in particular, are made from real flip-flops, not depending on stored charge. And, as a consequence of this, there is no minimum clock rate.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Quote:
Some of the early micros used dynamic logic, much like DRAM.

Interestingly, I just read a report that we are heading back in this direction. DRAM takes up considerably less room than SRAM. So even though it is slower, using some tricks the overall speed of the chip can be increased.

Regards,
Steve A.

The Board helps those that help themselves.

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

Other than debugging and development, is there really a
need for fully static operation?
Even in debug mode I think that the clock is not really stopped?

I'll believe corporations
are people when Texas executes one.

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

Well being fully static means that you can clock the CPU at 1Hz if you like. (or slower)

There "may" be applications where it is beneficial to stall the clock on the AVR, but I cannot think of any at the moment.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

While the AVR may be able to run down to 0Hz (first datasheet page, "Fully Static Operation" and "Speed Grade: 0-nMHz"), the other info on using external clock contradicts miami's theorem

Quote:

I was kind of the impression that it (theoretically) meant you have complete, absolute freedom to clock the AVR at any arbitrary speed -- constant, lurching, or random -- from moment to moment. In theory, you could stop the (external) clock for seconds, minutes, hours, or longer... then resume without skipping a beat as long as the AVR remained powered up...
which I assume came from the recent discussion in this thread.
https://www.avrfreaks.net/index.p...
But then lurch on over to an AVR datasheet, and see the dire warning under "External Clock":
Quote:
When applying an external clock, it is required to avoid sudden changes in the applied clock frequency to ensure stable operation of the MCU. A variation in frequency of more than 2% from one clock cycle to the next can lead to unpredictable behavior. If changes of more than 2% is required, ensure that the MCU is kept in Reset during the changes.

I certainly do NOT want "unpredictable behavior" in my apps.

Now if we want to provide the AVR clock from a "aster" device as mehlion opined, then we'd need to ensure that the AVR sees no lurching. Thus my recommendation to have the AVR pulled into reset whenever the "master" is not providing the clock.

There are indirect notes on this for other clock sources as well. If the crystal is shut down during power-down sleep then the normal long startup times apply to have it stabilize. There is a note in the clock prescaler section about the precaustions that are taken to ensure a stable clock.

So, my summary would be you need a sober clock--marching down a straight path with an even gait, and no lurching or other drunken weaving allowed.

That brings me back to 0Hz--obviously you can't do anything useful at 0Hz. And to change to 1Hz from 0Hz or 2Hz is a change FAR greater than 2%. ;)

Quote:
Some of the new AVRs are advertised as having "fully-static operation".

I'd think I'd say "all". While the earliest datasheets of the AT90S8535 [family] did not have the note that seems to be the exception. It appears that every other AVR model line datasheet in this century, and even the previous century, have the phrase on the first page. [Reference: Printed databooks (remember those?) 1999 & 1997]

LOL Continuing to page through, I found a few others without the phrase e.g. Mega161. But the venerable Mega103 has it.

In practicality I don't know how much use a 1Hz or 100Hz or even 1000Hz clock would be. (Can you imagine the ISP times at 0.2Hz?) But judging from mentions in these Forums 32kHz may not be that uncommon.

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

I would imagine that using 0Hz clock would give us an AVR with next to no power consumption. I don't know if it is that essential, but it gives the designers the freedom to use it ;)

as to 32kHz, even I have used it many times to save power. most of the times my designs don't need anything faster (sensory, dataloggers etc)

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

My "gut hunch" is that Atmel plays some games to get single cycle execution. I expect that it is more than doing things on both clock edges. There appears to be a prefetch of some sort with the corresponding pipeline that is basically hidden from us and normally of no consequence (except in conditional branches or jumps). I suspect that this is the stuff that brings on the "rapid change" warning with respect to the clock.

If so, it will likely remain inscrutable to us and the stuff of conjecture rather than knowledge.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Quote:
as to 32kHz, even I have used it many times to save power.

Did you happen to see my analysis on that a while back, where I "proved" ;) that an AVR running at 32kHz and just getting the job done takes more power than the same AVR that runs at a full speed for (say) a millisecond and then sleeps the rest of the second?

If this is "sensory", does the ADC run at 32kHz, below the min recommended 50kHz? Do you get full accuracy?

[Found the previous "proof": https://www.avrfreaks.net/index.p... ]

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

OK That I didn't know... have to keep that in mind next time and test both clock before finalizing...

and the ADC was averaged and gave accurate results. although I do have to admit that I didn't test it for 24h with logging... (didn't have the time; had just 12h to get it designed, built and running)

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

There is one downfall using a fast clock and sleep mode with wakeup from the whatchdog in between:
The whatchdog does not give an accurate timing as an 32 kHz crystal would do.
The Calculated differnce in power is not large, and I am not that shure the data are that accurate to make sure that one realy saves power.

On the positive side one saves the contineous crystall oscillator, one the negative one has the high speed RC (8 Mhz) for the short periods and the watchdog all the time.

Back to the original question, I think, that at very low clock rates there should not be much that limits the change in clock rate. I don't think there is a system inside the chip that can remember whether the last clock tick was 1 s or 100 ms ago.

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

Lee's proof, I think, depends on the important difference between static current (between clock edges) vs sleep current.

You can see the static current when you look at the spec sheet chart that shows current vs clock frequency. There is some point, below which, the current does not change much with clock rate. This is the static current.

I little bit of "what-if" number punching will show whether or not low clock saves more power than sleep in your application.

As for the AD, I'd bet a tall, cool, one that accuracy would be degraded at low clock rates. The ADC >>IS<< dynamic and depends on charge sharing on switched capacitors. If the clock rate is too low, leakage will degrade those charge packets.

SO..... Atmel may not be telling "the truth, and nothing but the truth!" when they say "fully static operation" because I am pretty sure the ADC IS NOT!

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net