Help Understanding the Internal RC Frequency Range on ATMega328P

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

Hi all,

 

I need to use the internal RC oscillator of my ATMega328P and I'd prefer to use the factory calibration rather than perform user calibration.  I've looked at the spec and as I understand it, the range on the frequency is 8.0MHz +/- 10% or 7.2-8.8MHz based on the table:

 

 

Is that correct?  Has someone tested a sample set of these MCUs and seen if this the case or if it is better/worse?

 

Would appreciate any input you have.

 

Thanks!
Matt

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

Yes, it is that "bad".

 

It is pretty good over temperature and supply voltage. But, the unit-unit variation approaches that 10% spec. A fraction is within a few percent of 8MHz.

 

Basically, it is not sufficiently accurate for async serial (e.g. U(S)ART) communications.

 

I do a calibration (which is automatic) against the 32.768KHz crystal that I use for a Real Time Clock.

 

Jim

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

Last Edited: Thu. Dec 6, 2018 - 07:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a hobbyist the Factory Calibration should be fine for USART comms.    Not suitable for accurate timing.

 

Although the Factory calibration is only guaranteed for +-10%,  in practice most chips will be within +-2%.

It would be unwise (tm) to sell a commercial product without calibration.

 

If you own one chip as a hobbyist and it happens to be at the end of range,   you can calibrate it yourself.

If you have several chips,   you check if within 2%.   You only need to calibrate if it is outside 2%.

 

If you have a steady voltage and temperature RC clock with Factory Calibration is ok.

A crystal is accurate and inexpensive.

A ceramic resonator always seems pointless.   It takes board space and is not very accurate.

 

David. 

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

Depending what you need it's sometimes easier just to measure the speed and make a adjustment in SW. (1 hour is xxxx ticks or the UART should be loaded with nnn to give correct speed).   

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

It is pretty simple to just iterate OSCCAL around its Factory Calibration value.

Print a message to the PC Serial Terminal.

You will get character errors at the extremes.

You will have several "good" values of OSCCAL.

Choose the middle value from the good range.

 

Requires no measuring equipment.   No maths.    Just a Serial Terminal.    (which is why you wanted to do UART comms in the first place)

 

David.

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

If serial comms is important for your application or if accurate timing is required, then a xtal is cheap and takes little board space!

If the two requirements above are not needed, then the internal RC is fine.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

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

add to #6

Or most new chips come with a +-2% calibration, get one of those.

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

Or most new chips come with a +-2% calibration, get one of those.

and stay indoors, where the temperature (and therefore, freq) is steady! 

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

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

Again we don't know what OP really need.

 

In most cases an UART is up against a PC with close to 0% error so a error of about 4% is ok.

 

And as it has been up before, if you control both ends you can just use less than 8 bit so +-10% will work (and if that is to slow then use a higher baud rate).

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

Hi all,

 

Thank you for all the great feedback!  The +/-2% number is interesting; we're planning to run at a clean 5V at room temp most of the time, so sounds like we would be fairly safe.

I completely agree that external crystal is the ideal; it just happens in this case that the design didn't have a crystal onboard and my hands are tied.  Work with what you've got :-)

 

We aren't using UART, so safe there.  We're driving a half H-bridge around 40kHz and then outputting a PWM at about 80Hz.

 

Has anyone had luck with the calibration script (AVR053)?  I ran it and posted separately (https://www.avrfreaks.net/commen...); it seems to work well and I got good feedback, though it's automatically saving into flash instead of the EEPROM.  I think with a few tweaks to the script and adding the auto-load of my FW, that may be the way to go if calibration is needed.

 

Best,

Matt

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

I use the Atmel-provided calibration routine. Would not call it a script, by any means. It works well. I modified it slightly to save to the EEPROM which is no big deal.

 

Jim

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

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

stantheman286 wrote:
We aren't using UART,

Than why worry about the frequency at all?   Why does it matter?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

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

Hey Jim,

 

Do you have a copy of the modifications to your script?  If we could just get it into the EEPROM automatically with the script and then read it into OSCCAL, seems like that's the answer.

 

Matt

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

stantheman286 wrote:
If we could just get it into the EEPROM automatically with the script and then read it into OSCCAL, seems like that's the answer.

This seems to be the default for the calibration program talked about in the app note.

 

Section 2.2 Pg 7

The calibration value is stored in EEPROM (skipped if calibration fails)

 

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274