ATmega's internal oscillator - how bad is it?

Other Hardware 3rd Party Boards
1

A question for the experts, if anyone happens to know. I've read at least one mention (actually, in the avr-gcc FAQ of all places) that the internal RC oscillator in specific/some/all ATmegas is not reliable enough for timing-critical tasks, including transmitting via RS232.

Running from the internal oscillator would be highly desirable for my purposes (lowest power consumption, faster start-up time), so I'm dying to know: is the RC oscillator on commonly Arduino-ized ATmegas (168/328, 644, 1284) as bad as it's made out to be for RS232 communication? The operating voltage will be fixed during operation with a PC attached, and probably at "room temperature" (extremes of maybe 60-95F depending on user's location and season).

The datasheet claims the RC oscillator can be "very accurately" calibrated via the user OSCCAL register for a given voltage and temperature range ... but is this value stable over time?

2

Drmn4ea:
A question for the experts

That probably excludes me but I'll give it a go.

I've read at least one mention (actually, in the avr-gcc FAQ of all places) that the internal RC oscillator in specific/some/all ATmegas is not reliable enough for timing-critical tasks, including transmitting via RS232.

That is not exactly what was stated but I'll play along.

is the RC oscillator on commonly Arduino-ized ATmegas (168/328, 644, 1284) as bad as it's made out to be for RS232 communication?

Maybe. For reliable serial communications, the clock needs to be better than about ±4.5%. From the factory, the oscillator is guaranteed to be ±10%. In my very limited testing, 5 out of 6 processors fresh from the factory had clocks good enough for serial communications. I was able to use them without any tuning.

The datasheet claims the RC oscillator can be "very accurately"

The claims is ±1% which is more than good enough for serial communications.

calibrated via the user OSCCAL register for a given voltage and temperature range ... but is this value stable over time?

Yes. Well, I've never seen any mention of the oscillator wearing over time.

In my experience, the oscillator has a moderate dependence on voltage and a low dependence on temperature (around room temperature). If the two are stable, I can consistently tune the oscillator to about ±0.25%. I suspect Atmel's number (±1%) is over the entire temperature / voltage range (or at least a big part of that range). In your case, once you've tuned the oscillator, you should have no problems with serial communications. Try to tune at the middle temperature (and do some testing at the extremes).

Bear these things in mind...

[#] EACH PROCESSOR IS UNIQUE. You cannot tune one and expect the OSCCAL value to work on another.

[#] When more current is flowing through the processor (lots of HIGH OUTPUTs), the processor will warm a bit which changes the oscillator speed. In my experience, this has a minor effect on the tuning but you should perform your own testing.

[#] Atmel's tuning algorithm places the OSCCAL value in EEPROM address zero. I suggest doing something similar. In my case, I store a "magic value" (addresses zero and one) and a version number (address three) so the Sketch can tell if a tuning value is available.

This can be used to tune the oscillator...

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1287558192

It's packaged for three ATtiny processors but it can easily be modified to work with other processors.

3

You know you can get 16MHz crystals and 22pF caps for tens of pennies don't you?
http://www.dipmicro.com/store/XC7-16000
http://www.dipmicro.com/store/C1K22-1000
Spend a dollar and take the concern out of the picture. Buy a few sets for your next project too. 4 crystals and 10 caps will be $1.60, plus ~$2 in shipping.
I've built up several standalone designs with these parts, all wirewrapped together and sending 4800BPS RS232 to each other.

"The operating voltage will be fixed during operation with a PC attached" --> so you've a good 500mA supply to work from to source the 25mA an ATMega needs.

4

CrossRoads:
You know you can get 16MHz crystals and 22pF caps for tens of pennies don't you?
16MHz Crystal HC49US - dipmicro electronics
22pF/1000V Radial Ceramic Disc Capacitor - dipmicro electronics
Spend a dollar and take the concern out of the picture. Buy a few sets for your next project too. 4 crystals and 10 caps will be $1.60, plus ~$2 in shipping.
I've built up several standalone designs with these parts, all wirewrapped together and sending 4800BPS RS232 to each other.

"The operating voltage will be fixed during operation with a PC attached" --> so you've a good 500mA supply to work from to source the 25mA an ATMega needs.

What if, the crystal pins are needed?

5

"PB7
XTAL2 (Chip Clock Oscillator pin 2)
TOSC2 (Timer Oscillator pin 2)
PCINT7 (Pin Change Interrupt 7)

XTAL2: Chip clock Oscillator pin 2. Used as clock pin for crystal Oscillator or Low-frequency
crystal Oscillator. When used as a clock pin, the pin can not be used as an I/O pin.

TOSC2: Timer Oscillator pin 2. Used only if internal calibrated RC Oscillator is selected as chip
clock source, and the asynchronous timer is enabled by the correct setting in ASSR. When the
AS2 bit in ASSR is set (one) and the EXCLK bit is cleared (zero) to enable asynchronous clocking
of Timer/Counter2 using the Crystal Oscillator, pin PB7 is disconnected from the port, and
becomes the inverting output of the Oscillator amplifier. In this mode, a crystal Oscillator is connected
to this pin, and the pin cannot be used as an I/O pin.

PCINT7: Pin Change Interrupt source 7. The PB7 pin can serve as an external interrupt source."

I suppose they could be. Every application is different.

6

in the 32 kb range with 28 pins, it makes some difference... It did to me a few years ago at least. :\

on the others (40 pins and higher, since it's dedicated pins) it doesn't , so running the external crystal is the way to go there. Unless you want to save board space.

7

You know you can get 16MHz crystals and 22pF caps for tens of pennies don't you?

Yes, my current board has a crystal already :slight_smile: My main interest in trying the RC oscillator is to reduce power consumption and start-up time. In unrelated low-power gadgets I design for my day-job, it is not uncommon for the circuit to wake up and complete an atomic task in a few msec... trying to bring a handful of these types of applications to Arduino, it will be best if half that time is not spent waiting for the crystal to start :wink: I was just curious if the RC osc. is even an option worth considering, since loss of RS232 programming would be a dealbreaker.

so you've a good 500mA supply to work from to source the 25mA an ATMega needs.

I should have been more clear - during programming (or use / proximity to a serial port), the operating voltage and temperature will be constrained by being powered by a PC, presumably indoors. In other words, I don't necessarily need or expect the RS232 timing to be valid over the entire operating voltage and temperature range, even though actual usage (far from a PC) will cover the entirety of those ranges.

@CodingBadly - Thanks for this info! I was worried that even "user-tuned" the accuracy would be terrible over modest temperature changes. My board will have an RTC onboard by default, so it could be used as a clock source for tuning if needed, but likely not from inside a bootloader. I'll definitely keep footprints for a crystal in anycase, but I'll give the RC a whirl.

8

Does the external crystal increase power consumption? :expressionless: Isn't it negligible?

9

bubulindo:
Does the external crystal increase power consumption?

The datasheet indicates that, all other things being equal, the internal oscillator uses less power than an external "high frequency" crystal.

10

Drmn4ea:
I've read ... the internal RC oscillator in specific/some/all ATmegas is not reliable enough for timing-critical tasks, including transmitting via RS232.

A fair bit would depend on the baud rate I would think. The oscillator may be out but is hardly going to wobble all over the place (or would it?). At fairly low baud rates a bit each way is hardly going to matter.

In any case I would have thought you could tolerate about 9% error on RS232. Since you are transmitting 10 bits (and then it resynchronizes on the next start bit) for the sampling to be wrong it would need to be 10% out by the end of the 10th bit.

I would try it, and do some measuring with a logic analyzer. See what typical errors you get. Dropping the baud rate would mask the problem I would think, it depends how fast you need it to be. If the error rate is constant (eg. always 1% fast) then you can compensate for that.

In fact I think the old chronometers that they carried on ships didn't necessarily tell the correct time, the important thing was that they were consistent. For example, if you knew that the chronometer always lost exactly 5 seconds a day, then you just build that into your calculations.

11

No "wobble". It's a stable beast. Well, a wildly fluctuating supply voltage would wreak havoc but I suspect @Drmn4ea will keep that problem at bay.

In any case I would have thought you could tolerate about 9% error on RS232.

It depends. :smiley: I throw out "4.5%" because, generally, better than that means serial communications is very likely to work.

Since you are transmitting 10 bits (and then it resynchronizes on the next start bit) for the sampling to be wrong it would need to be 10% out by the end of the 10th bit.

The 10% is total clock error. It's important to remember that the other side may also have a clock error. It's also important to remember that for an 8 MHz (or 1 MHz) processor clock, very few baud rates are accurate. This is a nice overview (search for "Usable Baud Rates")...
http://www.pjrc.com/teensy/td_uart.html

Dropping the baud rate would mask the problem I would think

I don't know if it does in general but I can say that lower baud rates help if the receiver has a modern hardware UART (one that performs multiple samples in each bit time).

12

Ok... I didn't found that part. I'd suspect that the only major power consumption would be caused by the higher frequency of the crystal compared to the internal one and not whether it was internal or external. :\

13

Figure 29-331.ATmega328P: Active Supply Current vs. Frequency (1-20 MHz)
Going up the 8 MHz line to 5.0 V we reach an Icc of about 5.5 mA.

Figure 29-334.ATmega328P: Active Supply Current vs. VCC (Internal RC Oscillator, 8 MHz)
Going up the 5 volt line to 25° C we reach an Icc of about 5.5 mA.

According to the datasheet there appears to be no significant difference in current (power) consumption between the internal oscillator running at 8 MHz and an external 8 MHz crystal. My apologies.

14

No apologies needed. I didn't find it (although, the internet didn't let me scroll to the end of the document) and couldn't figure out what would cause it to consume more power at the same frequency.

Thanks for the pointers. :wink:

15

Interesting thread - I wanted to add an interesting link I found on reducing power consumption in atmega devices - http://www.atmel.com/Images/doc8267.pdf

Cheers,
Sridhar

16

I am puzzled by this assertion. Why would the baudrate make a difference? A given percentage is a given percentage at any speed.

Not to be confused with the difficulty finding an accurate divisor to obtain the baudrate. Obviously, the greater the division value to obtain the baud clock, the closer to the nominal baudrate it can be made. That said, if only the baudrate was critical, OSCCAL would allow it to be "tweaked" to improve the accuracy.

17

its actually true that internal rc 8mhz clock provides more reliable 115kbaud communication than with a crystal (i remember when this statement almost got me run out of town... my how things have changed. lol). internal is my preferred setup these days, not only because those two crystal pins become available for io, but its the ONLY way to implement a truly accurate avr low power calendar clock (watch crystal). this cannot be done with the standard arduino 16mhz.