Clock sources/options for ATTINY1616

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

Hi

 

I'm working on moving an existing design (based on ATMEGA168) to the new ATTINY1616.

The reason being size (20pin VQFN or even lower pin count), and built in DAC which saves me both space and components on the currently (really constrained) layout. As for needs, I only need 2 PWM outputs, 2 ADC inputs, and UART so this is perfectly fine.

It's also much cheaper than the 168PB (the latest, that I'm using now).

 

My issue is with the UART: for things to work properly, I need a good clock source. I am currently running at 16Mhz and communicating at 1Mbps.

With the mega168 I use 16Mhz a ceramic resonator on the XTAL pins that gives me 0.5% accuracy, which is fine for UART and for my application.

 

For some reason, the TINY1616 has fewer options for clock sources:

a) Internal 16Mhz oscillator which, in this processor and according to the datasheet, can get me within 2% error using factory calibration. (theoretical UART max error should be <=3% total between the two devices, so this is cutting it close).

  Furthermore, the datasheet also says on a footnote they haven't exhaustively characterized this, so I'm left wondering....

b) From what I can see, pins TOSC1/TOSC2 can only have a resonator up to 32Khz, so the option to use a 16Mhz resonator is gone.

c) Another option is the EXTCLK.

 

This means that I either blindly trust the internal 16Mhz Oscillator accuracy or need to go with a significantly more expensive Crystal, since a 16Mhz resonator doesn't seem to be supported (or not without additional circuitry)

I also can't find any reference to a PLL that could use the 32Khz resonator to generate a more stable/reliable 16Mhz clock.

 

My questions are:

a) Am I reading the datasheet right? Are these all the clock options? 

b) To achieve stable 16Mhz via the EXTCLK pin, is there any alternative to a Crystal that comes close to the price of a resonator?

c) Do you think using the internal 16Mhz clock, with the factory callibrations, would be a smart move, considering I am using a UART?

 

Thank you very much for your input,

 

Best,

Pedro

 

 

Last Edited: Sat. Jun 27, 2020 - 08:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This part of the datasheet will be useful to you.

 

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

The USART of the tiny1616 is more advanced and has a fractional rate generator. This means the baud rate can be fine tuned to a precise value, as long as you have an external reference.

 

pramilo wrote:
b) From what I can see, pins TOSC1/TOSC2 can only have a resonator up to 32Khz, so the option to use a 16Mhz resonator is gone.

Yes, basically, the manufacturer expects you to use this 32kHz reference to calibrate timing critical parts of the application, such as the USART.

 

edit: yes, alternatively you can trust the values stored in the MCU ROM for calibration as mentioned in the previous post.

Last Edited: Sat. Jun 27, 2020 - 09:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use your 16MHz rezonator with a 74HC1GU04GW and 1M feedback resistor.

The part is 0.09 USD in 100 qts and very tiny.

Compared with your PB solution, for 0.10 USD you gain stronger ESD/EMC immunity. PB oscillator is particularly weak.

 

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

kabasan wrote:

This part of the datasheet will be useful to you.

 

IMAGE

 

 

Thank you for the pointer. I had read that but some questions persisted:

However it's unclear how exactly that improves the clock accuracy:

  • The image is from section 10 of the DS (Clock Controller). No mention is made to quantify the accuracy when using this method, so I'm still left wondering
  • If you scroll to section 36.9, "Characteristics" of the Oscillators, you get two separate values for the Internal Clock accuracy: 4% and 2%. If you look in the Datasheet of the Automotive version it won't even mention the 2%, just the 4%. 
  • I am assuming the 2% (best case) is already using the baud formula that you posted. It's really unclear why one shows 2% and the other 4% (even worse, why the Automotive shows 4%)

 

 

The UART section of the DS, shows that, for this particular chip, transmitting at 8data bits, the recommended maximum error is 2% (so lower than the "usual" UART spec which is 3%) and a match to our best Clock accuracy (2%).
Therefore, there's basically no margin for error if we consider for 2% deviation in the internal clock combined with a maximum tolerable 2% deviation in UART clocking between the two devices.

 

 

el cabasan wrote:

Yes, basically, the manufacturer expects you to use this 32kHz reference to calibrate timing critical parts of the application, such as the USART.

 

Can you point to where that's explained in the Datasheet?

I've looked at the Datasheet section of the UART and the clocks and I can't find any reference to the chip using the 32Khz source to adjust its working frequency for peripheral operation (including the UART).

 

Also, is there any Register setting to enable this? (appart from the obvious setting the fuses to let it know the oscilator is connected)

 

If this would be the case (with the 32Khz clock), then it'd be the ideal solution.

 

Finally, a nod to @Hangaround for the suggestion. Looked into it, and it's a great solution, if nothing works out yes

 

I'll be looking forward for your replies,

 

Thank you very much

Pedro

Last Edited: Mon. Jun 29, 2020 - 12:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sorry.
If the peripheral clock is 16MHz and BAUD is 1Mbps, the fractional baud rate generator will not work.
Therefore, the maximum error is 3%.

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

