Xtiny accuracy of 20MHz intern clk

Log in or register to post comments
Go To Last Post
16 posts / 0 new
Author
Message
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7364 View posts
Location: Denmark
#1
Posted by sparrow2: Mon. Jan 29, 2018 - 10:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been reading the datasheet for tiny817

 

And I'm a bit confused about the accuracy of the 20MHz (guess 16MHz is the same).

 

What is the difference (Table 34-12) between :

 

Accuracy with 16MHz and 20MHz Frequency Selection relative to the factory-stored frequency value  

and 

Accuracy with 16MHz and 20MHZ Frequency Selection 

 

first is max 2% error and the other about 4% (depends) .

 

 

Have anyone measured the speed?

 

and next step is how accurate a number do you get when :

 

• SIGROW.OSC20ERR3V is the frequency error from 20MHz measured at 3V

• SIGROW.OSC20ERR5V is the frequency error from 20MHz measured at 5V 

Are used?

 

I don't really care about the speed, I just need to know how accurate time can be that way.

 

 

 

 

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
balisong42
balisong42's picture
Level: Hangaround
Joined: Fri. Mar 20, 2009
Posts: 299 View posts
Location: Seattle, WA, USA
Posted by balisong42: Tue. Jan 30, 2018 - 12:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Over the full temperature and voltage range, the factory calibration will be within 5% of selected frequency.

Within the narrower range of 1.8-3.6V & 0-70*C, the factory calibration will be within 4% of selected frequency.

With a well regulated 3V supply in a temperature controlled room @ 25*C, the factory calibration can still be 3% off.

A baudrate error within 2% can be achieved at 3V or 5V by using the recorded error values as shown in 10.3.4.1.

 

So the oscillator is accurate enough for UART at some baudrates and conditions.

I wouldn't use it for a clock.

 

 

Top
Paulvdh
Paulvdh's picture
Level: Raving Lunatic
Joined: Fri. Aug 3, 2001
Posts: 2802 View posts
Posted by Paulvdh: Tue. Jan 30, 2018 - 06:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
And I'm a bit confused about the accuracy of the 20MHz
The main thing to remember is that the RC oscillator is not very accurate.

Why would you care if its 2% of or 5% ?

If your circuit is timing sensitive, then add a 20ct crystal.

If your cicruit is not timing sensitive, then just stop worrying.

 

Your datasheet is a pdf , right?

Do a text search for "RC" "accuracy" etc.

 

balisong42 wrote:
So the oscillator is accurate enough for UART at some baudrates and conditions.
Are you kidding?

Error is a percentage and this will be true for all baudrates.

With a 2% error of your clock you've consumed about all safety margins for uart communication.

Every time your neighbour farts in the wind you'll get uart errors.

Or:

It all seems to work during software development and after you've deployed your circuit the uart stops working.

Don't use RC oscillators for uarts. Just don't.

The only way I'd consider using an RC oscillator for a uart if it has a GUARANTEED accuracy of better tan 1% over a decent temperature range.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7364 View posts
Location: Denmark
Posted by sparrow2: Tue. Jan 30, 2018 - 06:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Remember that this chip can't use a normal 20MHz (or 16) crystal, and they made this  so the UART can run from the internal clk.

 

 

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30664 View posts
Location: Wormshill, England
Posted by david.prentice: Tue. Jan 30, 2018 - 07:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Many microcontrollers and peripheral chips have Internal RC clocks with either Factory calibration or on-die laser trimming.
The 'other' manufacturers provide better accuracy and stability than the 15-year old AVR RC design.
The Xmega has a better RC. The Tiny1634 has a better RC. A 2017 chip should be better than the old AVR RC.
.
Obviously you would never consider RC for Guided Missiles or an Olympic Record Clock.
.
UART comms can be practical. Even the old RC can self-calibrate. AVR with internal Temp Sensor can adjust for temperature. AVR with ADC can adjust for VCC.
But an improved modern RC should do its own thermal and voltage adjustments i.e. by Silicon design.
.
David.

Last Edited: Tue. Jan 30, 2018 - 07:41 AM
Top
m.majid
m.majid's picture
Level: Hangaround
Joined: Fri. Dec 5, 2008
Posts: 181 View posts
Location: Türkiye
Posted by m.majid: Tue. Jan 30, 2018 - 07:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
Have anyone measured the speed?

 

