Accuracy of internal RC oscillator for RS-232

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

I'd like to use a ATTiny25 MCU to sending RS-232 output using the internal RC oscillator. I'm familiar with choosing clock crystals with zero error-rate divisors as well as using a 32768Hz crystal for calibrating the RC oscillator using the OSCCAL register.

However, I'd like to have reliable RS-232 communication without any external reference or calibration. I think 2% timing accuracy is sufficient from my application. Reading AVR053, I see that there are multiple RC oscillator versions. From the source code that accompanies AVR053, the ATTinyx5 series uses the 5.0 oscillator.

I've seen some data suggesting that AVR's have an initial RC accuracy of +/- 10-20%, but the RC oscillator can be tuned to 1%.

Examining the datasheet for the ATTiny25, it appears the RC oscillator will be accurate enough for my application without any calibration. Specifically, "Figure 24-35. Calibrated 8 MHz RC Oscillator Frequency vs. Temperature" shows that at 5V, the RC frequency ranges from 7.86MHz at 0C to 8.09MHz at 80C. That's within the 2% specification and should be fine for RS-232 transmission.

My question is how much to believe the ATTiny25 graph. While the graph shows a range of 7.86-8.04MHz over a wide temperature range, are those frequencies subject to that +/- 10-20% accuracy figure quoted elsewhere. If not, what is the accuracy of the Tiny25 compared to the datasheet graph. I can't find a general statement of percentage accuracy of the RC oscillator in the ATTiny25 datasheet.

I've heard that in general PICs have a more accurate RC oscillator. Looking at a 8-pin PIC datasheet, it just shows a +/- 2% accuracy of the RC filter over the 0-85C temperature range -- roughly the same as the ATTiny25 graph in the datasheet.

Thanks for any thoughts.

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

Kevin,

If you use auto-baudrate recognition, the accuracy of the RC-oscillator is (in general) sufficient.

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

That's a good idea, Nard! However, for this application the RS-232 will be transmit only so I won't be able to use baud-rate recognition.

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

Remember that you can also do a one-time calibration when you are programming the chip at room temperature. Then if supply voltage stays the same it should be in good shape across moderate temperature changes.

Note that Atmel is here to help you with app note AVR053.
http://www.atmel.com/dyn/product...

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.

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

Thanks, Lee. You are quite right and I have considered performing that one time calibration. The AVR053 note and source code is quite useful, I did mention that application note in my original post as well. Probably, I will end up performing that one-time calibration as part of the testing/production process. However, I was hoping:

1) to be efficient and skip that calibration step if I could really depend upon the temperature/frequency graph in the datasheet that I referenced in my original post.

2) be assured that I'd be in a 2% error range from 0-80C if that datasheet graph is 100% accurate

Thanks again for your input.

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

I have used UART with the internal RC oszillator several times without to many problems. Most avr units come with the RC oscillator callibrated at 5 V supply. This callibration is usually good enough for UART. The 10-20% is without calibration, e.g. if you change the oscillator settings.

However there are some limits with the internal RC clock, because it uses up a large portion of timing uncertainties allowed in asyncronous comunication.
So you can't have high baudrates, extra errors from the divider or a similar bad clock at the other side of the UART. As an extra precaution 2 stoppbits should be used to get a little more tollerance. Depending on the type of data using the parity bit may also be a good idea. If the clock is realy bad, shorter data length (e.g. 6 Bits or even less can help).

If there is no good reason against a crystal clock, use one if you need the UART.

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

We have a couple products Mega48 & Mega88 that use the internal oscillator (for faster startup from powerdown) and a 32k crystal to tune for serial comms.

The app was working fine. We were working on a test fixture an ran through a batch of boards. Out of curiosity, I jotted down the OSCCAL counts that the tuning routine was using to get as close to 3.67864MHz as practical for about a dozen boards from the same build.

While most of the values were in a cluster (I never noted how much per cent that was off from nominal, nor how much off from factory OSCCAL value), there were several outliers, and one with the "opposite sign" indicating that the 4MHz was actually >>below<< 3.6864.

So I think you may need to do some experimenting to see whether your course of action is feasible.

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.

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

Kleinstein, thanks for your thoughts about increasing reliability. Yes, all my other UART systems used either a crystal oscillator or a 32768 calibration crystal. However, for this ATTiny25, a big part of its appeal will be both the small size (8-pins) and no need for external components for integration into a design.

Lee, I appreciate the info about the sample variation in your batch, especially the outliers. Since the ATMega48 datasheet only shows a single frequency for each temperature at a particular voltage, the fact that there are outliers demonstrates there's some error (undocumented?) between the frequency/temperature graph in the datasheet and the actual frequency.

I'm designing a programmer / hardware tester for the MCU's. At this point, I'm thinking about adding a calibration step that's performed during the programming and testing sequences.

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

Quote:

the fact that there are outliers demonstrates there's some error (undocumented?) between the frequency/temperature graph in the datasheet and the actual frequency.

Not necessarily.

The graphs are >>Calibrated<< RC oscillator frequency. It would be calibrated by applying the factory OSCCAL value, correct? As I noted, I did not pay muuch heed to that number that is loaded at startup, as I hunt for the desired value anyway.

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.

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

Recently I have tested software UART (only output) in Attiny15 and I was surprised: it worked with value of OSCCAL in range from 75 to 255 (factory value beeing 96). Seems to be in conflict with theory, but I am an eye-witness.

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

Lee, thanks for pointing out the difference in Factory versus User calibrations. The datasheet gives a Factory Calibration accuracy of 10% at 25C and 3V, but User calibration accuracies of 1%. So, the factory calibration will not be sufficient.

As for one-time user calibration, it appears the temperature/frequency graph dictates that performance. From 0 to 85C, error is less than 2% so it will be acceptable.

The only other question now is about drift over time. How much can I expect the RC oscillator to vary over the course of months to years after the one-time calibration?

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

Visovian wrote:
Recently I have tested software UART (only output) in Attiny15 and I was surprised: it worked with value of OSCCAL in range from 75 to 255 (factory value beeing 96). Seems to be in conflict with theory, but I am an eye-witness.
Interesting report. Did you measure the RS-232 pulse widths to see how the period changed with various OSCCAL values?

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

Instead I have measured oscillator frequency versus OSCCAL value just now. Here is the result:

Attiny15
osccal   freq
 
30       1326 kHz
40       1359
50       1398
60       1440
70       1478
80       1524
96       1601
150      1613
200      1614 
255      1613

Factory osccal = 96.
The software UART works from 1470 kHz, which is about 8% under nominal value.
I also warmed the chip with solder. At about 50 degC the frequency dropped 7 kHz = 0.44%.

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

Quote:

The software UART works from 1470 kHz, which is about 8% under nominal value.

Remember that that will depend on your RECEIVING end, as well.

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.

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

Quote:

Remember that that will depend on your RECEIVING end, as well.

On the other side I used PC and terminal "AccessPort". Thus the receiver timing was quite exact, I think. I set both sides to 4800 Bd.

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

Including start bit, 9 bits are send together. Timing only neesds to be good enough to seperate bit 9 form 8 or 10. So a limit at 8% of Frequency error is not a suppriese at all.

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

One other issue to consider - RC oscs can be jittery, and specs will usually be the error in the avarage rate, not the peak-to-peak error from cycle to cycle. This could be an issue at higher baudrates, but at lower rates the jitter will probably avarage out to an acceptable level.
I would certainly advise that you make provision for a calibration/test mechanism in production - you cna always choose not to use it if the accuracy proves to be sufficient.