pramilo wrote:

Can you point to where that's explained in the Datasheet?

I've looked at the Datasheet section of the UART and the clocks and I can't find any reference to the chip using the 32Khz source to adjust its working frequency for peripheral operation (including the UART).

 

It's not automatic, you need to do it in software. For example, you use the external 32kHz frequency, then using a timer that runs on the main clock, let's say 16MHz, you measure how many ticks fit into a 32kHz period.

If the internal 16MHz was perfect, it would be 500 ticks, but let's say you measured 505, now you know the internal osc is running 1% too fast, so you can reduce the USART baud rate by 1% and it will be corrected.

 

Timer type B has a frequency capture mode that would be adequate for this.

 

kabasan wrote:
If the peripheral clock is 16MHz and BAUD is 1Mbps, the fractional baud rate generator will not work.

Well, I really haven't tested this in practice, but from my understanding of the fractional rate mechanism, it should work fine up to 200kbaud or something like that.

Last Edited: Mon. Jun 29, 2020 - 12:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much for all your replies.

 

I think this thread contains great information for perople migrating from traditional ATMEGAs.

As I understand it applies to tinyAVR-0 series, tinyAVR-1 series and megaAVR-0 series.

 

To summarize, for someone reading this for the first time:

 

- The option to use a Ceramic Resonator as the main clock for these new models is gone

 

- You can now use the new, improved internal 16/20Mhz internally generated clocks, which have a precision of 4% using factory callibrated settings, and may be improved for some peripherals down to 2%.

In the case of UART, there's a fractional divider that can be configured with additional factory data to improve UART accuracy (see post above). However this would seem suitable for fairly low baud (up to a couple hudred Kbps) only

 

- For applications where clock accuracy is critical (such as a higher speed UART) or counting Real time, you can still supply your own External clock signal to the chip, usng a Crystal Oscilator.

(not to be confused with a Ceramic Resonator; circuitry to support those seems to be gone from the chip)

 

You have 2 options for external clock: either the Crystal (expensive but highly accurate, to 0.005% or better) or use a couple additional (external) components to generate a clock signal from a Ceramic Resonator.

The second option is much cheap(er) and should give you 0.5%(+-0.1) accuracy. This is well within UART requirements and better than the Internal Oscilator (which tends to be at 4%)

 

To use the Ceramic Resonator you need to add an Unbuffered Inverter (such as the  74HC1GU04GW ) and a resistor. It is important to use precision resistors (0.1% or better) or otherwise, the generated frequency loses precision (which defeats the purpose of using the external clock).

Also make sure to check the Resonator capacitance (and actual resistor value) against the datasheet of your Inverter.  Google and the datasheet of the Inverter should help you put the circuit together.

 

Thank you once again

Pedro

Last Edited: Mon. Jun 29, 2020 - 01:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pramilo,

You are confusing some terms.

Crystals and ceramic rezonators are pasive components. They need an inverter (internal to the MCU, or external like the GU04 gate) to form an oscillator.

Internal to the MCU: doesn't exist in these new chips. Period.

If you were reffering to a 32kHz crystal, that's a different animal, you cannot use this as a direct clock for these MCUs.

The 1M "feedback" resistor has nothing to do with precision. Usually they work in the 200K to 2.2M (or more) range. You probably confuse it with a resistor in an RC oscillator.

1M is the value recommended by the ceramic rezonators manufacturers.

I'm using a lot the scheme with an 74HC1GU04 gate, the 1M feedback resistor and an 16MHz CSTNE16M000... ceramic rezonator. For chips like atmega88PB, 328PB, some STM8S variants and even an STM32. Note that these chips SUPPORT external crystals/ceramic rezonators directly (because they HAVE the internal inverter gate for the oscillator) but they are very week regarding noise immunity (ESD and EFT) when they are clocked this way. When clocked with the external oscillator, their noise immunity improve a lot.

And I need this noise immunity badly.

 

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

There is also the autobaud feature that can be put to use if wanted but is 1x only. At 16MHz, you would have to choose something lower than 1M as you could end up <64 (which autobaud will not allow), so something like 921600 would be used if needing standard values. A 20MHz clock would allow enough room to do autobaud at 1M. The problem with autobaud is you need some kind of 'understanding' between the 2 usarts about when the autobaud takes place.

 

The following is values from autobaud with a mega4809 connected to a Omega2 board. You can see the 1M works ok in this case, but if it errs the other way then it will not work (<64) so 921600 would be the highest usable baud in this case (unless the 20MHz clock is used instead). The code I created for the mega4809 autobaud sets its own break, then expects a 'U' to sync, and another 'U' to verify so the other end does not have to deal with break and can just send a pair of 'U's.

 

baud, resulting baud register val from autobaud
230400 = 281
460800 = 142
921600 = 71
1000000 = 66

 