I did test using factory stored calibration

I did not use SIGROW.OSC

 

ATtiny816-MNR

Vcc 5 V 

20MHz 

UART 250Kbps, 8 bit data

for Tx data=0x55 I measured 9 bit (1start+8data) for 2 separate chips

 

-40°C : 36.6 us (e=%1.6)

-40°C : 36.8 us (e=%2.2)

25°C : 36 us (e=0)

+140°C : 35.6 us (e=%1.1)

+140°C : 35.8 us (e=%0.5)

 

 

 

Majid

Top
Paulvdh
Paulvdh's picture
Level: Raving Lunatic
Joined: Fri. Aug 3, 2001
Posts: 2802 View posts
Posted by Paulvdh: Tue. Jan 30, 2018 - 09:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

While writing the post above I overlooked you are a 16 year member and have over 5600 posts.

I had a peek at the tiny817 datasheet and was surprized they omitted the crystal oscillator in combination with such a crappy RC oscillator substitute ???

It sounds pretty silly to omit the crystal oscillator if they can't get the RC within 1%.

When searching for "oscillator" I found the graphs starting at page 464 with characterisations of RC oscillator with temperature & Vcc.

It seems that if you keep Vcc stable then the temperature stability seems reasonable enough for uart communication.

You might have to do a callibration in advance. Haven't looked into that.

There is also a temperature sensor inside.

You can use that & the characterisation graphs to make an estimate callibration value if your uC is expected to experience high temperature differentials.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7364 View posts
Location: Denmark
Posted by sparrow2: Tue. Jan 30, 2018 - 10:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

remember if you want it better it has a 32768 hz xtal osc.

But I just wanted to how good the internal RC really is.

 

It seems these chips and 324pb and 328pb are made in a process that have problems with xtals ! (but it seems that the 328pb internal is RC is better that old AVR's, I use UART from 20-80C when debugging without problems, (but it has a PC at the other end so there the error is 0%))  

Top
Paulvdh
Paulvdh's picture
Level: Raving Lunatic
Joined: Fri. Aug 3, 2001
Posts: 2802 View posts
Posted by Paulvdh: Tue. Jan 30, 2018 - 10:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
It seems these chips are made in a process that have problems with xtals
Seems very unlikely. It's got a 32kHz oscillator and ADC. The crystal oscillator is nothing more than an inverting amplifier. Any 74hcu04 can do the job.

 

sparrow2 wrote:
(but it has a PC at the other end so there the error is 0%))
This is a very near sighted assumption.

In my self designed home network packets are sent over RS485 and I have an AVR to slightly transform RS232 data to RS485. (It modifies the headers in a non-compatible way).

I experienced errors with longer packets.

To save some time the AVR buffered 4 bytes before it started to send to the RS485 network, and then simply kept on sending data as long as there was data in it's circular buffer.

While debugging I discovered that buffering 4 bytes was not enough and the buffer ran empty halfway a packet because the AVR was sending faster ( 200ppm Xtal correct oscillator) than the PC send the data. Even though the data stream from the PC was continuous. The baudrate error was too big.

That was some time ago. I think is was a Mostek PCI serial port.

RS232 is not a big thing in the PC world and price is considered more important than accuracy.

Al those cheap USB adapters run from 12MHz crystals or something and I don't expect them to generate very accurate baudrates.

That's part of the reason I want a pretty decent baudrate generator for my AVR's. All the errors add up.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Tue. Jan 30, 2018 - 10:35 AM
Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30664 View posts
Location: Wormshill, England
Posted by david.prentice: Tue. Jan 30, 2018 - 10:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I doubt if the fabrication process is a problem. More likely to be a "Marketing" problem. They have designed the Silicon for low power and forgotten about reliability.
.
Low power xtal drive means slower startup and less ability to cope with poor quality crystals.
Yes, sleep current is important. The xtal power is insignificant when awake. In an ideal world you use RC when asleep and switch to HF xtal for breakfast. However this is not backward compatible.
Existing low power apps use RC when asleep and LF xtal for accuracy.
.
@Paulvdh,
Surely your experience is a software design problem.
.
David.

Last Edited: Tue. Jan 30, 2018 - 10:49 AM
Top
rammon
rammon's picture
Level: Hangaround
Joined: Tue. Jan 30, 2018
Posts: 151 View posts
Posted by rammon: Tue. Jan 30, 2018 - 11:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:

