switch clock during runtime and cal. int. oszi to 7.37MHz?

Log in or register to post comments
Go To Last Post
35 posts / 0 new
Author
Message
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
#1
Posted by Baldrian: Tue. Nov 17, 2009 - 12:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Freaks,

I have some questions which I would like to discuss with you.

- Are there any disadvantages when I change the CPU speed from 1Mhz to 4Mhz during runtime? Of course I switch the FreeRtos timing and I'm aware of the delay functions. Beside that, do I have to take anything into account?

- Is it ok, to calibrate the internal Oszillator to 7.3728Mhz to get good usart clocking? From datasheet, I should be able to calibrate from 7.3 to 8.1 Mhz. But what happens if the temperature changes, will I get problems running out of OSCCAL value range during calibration? I know, that the internal oszillator isn't the best for usart communication, but I don't need it all the time, so it is ok I think.

http://xkcd.com/221/

Tags:

Tools, Compilers and General Programming
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101075 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Nov 17, 2009 - 12:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) If the CPU has CLKPR then that's exactly what it is there for - so you can wind up the speed (and power consumption when there's intensive work to be done then wind it back when idle (but also consider sleeping to further extend the battery life)

2) Yes you can reduce the speed to a UART friendly level but how accurate this is depends on your timing reference and if voltage or temperature may wander then consider recalibrating from time to time. But as you need a good reference to calibrate against why not just use a crystal in the first place?

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Tue. Nov 17, 2009 - 01:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
1) If the CPU has CLKPR then that's exactly what it is there for - so you can wind up the speed (and power consumption when there's intensive work to be done then wind it back when idle (but also consider sleeping to further extend the battery life)

2) Yes you can reduce the speed to a UART friendly level but how accurate this is depends on your timing reference and if voltage or temperature may wander then consider recalibrating from time to time. But as you need a good reference to calibrate against why not just use a crystal in the first place?

Thanks clawson,

that's exactly what I hopped to hear :D

For calibration I can use the 32,768kHz rtc crystal. But I don't have an option to change to an external crystal. I'm stuck with the internal as the hardware is allready done.
And as in most development projects, there are comming frome time to time new requirements when the product is almost finished and now I have to find the best way to realize it in software. :lol:

http://xkcd.com/221/

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101075 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Nov 17, 2009 - 01:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

as the hardware is allready done.

Ah the usual story - why do people start the implementation before they've finished the design phase? Oh well.

Anyway, if you have a 32.768kHz crystal then you are sorted. Just use a calibration routine like that in the Butterfly example source code and call it from time to time if the volts/temp may vary and all should be well. To reach those upper baud rates do what you suggested and calibrate to 7.3728MHz

Lee (theusch) has said he does exactly this regularly in his apps and it clearly works very well.

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7104 View posts
Location: Denmark
Posted by sparrow2: Tue. Nov 17, 2009 - 01:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I assume that both questions is about the intern osc.

Quote:

From datasheet, I should be able to calibrate from 7.3 to 8.1 Mhz

So if you stay inside those two values atmel garante that you can find a OSCCAL for that chip.(at all legal volt and temp)
But be very carefull if you plan an do any calibration other than in the production test (read the app. note carefull). It sounds like you plan on makeing a calibration every time will the RS232.
But the intern osc. should work fin if you make a calibration only one time.

Jens

Jens

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Tue. Nov 17, 2009 - 01:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

But be very carefull if you plan an do any calibration other than in the production test (read the app. note carefull). It sounds like you plan on makeing a calibration every time will the RS232.
But the intern osc. should work fin if you make a calibration only one time.
Jens

Ok. Reading the calibration application note carefully, the only thing I could find is: 

Note that the Fast RC oscillator frequency should under no circumstance be calibrated to more than 10% above the nominal frequency, since this may cause EEPROM and Flash access to fail.

Does that mean: When calibrating don't run over 8.1Mhz+10%, otherwise your controller will crash?

Is this what you meant with "read the app. note carefull" or is there some other aspect which I missed when reading about runtime calibration?

http://xkcd.com/221/

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30448 View posts
Location: Wormshill, England
Posted by david.prentice: Tue. Nov 17, 2009 - 02:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Baldrian,

You should be fine. You are using the nominal 8MHz RC clock and then calibrating this for 7.3288MHz. So you are in fact going slightly slower.

The note refers to the fact that eeprom writes are tied to a fixed # of cycles of an internal clock. You are fine for a slower clock.

In practice a 7.3728MHz clock will give perfect UART comms. I suspect that a single calibration will do you fine for the whole of your product's life. If you expect extremes of temperature and voltage, you can always check the calibration.

