AVR-Chat

Hi, I want to build a simple ATmega16 device with no xtals if possible
and I am confused after reading the ATMega16 data sheet.

1. Do the timer intervals rely on the frequency of the main xtal or do
they somehow automatically change if you change the main xtal.
2. If you have no xtal does this affect the timers much?
3. Will the Timers work if you have no Xtal connected to the TOSCI pins?
4. Does the Xtal frequency affect the serial input baud rate?

Thanks Ted

On Sat, 14 Jan 2006 12:46:16 -0000 you wrote:

>Hi, I want to build a simple ATmega16 device with no xtals if possible
>and I am confused after reading the ATMega16 data sheet.
>
>1. Do the timer intervals rely on the frequency of the main xtal or do
>they somehow automatically change if you change the main xtal.
>2. If you have no xtal does this affect the timers much?
>3. Will the Timers work if you have no Xtal connected to the TOSCI pins?
>4. Does the Xtal frequency affect the serial input baud rate?

The clock source depends on the settings of the CKSEL fuses. If you change the xtal
frequency or clock mode then timer operation is affected proportionately.

If you have no xtal and no external clock source then the fuses need to be set for RC
operation. The timers work but are much less accurate and too imprecise for serial port
use.

The xtal frequency determines the baud rate in conjunction with the UBBR value as covered
in the section on the USART on P. 145.

The TOSCI xtal is optional and is for an asynchronous use of timer2 - that is covered in
the section on timer2 in the datasheet P. 116.

--
Ralph Hilton
http://www.ralphhilton.org
C-Meter: http://www.cmeter.org
FZAOINT http://www.fzaoint.net

Ted Smith wrote:

>Hi, I want to build a simple ATmega16 device with no xtals if possible
>and I am confused after reading the ATMega16 data sheet.
>
>1. Do the timer intervals rely on the frequency of the main xtal or do
>they somehow automatically change if you change the main xtal.
>2. If you have no xtal does this affect the timers much?
>3. Will the Timers work if you have no Xtal connected to the TOSCI pins?
>4. Does the Xtal frequency affect the serial input baud rate?
>  
>
1)  of the main (or system) clock, yes.  Though on almost all AVRs, and 
IIRC, the ATMEGA16 is onme of them,  you can disable the external clock 
connections )e.g., no crystal or resonastor) and run on the internal 
"calibrated RC clock." typically at 8 Mhz.

2)  Yes.  Because the RC oscillator on board has a much hiugher 
temperature coefficient than a crystal or a ceramic resonator would.  So 
as temperature changes, so will your sytem clock freqyency.

3)  Yes.  So long as you select the correct mode for thre system clock, 
utilizing the calibrated intenral RC oscillastor, as described above.

4)  Yes.  The baud rate generator is driven by the system clock, and you 
must select the correct settings for the baud rate generator divider, to 
generate the correct baud rate clock for the desired serial 
vcommunicaitons speed. 

  All of this is very clearly documented in the ATMEGA16 data sheet.

tom

> The clock source depends on the settings of the CKSEL fuses. If you 
change the xtal
> frequency or clock mode then timer operation is affected 
proportionately.

While using any external resonator or crystal, make sure that the CKOPT 
bit is checked. This selects the "rail to rail" oscillator mode (AKA 
NORMAL!)  Otherwise, you are using a "vittoz" low power oscillator, and 
this can cause some VERY wierd problems, or work just fine with 1000 
units and fail miserably next week.

On 14 Jan 2006 at 17:50, Dave VanHorn wrote:

> While using any external resonator or crystal, make sure that the CKOPT 
> bit is checked. This selects the "rail to rail" oscillator mode (AKA 
> NORMAL!)  Otherwise, you are using a "vittoz" low power oscillator, and 
> this can cause some VERY wierd problems, or work just fine with 1000 
> units and fail miserably next week.
> 

	The ATtiny2313 doesn't have this rail-to-rail option.

> 
> 	The ATtiny2313 doesn't have this rail-to-rail option.

It dosen't seem to have the option, but it is probably set up for rail-
to-rail by default, at least I would hope so.

I have seen some VERY nasty problems caused by this. 
Non-deterministic execution...
Some parts of the chip missing clock cycles. 

Very nasty.

On 16 Jan 2006 at 6:37, Dave VanHorn wrote:

> > 	The ATtiny2313 doesn't have this rail-to-rail option.
> 
> It dosen't seem to have the option, but it is probably set up for rail-
> to-rail by default, at least I would hope so.

	Yes, me too. But the scope tells the contrary...

 
> I have seen some VERY nasty problems caused by this. 
> Non-deterministic execution...
> Some parts of the chip missing clock cycles. 
> 
> Very nasty.
> 

	On one application I'm using the Tiny2313 with a 16MHz crystal and the 
