Synchronous UART with mixed clocks

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
killertoffy
killertoffy's picture
Level: Rookie
Joined: Wed. Jul 26, 2006
Posts: 44 View posts
#1
Posted by killertoffy: Thu. Oct 16, 2008 - 08:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using an ATMega324 and want to run it at 20MHz, while maintaining fast and reliable serial comm at 115200 bauds.

I've seen megas can use an external clock XCKn for the UART when used in synchronous mode.

So my setup is as follow :

-Mega324 XTAL1/2 to a 20MHz crystal (on STK500)
-External crystal oscillator at 3.6864MHz with output pin connected to PD4(XCK1)
-PD2/3(RXD1/TXD1) connected to STK500 spare 232.

I first tried the uart connection with a 11.0592Mhz crystal for the avr in asynchronous mode, and comm was ok.

But I can't get the mixed clock version working.
It definitely sends something (garbage) and if I disconnect the XCK1 it stops, so it seems to be using the external clock.

Using the following C code : (with Peter Fleury's lib)

uart1_init( UART_BAUD_SELECT(115200,3686400UL)); 
UCSR1C|=_BV(UMSEL10); // synchronous mode
sei();
for(;;) uart1_puts_P("\n#hello world\n");

I read about the URSELn trick, but the 324 seems to have separate registers.

Anybody succeeded with such a config ?

Thanks

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 24796 View posts
Location: Melbourne,Australia
Posted by Kartman: Thu. Oct 16, 2008 - 09:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking at the datasheet, it won't work! It is trying to send/receive data at the XCLK frequency! Best to try a 18.432mhz crystal or tolerate the -1.4%error at 20mhz.

Top
UNiXWHoRe
UNiXWHoRe's picture
Level: Posting Freak
Joined: Fri. Nov 3, 2006
Posts: 1115 View posts
Posted by UNiXWHoRe: Thu. Oct 16, 2008 - 01:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It will work if you divide the 3.6864MHz clock before feeding it to XCLK. You could do the dividing with 4 d-flipflops in series (2x 74hc74)...

Top
killertoffy
killertoffy's picture
Level: Rookie
Joined: Wed. Jul 26, 2006
Posts: 44 View posts
Posted by killertoffy: Thu. Oct 16, 2008 - 04:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whoooaaaa read the thing 20 times and totally missed that one.
:oops:

Good idea with the flip flops. I'll give a try.

Thanks for your help.

Top
UNiXWHoRe
UNiXWHoRe's picture
Level: Posting Freak
Joined: Fri. Nov 3, 2006
Posts: 1115 View posts
Posted by UNiXWHoRe: Thu. Oct 16, 2008 - 05:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Be aware however that any incoming data will have to be synced with the clock you are using for TX. Synchronous means just that, both sides in sync to the same communications clock.

Top
killertoffy
killertoffy's picture
Level: Rookie
Joined: Wed. Jul 26, 2006
Posts: 44 View posts
Posted by killertoffy: Fri. Oct 17, 2008 - 02:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've used a 74hc590 (8 bits counter) to prescale the clock.
Works like a charm !
Now I can even select different baudrates with a jumper that selects the corresponding counter output.

Indeed, I have glitches when receiving.
I believe there's no easy way to re-sync the input...

It is not a big issue as there's only a few bytes to receive. I can deal with that using error detection and re-transmition.

The best solution would probably to use a real external uart, or clock the avr with a magic crystal.

Top
UNiXWHoRe
UNiXWHoRe's picture
Level: Posting Freak
Joined: Fri. Nov 3, 2006
Posts: 1115 View posts
Posted by UNiXWHoRe: Fri. Oct 17, 2008 - 02:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your "glitches" are probably because the other device is sending asynchronously. That means it has no real regard towards any communications clock, it just sends out bits the right width for the selected baud rate, and expects the receiving side to receive asynchronously. Instead, since you are using synchronous UART mode, your receiving UART is sampling all bits on the rising (or falling, depending on CKPOL) edge of the comms clock, which may or may not fall within acceptable phase margin with the sent data. The synchronous to asynchronous UART will work just peachy for one way comms, but asynchronous to synchronous is another story.

Top