I alter OSCCAL to obtain 7.3728MHz so that a bootloader can use 115k baud. Then the program runs at 8MHz (and 9600 baud) which suits timing calculations.

If you have a 32kHz watch crystal you can keep a perfect RTC.

(Bald) David.

Top
stu_san
stu_san's picture
Level: Raving Lunatic
Joined: Fri. Dec 30, 2005
Posts: 2321 View posts
Location: Fort Collins, CO USA
Posted by stu_san: Tue. Nov 17, 2009 - 03:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
If you have a 32kHz watch crystal you can keep a perfect RTC.
:twisted: For some value of "perfect". :lol: Other posters have complained about several seconds drift per (week? day? can't remember).

But for the OP's purpose, the 32 KHz crystal is more than accurate enough.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

Top
Koshchi
Koshchi's picture
Level: 10k+ Postman
Joined: Wed. Nov 17, 2004
Posts: 15658 View posts
Location: Vancouver, BC
Posted by Koshchi: Tue. Nov 17, 2009 - 05:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I should be able to calibrate from 7.3 to 8.1 Mhz.

I would not count on that exact range. Each chip is going to be slightly different. Since you are getting close to the low end of the range, it is possible that you won't be able to get to the value you want.

Regards,
Steve A.

The Board helps those that help themselves.

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39996 View posts
Location: Wisconsin USA
Posted by theusch: Tue. Nov 17, 2009 - 06:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

From datasheet, I should be able to calibrate from 7.3 to 8.1 Mhz.

??? What model are we dealing with? That is only -10%/+1% from a nominal 8MHz. A Mega164, for example, shows a range of 5MHz-15MHz of "tuning". roughly the same for a Mega8, Mega48, Mega48PA, and Mega640.

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.

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Wed. Nov 18, 2009 - 08:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's an atmega644PV. And I found out that the OSCCAL Value can go from ~5 to 15 MHZ. And the datasheet says, I should stay between 7.3 and 8Mhz.

The 32kHz works also as RTC. It is quite accurate. :-)

http://xkcd.com/221/

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30448 View posts
Location: Wormshill, England
Posted by david.prentice: Wed. Nov 18, 2009 - 09:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why make life so complicated?

At startup, your AVR reads the 8MHz calibration value from flash into OSCCAL. Adjust it by approximately 7.3728/8.000 by:

OSCCAL = (OSCCAL*236)/256;   // you could use a better magic fraction.

Hey Presto, your AVR is now running at 7.3728MHz (or good enough for comms).
Of course you can do a proper calibration routine. But the rough guess will give you reliable enough comms to get started. If your device is going into mass production then you definitely need to do a proper calibration because there will always be the odd AVR that comes out of the factory +-10% clock accuracy. The vast majority of AVRs will be within +-2%.

David.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101075 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Nov 18, 2009 - 10:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David,

You sure about that? Your equation surely relies on the OSCCAL vs frequency curve being linear? It don't look too linear to me...

(plus you are relying on the factory calibration byte being loaded - true on modern AVRs where there's only one - but on older it's the 1MHz value that is auto-loaded, if you use 2/4/8 you have to manually load the right factory byte)

Attachment(s): 

Image icon osccal.jpg

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7104 View posts
Location: Denmark
Posted by sparrow2: Wed. Nov 18, 2009 - 11:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Read app note AVR053
I'm not sure if it 100% cover the new AVR's
Then main problem is that the speed isn’t monotone you program in blocks (take a look at the curve).

About problem with the 32KHz crystals (like all) need to be trimmed to be accurate if not they will be off but at a very consistent speed so you can make a software trim (for each board ).
I like to do that with a DDS function so you never have missing steps in you time.

Jens

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7104 View posts
Location: Denmark
Posted by sparrow2: Wed. Nov 18, 2009 - 11:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And be carefull using david's way on some of the AVR's just one count off can give more than 1% change in freq. and it's not a linear function.

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Wed. Nov 18, 2009 - 11:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using the way from Atmel App Note AVR351. Works like a charm.

With Davids method I could really run into trouble, because factory calibration is at +-10%. That means, in worst case the expected 8MHZ could be 7.2MHZ. Then adjusting it by approximately 7.3728/8.000, will give a really bad calibration.

http://xkcd.com/221/

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30448 View posts
Location: Wormshill, England
Posted by david.prentice: Wed. Nov 18, 2009 - 12:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know it looks a little simplistic to just to the linear "guess". But it does not go too far wrong. I have only ever calibrated by trying a range of OSCCAL values with the UART and choosing the middle value.

In fact it works a little better than using the graph that you posted. That suggests OSCCAL -= 11 for the initial guess. The simple multiplier suggests OSCCAL -= 15.