sparrow2 wrote:
It seems these chips are made in a process that have problems with xtals
Seems very unlikely. It's got a 32kHz oscillator and ADC. The crystal oscillator is nothing more than an inverting amplifier. Any 74hcu04 can do the job.

 

Not quite so. Achieving low power is not so easy with an 74hcu04. I'm using external oscillators based on hcu04 chips, and the power is 6-7mA with an 1K Rs which gives you not even full swing (at 5V it is 4V pp). Put a scope and see the waveform of the internal oscillator (or try to achieve the current consumption of the internal oscillator with external components).

 

The problem is that the low power means very high sensitivity to noise. And that's a very sad thing about these new chips. I have boards in very noisy industrial fields based on old atmega328 with crystal which don't have any problem. When I put a board based on a ATmega328PB, also with crystal, it failed. That's why I'm using "external" oscillators base on HCU04 chips with the new AVRs. More power, but they works!

 

BTW, they fully specified that the full swing oscillator option fuse is gone in newer PB devices. I suspect this is the case for newer attiny's too.

 

sparrow2 wrote:
(but it has a PC at the other end so there the error is 0%))
This is a very near sighted assumption.

In my self designed home network packets are sent over RS485 and I have an AVR to slightly transform RS232 data to RS485. (It modifies the headers in a non-compatible way).

I experienced errors with longer packets.

To save some time the AVR buffered 4 bytes before it started to send to the RS485 network, and then simply kept on sending data as long as there was data in it's circular buffer.

While debugging I discovered that buffering 4 bytes was not enough and the buffer ran empty halfway a packet because the AVR was sending faster ( 200ppm Xtal correct oscillator) than the PC send the data. Even though the data stream from the PC was continuous. The baudrate error was too big.

That was some time ago. I think is was a Mostek PCI serial port.

RS232 is not a big thing in the PC world and price is considered more important than accuracy.

Al those cheap USB adapters run from 12MHz crystals or something and I don't expect them to generate very accurate baudrates.

That's part of the reason I want a pretty decent baudrate generator for my AVR's. All the errors add up.

 

That's plain wrong. At least about the usb-uart converters. The 12MHz should be very precise no matter how cheap the device is. It's about USB specs, which is at least one order of magnitude better than what an uart needs. They are forced to use a precise time base, so uart will use it too. I can't know about other PC i/o things, but it's very unlikely that they are not based on crystals.

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7364 View posts
Location: Denmark
Posted by sparrow2: Tue. Jan 30, 2018 - 11:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems very unlikely. It's got a 32kHz oscillator and ADC. The crystal oscillator is nothing more than an inverting amplifier. Any 74hcu04 can do the job.

I mean high speed not the 32KHz.

 

324pb and 328pb can't run 20MHz from a xtal like "real" 324 and 328.

Top
rammon
rammon's picture
Level: Hangaround
Joined: Tue. Jan 30, 2018
Posts: 151 View posts
Posted by rammon: Tue. Jan 30, 2018 - 11:34 AM (Reply to #12)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Seems very unlikely. It's got a 32kHz oscillator and ADC. The crystal oscillator is nothing more than an inverting amplifier. Any 74hcu04 can do the job.

I mean high speed not the 32KHz.

 

324pb and 328pb can't run 20MHz from a xtal like "real" 324 and 328.

 

What do you mean? I'm using 328PB with crystal (not 20MHz though).

But I had bad experiences with it (the crystal oscillator is weak and susceptible to noise) in some applications and since then I'm using an external crystal oscillator based on a HCU04 gate no matter what.

 

It seems that they learned that their oscillator is not good and took it off completely in the new tiny's :)

(It's not new, old tiny's have the same situation, see attiny48/88).

Fine for me :)

 