At 1M, the above resulting baud value indicates the usart baud rate generator is running ~3% faster than the Omega2's. When setting the baud register to 64 instead of using autobaud (now ~3% error compared to Omega2) the avr also communicates with no errors (64 is a valid value, although you probably cannot apply a sigrow correction as it may take you <64).  I went up to 69 without errors, which is about ~4.5% error, 70 started to produce errors.

 

The operational range for 8bits no parity is listed as about +/-4.5%, so if the other end is pretty accurate, then the avr can have most of the error for itself.

 

I also had a 12MHz ceramic resonator laying around I just tried (3pin through-hole). On the mega4809 I hooked it up to PA0 (EXT CLK) and PA2 (EVOUTA), setup PA0 as input and as a EVSYS CH0 generator, with PA2 EVOUTA (output, inverted) as a CH0 user. So one resonator, one 1Meg resistor, and with the cpu clock set to EXT and no prescale, I had pretty close to 12MHz as the resulting autobaud numbers seem to indicate (not actually measured, though)-

 

baud, resulting baud register val from autobaud, (computed value)
 9600  = 4923 (5000)
 115200 = 417 (416)
 230400 = 207 (208)
 460800 = 105 (104)

 

So maybe if you want a little more accuracy (or more importantly, a somewhat stable freq at all temps), all you need is a ceramic resonator, a 1Meg Ohm resistor, and one extra pin besides EXT CLK. I just did this as a quick test and have not looked at what is going on with the clock signal, but the avr seems happy so far.

 

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

curtvm wrote:
I also had a 12MHz ceramic resonator laying around I just tried (3pin through-hole). On the mega4809 I hooked it up to PA0 (EXT CLK) and PA2 (EVOUTA), setup PA0 as input and as a EVSYS CH0 generator, with PA2 EVOUTA (output, inverted) as a CH0 user. So one resonator, one 1Meg resistor, and with the cpu clock set to EXT and no prescale, I had pretty close to 12MHz as the resulting autobaud numbers seem to indicate (not actually measured, though)-

 

Yeah, I did something similar a couple years ago (but with a crystal)

 https://www.avrfreaks.net/forum/weekend-project-using-event-system-tiny1614-create-full-swing-crystal-oscillator?skey=weekend%20project

 

The problem was that it generated a lot of noise, in terms of frequency it was ok.

Last Edited: Mon. Jun 29, 2020 - 01:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

low baud (up to a couple hudred Kbps) 

The sounds very high baud, low baud would be 1200 or 9600 baud, wouldn't it? Most tables top out at 115K baud.

 

Crystals are extremely cheap these days, maybe 10 cents in quantity & you easily get 0.01 percent (0.0001) freq accuracy, even with the worst crystals.  Unfortunately Atmel, mysteriously did away with using such crystal, so a crystal oscillator is a secondary, though more pricey choice, noting by extreme coincidence Microchip happens to make/sell them.  Of course an external oscillator is just a digital sqaure clock signal.

 

Autobaud is perhaps a way to help alleviate timebase troubles, but what if you are only sending, or very rarely rcving?  Then you'd have no idea there is a freq error in order to make a correction.   Can two autobaud units talk to each other, or do they "chase" each other?  Never tried that! 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Mon. Jun 29, 2020 - 04:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much for all your feedback,

 

I'll be doing a closed loop control with data coming in and out of the AVR continuously (at 1Mbps as mentioned).

 

I've come across an Application Note that kind of combines the suggestion from Raving Lunatic (32Khz) but uses it differently. See  http://ww1.microchip.com/downloads/en/Appnotes/doc8002.pdf (Application note  AVR055)

It describes using the external 32Khz oscillator to adjust the RC oscilator calibration byte.

 

I'll likely go with the Inverter + resistor + Ceramic resonator anyway, becaus eit's the path of "least resistance" and closer to the actual design, but further down, I might consider looking into that.

 

Just wanted to leave that Appnote as a contribution to this great, rich discussion.

 

Best Regards

Last Edited: Wed. Jul 1, 2020 - 05:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the peripheral clock is 16MHz and BAUD is 1Mbps, the fractional baud rate generator will not work.

Doesn't it?  With CLK2X set (8 samples/bit instead of 16, equivalent to U2X), a BRG register value of 128 will yield 1Mbps, while 127 will be 1/64th lower and 129 will be 1/64 higher.   1/64 is 1.56%, so that's not a great step value, but it's still "working", right?

 

(also, you never needed a fractional BRG to get exactly 1Mbps from a 16MHz clock...)

 

(if you're trying to fine-tune the frequency, you're probably better off messing with the oscillator calibration.)

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

Thank you for the insight regarding the 2X and fractional generator.

From my understanding of the Datasheet using the 2X option will make the UART less tolerant to timing errors from the other source but I'll need to look into that.

Based on your feedback, I might be going with something like:

At manufacturing, recheck/tweak oscillator calibration against an external clock. There's some AppNotes on that.

At runtime, I will probably add a synchronization function inspired in the AppNote about tuning the oscillator using the UART.
In this case then, I would instead tune the fractional Baud instead of the oscilator as I hope experimentation will.show that the RC oscilator won't drift much after initial calibration.