Oops. I rather assumed that OSCCAL would be loaded with the 8MHz calibration if the 8MHz fuse was selected on a mega32. However the later AVRs only have a 8MHz oscillator and one calibration.

David.

Edit. I take the point that the simplistic guess is inferior to using a watch crystal. However, it is a very practical method to observe the range of "usable" OSCCAL values for the UART.

    factory = OSCCAL;
    oscdef = factory * (7.328 / 8.0);      //simplistic good guess

    while (1) {
        char step, i;
        for (step = oscdef - 16; step < oscdef + 16; step += 0x1) {
            OSCCAL = oscdef;    // so printf is legible
            printf("\r\nUsing OSCCAL=%02X: [%02X,%02X]", step, oscdef, factory);
            delay_ms(100);      //
            OSCCAL = step;      //do string at this calibration:
            printf("ABCDEFGHIJKLMNOPQRSTUVWXYZ");
            for (i = 0; i < 10; i++) {
                PORTB ^= (1 << 0);      //always nice to flash an LED
                delay_ms(100);
            }
        }
    };
Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39996 View posts
Location: Wisconsin USA
Posted by theusch: Wed. Nov 18, 2009 - 03:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I have only ever calibrated by trying a range of OSCCAL values with the UART and choosing the middle value.

You kids get to work with the nice toyz. Back when I was your age, I had to work with, e.g., Mega88 with the discontinuity in the OSCCAL. From experience, David, I can gar-n-tee that a decent sized batch of Mega88s caled to 7.3728 will end up as a bell curve of OSCCAL counts off of the default loaded value. there will be some outliers at both ends.

It can also make my head hurt in the self-tuning routines when I'm trying to take a nice step in the right direction and the discontinuity hits. I finally gave up and just step in the right direction, rinse, repeat.

We've only just learned that the model is Mega644P. That also has the discontinuity. David, if the factory OSCCAL happens to be to the right of the discontinuity and you step it down a fraction as suggested, you could well end up at 9MHz instead of 7.3,

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.

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7104 View posts
Location: Denmark
Posted by sparrow2: Wed. Nov 18, 2009 - 03:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

some comments
unless you use float some other places that code add a lot extra.
And if you have a watch crystal then use it for the calc of OSCCAL (time the speed factor) even a watch crystal that is way off is still a very very fine reference for a baud rate generator.

Jens

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30448 View posts
Location: Wormshill, England
Posted by david.prentice: Wed. Nov 18, 2009 - 04:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok. If you are going to calibrate a production run of AVRs you will need to cater for worst cases. And you would obviously set yourself up against a known timing source.

However, those punters without oscilloscopes, watch crystals... etc can see some USART output.

Hopefully the initial guess will produce reasonably legible output. If not, you will get a pretty good clue where would be a better place to start. And after one (or possibly possibly two) runs you have found a suitable OSCCAL value.

Yes. If the factory calibration is 0xA0 or less, you will be testing a range like 0x80..0xA0 or 0x70..0x90 . I am sure that there will be factory calibrated devices with smaller values, and hence catch the discontinuity. And I would have to make a more sophisticated loop.

I have only encountered calibration bytes between 0xB0 and 0xD0. What extreme values have other people seen?

David.

Top
skeeve
skeeve's picture
Level: Raving Lunatic
Joined: Sun. Oct 29, 2006
Posts: 5392 View posts
Posted by skeeve: Wed. Nov 18, 2009 - 04:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

From datasheet, I should be able to calibrate from 7.3 to 8.1 Mhz.

??? What model are we dealing with? That is only -10%/+1% from a nominal 8MHz. A Mega164, for example, shows a range of 5MHz-15MHz of "tuning". roughly the same for a Mega8, Mega48, Mega48PA, and Mega640.
The Table taketh and the Figure giveth back.

Iluvatar is the better part of Valar.

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39996 View posts
Location: Wisconsin USA
Posted by theusch: Wed. Nov 18, 2009 - 04:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I have only encountered calibration bytes between 0xB0 and 0xD0. What extreme values have other people seen?

Out of a batch of 20+ Mega88s, I had two that were below 128/0x80.

Several were above but close to 128, and tuning to 7.37MHz involved jumping the discontinuity.

That first one that went across drove me nuts till I figured out it was because of the discontinuity. I was trying to be clever and "jump" a number of steps in the right direction to settle faster--i.e., "P" proportional gain.

When I found the cause I decided it just wasn't worth it as there were too many cases around the discontinuity. So now I just step a single OSCCAL click each tuning cycle and get there eventually. (In this app "time to settle" is immaterial, as it has backup battery power so once tuned it stays there. Yes, in long periods of sleep if the temperature changes a lot then it could be off a bit but not that far.)

