UCLK

Cesar Eduardo Barros cesarb at cesarb.net
Thu Aug 28 02:42:45 CEST 2008


Andy Green escreveu:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> | In a message from Ben Dooks on linux-arm-kernel about cpufreq, he said:
> |
> |  > > - My patches have code to use hardware flow control to "pause" the
> |  > > serial ports during frequency transitions, so as to not confuse the
> |  > > GTA01 GSM modem (or Openmoko's gsmd).
> |  >
> |  > That is useful for designs that forgot to provide a stable UCLK to
> |  > provide UART baud clocks... all of the ones that I've had a direct
> |  > hand in working on feed back or feed in an external known (and stable)
> |  > clock.
> |
> | It might be worth considering this on future designs (looking at the
> | schematics, GTA01 uses the pin for something else, while GTA02 doesn't
> | connect the pin at all).
> 
> It's a good point, it would help the UART continuity during clock
> change.  But it means adding an oscillator somewhere?  There's a PLL
> from the Wolfson we could maybe use.

A possible trick would be to route the output of the USB PLL to a pin, 
and have a trace linking that pin to the UART external clock. The USB 
PLL isn't affected when the main PLL changes (or at least shouldn't be).

For the GTA02, for instance, that would mean a trace between 
UEXTCLK/GPH8 and CLKOUT1/GPH10 (which would also allow several other 
options besided the USB PLL). Both pins are free on the GTA02, but I 
don't know if routing that trace would be easy (especially considering 
the trace would be carrying a 48MHz signal).

For a USB clock of 48MHz, that would give us a UBRDIV of 25 for 115200, 
which feeding the formula in the reverse results in a baud rate of 
115385, an error of 0.16% (unless I made a mistake on the calculations). 
This is less than the about 1.87% where things start having problems.

Of course, even with all that it would still be a good idea to "pause" 
the flow control during the PLL lock time to avoid a buffer overrun, but 
the AFC might be able to do it automatically for us. The problem avoided 
by using a stable clock is mainly the frequency changing (or the clock 
stopping) in the middle of a byte.

-- 
Cesar Eduardo Barros
cesarb at cesarb.net
cesar.barros at gmail.com



More information about the hardware mailing list