Top
rammon
rammon's picture
Level: Hangaround
Joined: Tue. Jan 30, 2018
Posts: 151 View posts
Posted by rammon: Tue. Jan 30, 2018 - 11:49 AM (Reply to #8)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No problem about the process other than being low power and very high impedance (weak) it is susceptible to noise. I have applications that work, and applications that don't (with a 328PB with crystal).

 

+/-2% is really good if you use the ubiquitus 8N1 format (or a 10bit frame). For a 10bit frame the error margin is somewhere around 4.5%, they cut it to 4% (just in case...) and then divide it by 2 assuming that in the worst case you have a device with +2% at one end and a device with -2% at the other end.

 

The PC is almost sure 0.00 to 0.16% for common baudrates.

 

I have lots of devices in the field with +/-2% RC, +/-1.5% RC and +/-1% RC, but specified for the entire temperature range. No problems.

 

Silabs make devices with internal RCs from 0.5% to 2%. NXP/Freescale make devices with 1% to 1.5%.

They can. Others can't.

 

 

Top
Paulvdh
Paulvdh's picture
Level: Raving Lunatic
Joined: Fri. Aug 3, 2001
Posts: 2802 View posts
Posted by Paulvdh: Tue. Jan 30, 2018 - 11:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@david: Yes it was a software problem, but it would never have shown it's ugly head if the PC's uart baudrate was closer to the expected theoretical value.

 

The 12MHz (or 48) Crystals are of course fairly accurate for the USB side, but not readily divisible for "standard" UART baud rates.

This means some fractional baudrate generator is implemented in the USB <--> Uart chips and the accuracy of those is dependent on the scheme used.

DDS chips use a good algorithm ( such as a 24 bit accumulator or more). For uarts 6 bits (Tiny817) is often deemed "accurate enough". But that's certainly not " 0% ".

Those Fractional algorithms also add jitter which gets noticable if the output frequency gets near the input frequency.

 

Datasheet of PL2303 has no info on this.

Datasheet of CH340 says: The baud rate error of serial transfer signal is less than 0.3%, and permission baud rate error of serial receive signal is not less than 0.2%.

 

@Rammon: Where does your " 0.16% " quote come from?

 

And who knows what other hardware manages to spit out a serial stream in this crazy world.

Just be carefull with the assumptions you make.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Tue. Jan 30, 2018 - 12:00 PM
Top
rammon
rammon's picture
Level: Hangaround
Joined: Tue. Jan 30, 2018
Posts: 151 View posts
Posted by rammon: Tue. Jan 30, 2018 - 12:41 PM (Reply to #15)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:

@david: Yes it was a software problem, but it would never have shown it's ugly head if the PC's uart baudrate was closer to the expected theoretical value.

 

The 12MHz (or 48) Crystals are of course fairly accurate for the USB side, but not readily divisible for "standard" UART baud rates.

This means some fractional baudrate generator is implemented in the USB <--> Uart chips and the accuracy of those is dependent on the scheme used.

DDS chips use a good algorithm ( such as a 24 bit accumulator or more). For uarts 6 bits (Tiny817) is often deemed "accurate enough". But that's certainly not " 0% ".

Those Fractional algorithms also add jitter which gets noticable if the output frequency gets near the input frequency.

 

Datasheet of PL2303 has no info on this.

Datasheet of CH340 says: The baud rate error of serial transfer signal is less than 0.3%, and permission baud rate error of serial receive signal is not less than 0.2%.

 

@Rammon: Where does your " 0.16% " quote come from?

 

And who knows what other hardware manages to spit out a serial stream in this crazy world.

Just be carefull with the assumptions you make.

 

0.16% is the error of the "standard" baudrates  (9600,19200,38400,etc.) that can be achieved with 8MHz, 12MHz, 16MHz, 24MHz, 32MHz, 48MHz clocks. Even with non-fractional BRGs.

 

Lately there are some chips appeared that claim "crystalless usb". They just resyncronize every SOF. But they still need a 0.25% clock (probably to not miss the SOF). That looks quite close to the CH340 spec.

 

I'm not making assuptions. I just explained some things. When you have a 10bit frame, +-2% is enough, no matter what is at the other end. I'm not assuming that a PC is 0% or 0.16%, I'm assuming the PC is 2%, so I will also be 2%. I'm not using a 4% clock just because I assume the other end is 0%.

 

And the "rule" for 11bit frames is 1.5%, 12bit frames 1% (with some good margin). These are the numbers that should be respected by the partners. Usually a "host" (PC) is more accurate because it needs to support any combination. But if I know that I'm using a 10bit frame, I can use 2%.

 

About the baud rate generators (fractional or not) is another discussion. You should do some math anyway, to see if you can achieve the desired baudrate or not.

Here, the trend is to make it better, not worse, "hosts" trying to achieve as many baudrate values as possible, with the lowest error possible. Even the "devices" (our microcontrollers) are usually doing better in this respect (see the fractional BRGs).

Top