RE: [avr-gcc-list] OT: anyone successfully use the CLKPR feature in themega88?

[Eric Weddington]

Hi Larry,

Sorry to get back to you late on this. Unfortunately I don't have an answer
on this one. A quick glance at the errata in the datasheet doesn't bring
anything up about this.

I strongly suggest that you write to address@hidden and ask the AVR group
about this. Perhaps they have some information in their knowledge base about
this.

Sorry I don't have anything more definitive about this.

Eric Weddington

> -----Original Message-----
> From: larry barello [mailto:address@hidden 
> Sent: Tuesday, October 03, 2006 2:30 PM
> To: 'Eric Weddington'
> Subject: RE: [avr-gcc-list] OT: anyone successfully use the 
> CLKPR feature in themega88?
> 
> Seems unlikely.  That same paragraph is in the m88 data sheet 
> as well (good
> ol' cut 'n paste).  The state machine for changing the register is
> predicated upon CPU clock cycles.  It has to be or the thing 
> wouldn't work
> (hmmm).  All that paragraph says, I think, is that one can't 
> determine the
> exact latency of the switch in order to keep time accurate.
> 
> I don't really care about a  cycle or two in either speed, 
> but I do care
> that when I set the speed back to full blast that it happens 
> *every single
> time* otherwise my internal s/w state machine gets confused 
> and doesn't try
> to reset the speed again.
> 
> Right now I have my code always set the speed back to full on 
> every timer
> tick - occasionally, it misses and a 20ms tick becomes 2 
> seconds...  It
> almost always gets it the second time, but I am not writing 
> code based upon
> that casual observation.
> 
> It is handy that the m88 has a "clock out" option, so I can 
> directly observe
> the internal CPU clock switching (or not, as the case may be).
> 
> | -----Original Message-----
> | From: Eric Weddington [mailto:address@hidden
> ...
> | 
> | Actually it's not off topic. Talking about IAR would be 
> off-topic. ;-)
> | 
> | I'm actually going to be implementing an API for avr-libc 
> for the CLKPR
> | register in the near future.
> | 
> | > The overt symptoms are that the clock doesn't bump up
> | > reliably.  I suspect
> | > that it doesn't bump down reliably either, but at 11mhz &
> | > 50hz timer tick I
> | > wouldn't notice the code taking several tries.  @ 100khz and
> | > .5 hz I notice
> | > when it misses as a complete control cycle occurs at a 
> glacial pace...
> | 
> | Here is this from the ATmega1281 datasheet. Have you seen this?
> | 
> | "The ripple counter that implements the prescaler runs at 
> the frequency of
> | the undivided clock, which may be faster than the CPU's 
> clock frequency.
> | Hence, it is not possible to determine the state of the 
> prescaler - even
> | if
> | it were readable, and the exact timer it takes to switch 
> from one clock
> | division to the other cannot be exactly predicted. From the 
> time the CLKPS
> | values are written, it takes between T1 + T2 and T1 + 2 * 
> T2 before the
> | new
> | clock frequency is active. In this interval, 2 active clock 
> edges are
> | produced. Here, T1 is the previous clock period, and T2 is 
> the period
> | corresponding to the new prescaler setting."
> | 
> | Could this have something to do with it?
> | 
> | Eric
> 
> 
>