Ceramic Resonator for UART?

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

Can I use ceramic resonator (instead of crystal) for UART operation?

What I mean is can I connect my Atmega644P to 16MHz ceramic resonator (0.3% accuracy) and still can use the UART upto 38.4k? According to Atmega644P datasheet, the error rate for 38.4k at 16MHz is 0.2%, which is acceptable. But that is assumed that a crystal which is more accurate than the resonator is used. So, if I use resonator, can I still use the UART uptp 38.4k?

cs

I'm happy ytd, today, and tmr :)

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

+/-0.3% (resonator) + +/-0.2% (mcu) = +/- 0.5% (worse case)
http://www.maxim-ic.com/app-note...
"Making use of the allowable error budget is helped in systems where both ends of the link are being designed at the same time, partly because the tolerance of both ends will be known, and partly because tradeoffs and cost saving can be made. In general a standard, low cost, ceramic resonator with ±0.5% accuracy and a further ±0.5% drift over temperature and life can be used for the clock source at both ends of the link. This meets the 2% nasty scenario discussed earlier. If the system uses a master controller (typically a microcontroller or a PC) which uses a standard 100ppm crystal oscillator for the UART clock source, then the link error just about halves. Be careful with microcontrollers that synthesize baud frequencies for their internal UARTs. Depending on the choice of microcontroller clock, the baud rates may not be exact. If the error can be determined, it can be easily included in the link error budget."

/Martin.

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

0.5% <2% thus I can use?

Ceramic resonators much cheaper than a crystal. Also, lower components count.

Thanks a lot Martin.

cs

I'm happy ytd, today, and tmr :)

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

Quote:
0.5% <2% thus I can use?

Yes. I have often used ceramic resonators on applications that use UARTs, it should work fine.

Four legs good, two legs bad, three legs stable.

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

Also, if both ends of your serial communication line are AVRs running at the same clock speed, then you can ignore the bushwah about the error arising from not being able to hit one of the standard baudrates exactly with one of the small integer divisors in the baudrate generator, because nothing says that you have to operate a link that's fully under your control at a standard baudrate. If two AVRs with baudrate divisors of seven (a totally made up number just for argument's sake) wind up at 109237 baud, then they're both at the same exact baudrate, subject only to inaccuraces in their clock speeds. So 109237 baud isn't a "standard" rate in the 2400, 4800, 9600, 19200, ... sequence; BFD. The bytes will still fly back and forth real fast.