========================
Let's revisit something else, though:

Quote:

And the datasheet says, I should stay between 7.3 and 8Mhz.

Now that we finally know the model number I looked that up.

I am pretty sure that the datasheet mention of 7.3-8.1 is not "range you should stay in", but rather "this is the range you can expect the 8MHz clock to be in when the default OSCCAL value is applied at startup". Tune with OSCCAL all you want. In newer models that use a different oscillator for EEPROM I think you can even go up to whoopee-fast if you like. Certainly tuning to 7.37MHz won't be a problem.

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.

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7104 View posts
Location: Denmark
Posted by sparrow2: Wed. Nov 18, 2009 - 09:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I read it the way that if you want a freq in the 7.3 to 8.1 MHz range you can find a OSCCAL for that, or in other words all chip will run slower than 7.3 with OSCCAL=0 and faster than 8.1 if it's 0xff.

Jens

Edit
and I would start with a OSCCAL of 0 and that step up until I get the freq I want, that should allways work, and the chip should allways run at legal speed.

Top
skeeve
skeeve's picture
Level: Raving Lunatic
Joined: Sun. Oct 29, 2006
Posts: 5392 View posts
Posted by skeeve: Wed. Nov 18, 2009 - 10:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking again, I think that 7.3-8.1 MHz is the range
in which one can expect to get 1 percent accuracy.

Iluvatar is the better part of Valar.

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39996 View posts
Location: Wisconsin USA
Posted by theusch: Wed. Nov 18, 2009 - 10:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

and I would start with a OSCCAL of 0 and that step up until I get the freq I want, that should allways work, and the chip should allways run at legal speed.

It would always work--but so does starting at the middle, or the factory OSCCAL value--and that will be a >>lot<< closer to the destination.

That can be important if you do like I do with a watch crystal for calibration. I let that run for 1/4 or 1/2 second and then see how many counts are in a free-running Timer1. If I indeed need many steps then it takes many seconds.

Yes, one can use smaller fractions of a second. My way worked best for me, given the parameters of my apps: battery-backup, so although a more-or-less continuous recal when primary power is available, the full seek only needs to be done theoretically once at startup after programming.

As I mentioned, I was going to take bigger steps when known to be farther away. Then one of my units fell into the discontinuity so I went back to single-step rather than jumps. YMMV

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.

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7104 View posts
Location: Denmark
Posted by sparrow2: Wed. Nov 18, 2009 - 11:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To Lee
But then you have the risk of OC the chip in the proces !

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39996 View posts
Location: Wisconsin USA
Posted by theusch: Thu. Nov 19, 2009 - 03:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

OC

OC? Over Clock? (If so, I don't see how that could happen.)

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.

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7104 View posts
Location: Denmark
Posted by sparrow2: Thu. Nov 19, 2009 - 12:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To Lee
The chip should never run faster than 8.8MHz (from the data sheet) because then the eeprom and flash could fail.
If you have a chip that run faster than 8.8 MHz at 0x7F and below(Edit should be above) the speed you want at 0x80, your rutine easy could overclock before it find the correct value.

Jens

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30448 View posts
Location: Wormshill, England
Posted by david.prentice: Thu. Nov 19, 2009 - 01:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wondered what OC was supposed to mean.

Both Baldrian and Lee were trying to set the RC clock to a speed lower than 8MHz.

I would assume that the AVR core itself will depend on the Vcc and clock speed. i.e. if the AVR can run at 20MHz and 5V.

If the clock source is RC, external or crystal oscillator is immaterial for the core.

Now the actual RC subfunction may be fussy about certain values. The stability may suffer at extreme values. In my experience it still actually oscillates though. And if you can achieve 16MHz, the core will still run if it has sufficient Vcc.

I take your point about the eeprom writing. It would be wise to allow a little more time for write completion.

David.

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39996 View posts
Location: Wisconsin USA
Posted by theusch: Thu. Nov 19, 2009 - 02:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The chip should never run faster than 8.8MHz (from the data sheet) because then the eeprom and flash could fail.
If you have a chip that run faster than 8.8 MHz at 0x7F and below(Edit should be above) the speed you want at 0x80, your rutine easy could overclock before it find the correct value.

Quote:

Both Baldrian and Lee were trying to set the RC clock to a speed lower than 8MHz.

As I'm tuning down, I'd find it quite unlikely that the factory OSCCAL value used as a starting point would be outside safe operation limits.

[lol--even better, my apps use CLKPR of /2 and tune to 3.6864MHz (or as close as I can get).]

We finally learned that we are dealing with a '644. That chip, and all "late mode" AVRs, don't use the internal oscillator under discussion for EEPROM timing but rather the 128kHz (?) clock that I think is used for watchdog and other purposes. As such, datasheets for these models don't have the dire warning about OSCCAL going too high.

Flash read? I can't see where that would ever be a problem unless you'd crank OSCCAL all the way up and perhaps running at lowest voltage. (Remember that as we migrate to all "PA" chips there are no speed grades, so flash reads are then obviously good at all speed/voltage combinations.)

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.

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7104 View posts
Location: Denmark
Posted by sparrow2: Thu. Nov 19, 2009 - 04:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to make it clear
Just because a chip can run 20MHz doesn't mean that it is garantiet to run ex. 10 MHz using the intern osc.

My ref to Lee is NOT about the 644 but the 48 and 88 that I do know he/you use.

And a look at both the 48/88 and 644 datasheets a 0x7f will give a freq over the 8.8 MHz that is max. using the intern osc. (it looks like it will run in the ballpark of 10MHz). And that is why I state that it's an OC (over clock).

Jens

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39996 View posts
Location: Wisconsin USA
Posted by theusch: Thu. Nov 19, 2009 - 05:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

And that is why I state that it's an OC (over clock).

My caps lock is sticking... ;)