internal clock prescaler set to divide by four.  It seems more stable this 
way.

	Mark Jordan

> 	On one application I'm using the Tiny2313 with a 16MHz 
crystal and the 
> internal clock prescaler set to divide by four.  It seems more 
stable this 
> way.

Eww.. I've never used that particular chip, but I'd be nervous. 
IF you get the right crystal, and I've seen NO guidance from Atmel on 
selecting it, then you'll be ok. The key is to get the output level 
higher than the unspoken threshold value. 

In our case, with the M128, most systems worked fine, a few had 
really tough to explain problems, wierd serial port glitches, but 
nothing consistent.. Then one day, all of a sudden, bang. Pretty much 
nothing works. Different date code on the M128 parts is about all we 
could point at.  

Once we found out about the CKOPT bit (which got set the opposite of 
what I had spec'd), we flipped the bit back and life was good again.

A bit nasty recalling systems from customers though, since you can't 
touch the fuse bits from the program.

Dave VanHorn wrote:

>>	The ATtiny2313 doesn't have this rail-to-rail option
>>

>>It dosen't seem to have the option, but it is probably set p for rail-
>>to-rail by default, at least I would hope so.
>>I have seen some VERY nasty problems caused by this. 
>>Non-deterministic execution...
>>Some parts of the chip missing clock cycles. 
>>Very nasty.
>>    
>>
Dave,

   Were you attempting to use this non rail-to-rail clock for external 
devices?

   As I undersand that data sheets on this issue, the low power (non 
rail-to-rail) clock option is only recommended when you are NOT sharing 
the clock wqith any other device.

tom

>    Were you attempting to use this non rail-to-rail clock for 
external 
> devices?

Absolutely not.



>    As I undersand that data sheets on this issue, the low power 
(non 
> rail-to-rail) clock option is only recommended when you are NOT 
sharing 
> the clock wqith any other device.


I've confirmed with Atmel that it's a Vittoz type oscillator.
Pull a google on it.  Nice way to save power, but your crystal 
selection is much more critical. Notice that Atmel gives you no 
guidance on what the amplitude should be, or really even that there's 
much 'special' about this mode at all?

This issue forced us into a total recall of a bunch of systems. 
The problems were glitchy, hard to pin down, and blamed on software 
and hardware, up until a new date code of AVR chips arrived, and at 
that point, some fairly large number of them wouldn't start, using 
the same crystal and caps as we had before.

Dave VanHorn wrote:
>>Were you attempting to use this non rail-to-rail clock for 
>>external devices?
> 
> Absolutely not.
> 
>>As I undersand that data sheets on this issue, the low power 
>>(non rail-to-rail) clock option is only recommended when you are NOT 
>>sharing the clock wqith any other device.
> 
> I've confirmed with Atmel that it's a Vittoz type oscillator.
> Pull a google on it.  Nice way to save power, but your crystal 
> selection is much more critical. Notice that Atmel gives you no 
> guidance on what the amplitude should be, or really even that there's 
> much 'special' about this mode at all?
> 
> This issue forced us into a total recall of a bunch of systems. 
> The problems were glitchy, hard to pin down, and blamed on software 
> and hardware, up until a new date code of AVR chips arrived, and at 
> that point, some fairly large number of them wouldn't start, using 
> the same crystal and caps as we had before.

There's no such thing as a Vittoz oscillator. All Vittoz did was
derive some conditions for a standard oscillator that has always
existed and that i've analysed and figured out eons ago. What he
hasn't done is derive the optimum conditions for large-signal
operation;)

Dave VanHorn wrote:

>>   Were you attempting to use this non rail-to-rail clock for external devices?
>>    
>>
>Absolutely not.
>
>  
>
>>   As I undersand that data sheets on this issue, the low power(non rail-to-rail) clock option is only recommended when you are NOT sharing the clock with any other device.
>>    
>>
>I've confirmed with Atmel that it's a Vittoz type oscillator.
>Pull a google on it.  Nice way to save power, but your crystal 
>selection is much more critical. Notice that Atmel gives you no 
>guidance on what the amplitude should be, or really even that there's 
>much 'special' about this mode at all?
>
>This issue forced us into a total recall of a bunch of systems. 
>The problems were glitchy, hard to pin down, and blamed on software 
>and hardware, up until a new date code of AVR chips arrived, and at 
>that point, some fairly large number of them wouldn't start, using 
>the same crystal and caps as we had before.
>  
>
  Ahhh.  OK, then.   Well, I suppose even Atmel makes mistakes 
sometimes, eh?  *sigh*

Tom