The datasheets tout "Fully static operation" as an important feature of AVR's,
but I have no idea what it means. Anyone?
--Mike
What is "Fully Static Operation"
Author
Message
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29759 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)
It can "run" at Zero Hz...... some older processors needed a minimum clock to keep it alive.
Makes sense now - Thank you,
--Mike
avr-mike wrote:
The datasheets tout "Fully static operation" as an important feature of AVR's, but I have no idea what it means. Anyone?
The beauty of AVRfreaks is that every possible issue dealing with AVRs has been brought up, discussed, and a consensus reached.
https://www.avrfreaks.net/forum/...
with a link to https://www.avrfreaks.net/forum/...
Note my query:
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.
Other light reading:
https://www.avrfreaks.net/forum/...
Back to 2003:
https://www.avrfreaks.net/forum/...
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.
Well, that's interesting in terms of external...Would same apply to internal? Likely, not...probably internal synchronization logic prevents any gear-shifting issues.
I wonder why they don't say proper instead of stable? Of course if the clock is jumping around, it wouldn't be stable...so much for a useful warning! Of course, they mean stable in a different context (reliable).
A variation in frequency of more than 2% from one clock cycle to the next can lead to unpredictable behavior--that's a little less ambiguous.
avrcandies wrote:
Didn't you participate in one of the prior discussions on this? No matter. Anyway, tell me how you are going to get any AVR internal clock down to, say, a fraction of a Hz? And then half that? And continue till fully static?
Well, that's interesting in terms of external...Would same apply to internal? Likely, not...probably internal synchronization logic prevents any gear-shifting issues.
theusch wrote:
The beauty of AVRfreaks is that every possible issue dealing with AVRs has been
brought up, discussed, and a consensus reached.
OK, I'll go back to just answering questions now.... :-)
In the thread you referenced there was this from @ka7ehk:
ka7ehk wrote:
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.
The 2% rule could be explained if there's an internal PLL boosting the frequency
and would lose its lock with a more rapid change in the clock rate. Several AVRs
have a PLL you can actually configure for your own use (I'm sure you know this!)
so it's possible there's one "in there" but used only internally.
--Mike
Its the difference between SRAM and DRAM. DRAM needs a constant refresh to keep the cell values valid. Think if it as a leaky bucket; you have to keep refilling it while there is still enough to be able to tell if it is full or empty. SRAM is (like) a flipflop. You set or clear it, and it stays in that state until power is removed or it is changed.
My recollection is that some of the VERY early micros were NOT static (maybe 4004?).
Jim
Static, did I hear someone mention static?
JC
Just for fun I decided to see how long it would take to drop the frequency from 16MHz
to 1Hz while sticking to the maximum of 2% change in frequency. The number of clocks
needed can be calculated as:
1.02^N = 16000000
N = log 16000000 / log 1.02 = 840 clocks
A 2% reduction of frequency is nearly the same as a 2% increase in the period, so the
period is increasing by a factor of 1.02 each cycle and the total time required is:
T = (1 + 1.02 + (1.02)^2 + (1.02)^3 + ... + (1.02)^839) / 16000000
T = [(1.02)^840 - 1] / (1.02 - 1) = 52 seconds
--Mike
avr-mike wrote:
OK, I'll go back to just answering questions now.... :-)
That wasn't the point. The point was that there was prior discussion.
avr-mike wrote:
Just for fun I decided to see how long it would take to drop the frequency from 16MHz to 1Hz while sticking to the maximum of 2% change in frequency.
Did you do a CLKPR register test, and change to /256 from /1? Oh, wait -- that violates the 2% rule. As does any manipulation of CLKPR.
How many have done apps with an external clock that varies in frequency during operation? I cannot remember any discussion. My take on the "fully static operation" and the "2% rule on external clock" is that it is just that -- the creation of the clkCPU. The processor core itself doesn't care [because of fully static operation] where the edge comes from or how far apart they are (as long as they aren't too close together).
OK, sparkies, riddle me this: (or "these"?)
1) If the processor doesn't have fully static operation, then how does power-down or other sleep mode that stops clock(s) work?
2) Explain the conundrum of power-down sleep, stopping the clock, and the 2% rule. Does it take 82 seconds to go to sleep, and 82 seconds to come out of sleep? Indeed, it takes longer than that for me -- but for you I'd wager it is a few ticks of the clock.
https://www.avrfreaks.net/projec...
https://www.avrfreaks.net/forum/...
Last Edited: Sat. Oct 13, 2018 - 01:54 PM
The way I read description of wakeup from power-down sleep (on an M328P, at least), it is very much like initial power-up, with the WD providing a delay for oscillator stabilization. The oscillator does not just "ramp up". It appears to be gated into hardware by the boot-up circuit and the first clock cycle runs at full speed.
Jim
theusch wrote:
Did you do a CLKPR register test, and change to /256 from /1? Oh, wait -- that violates the 2% rule.
CLKPR doesn't change the input clock, it remains operating at full speed. Likely there is an "enable"
input on all of the flip-flops. At full speed this would be a constant logic '1'. Choosing a reduced
speed (non-zero CLKPS bits) the enable input would be a pulse train of appropriate duty cycle (50%
for /2, 25% for /4, etc.).
--Mike
avr-mike wrote:
CLKPR doesn't change the input clock, it remains operating at full speed.
I think you are finally starting to get the point that I've been making since the start of the thread, and in past threads. Or at least trying to.
I'll bet a cold one, even thogh I'm just an old bit-pusher, that you can't collect: As yyou are not saying, contrary to what you said earlier in the thread, the process or is fully static and moves from edge to edge. what mechanism fails when external clock makes a sudden change, I have no idea. As I'm tryying to hammer home, if the CPU was anything but fully static then you couldn't do power-don sleep/wakeup; you couldn't do CLKPR; and similar.
What is your concern, anyway?