WHY DO YOU THINK THERE WILL BE AN EEPROM PROBLEM AT ANY SPEED?

Why would the Atmel-default OSCCAL value be out-of-spec? Nearly all internal oscillator apps will just use that without tuning.

Did I ever say anything about starting at 0x7f?

Why do you feel that 8.8MHz is a magic number?

We all know that a chip rated to run at n MHz at z voltage over all conditions isn't going to drop over dead at n.000001 MHz under normal conditions.

===================
Aaah! I found the dire warning in an "older" Mega88 datasheet:

Quote:
Note that this oscillator is used to time EEPROM and Flash write accesses, and these write times will be affected accordingly. If the EEPROM or Flash are written, do not calibrate to more than 8.8 MHz. Otherwise, the EEPROM or Flash write may fail.

Well, I ain't gonna do any flash writes, much less during calibration. EEPROM writes? Hmmm---I do indeed do continuous/periodic recals, so other parts of the app may do EEPROM writes. My apps use /2 and cal down to 3.68MHz so it is moot anyway, right?

Quote:

My ref to Lee is NOT about the 644 but the 48 and 88 that I do know he/you use.

But late in the thread, OP finally said that the '644PV was being used.

================================
I retract it all! You are a better datasheet reader than I am--PA datasheets do in fact contain the dire warning. So I see your point as you could be calibrating a bit above the dire limit while hunting for the right value.

In practice, I don't think it would ever be a problem when down-clocking. And never a problem with /2 or greater prescalers?

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.

Top
skeeve
skeeve's picture
Level: Raving Lunatic
Joined: Sun. Oct 29, 2006
Posts: 5392 View posts
Posted by skeeve: Thu. Nov 19, 2009 - 06:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
Just to make it clear
Just because a chip can run 20MHz doesn't mean that it is garantiet to run ex. 10 MHz using the intern osc.

My ref to Lee is NOT about the 644 but the 48 and 88 that I do know he/you use.

And a look at both the 48/88 and 644 datasheets a 0x7f will give a freq over the 8.8 MHz that is max. using the intern osc. (it looks like it will run in the ballpark of 10MHz). And that is why I state that it's an OC (over clock).

According to the speed grades section,
10 MHz is in the safe operating area above 2.7 volts.
That doesn't mean that everything will work.
If the frequency is 9 MHz, don't write EEPROM or flash.
Of course one could use the prescaler to prevent
overclocking during the initial calibration.

Iluvatar is the better part of Valar.

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7104 View posts
Location: Denmark
Posted by sparrow2: Thu. Nov 19, 2009 - 06:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Aaah! I found the dire warning in an "older" Mega88 datasheet:

So where do you get a newer one, the note is still in the mega88PA datasheet.
Quote:

But late in the thread, OP finally said that the '644PV was being used.

I think we lost him a while ago.

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Fri. Nov 20, 2009 - 08:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
Quote:

I think we lost him a while ago.

Nope. Still here and following :D

To sum things up. I use the calibration method AVR055 to calibrate my internal oszillator. This works like a charm.

And the switching from 1 (or 0.96) to 4MHz (or 3.6864) works also as expected, getting my external Flash and eeprom read down to 1/5 of time. saving me (after doing some measurment) abotu 3/4 of power. 8)

http://xkcd.com/221/

Top