Content originally posted in LPCWare by Rob65 on Wed Jan 11 13:31:09 MST 2012
Quote: vasanth
But what is the time taken for a changeover? Because we know there is PLL locking. If the changeover takes significant time between conversions, what is the optimum way to use this feature?
I have not really thought about this yet.
The LPC17xx user manual tells me this about PLL locking:
Quote:
The PLOCK0 bit in the PLL0STAT register reflects the lock status of PLL0. When PLL0 is
enabled, or parameters are changed, PLL0 requires some time to establish lock under the
new conditions. PLOCK0 can be monitored to determine when PLL0 may be connected
for use. The value of PLOCK0 may not be stable when the PLL reference frequency
(FREF, the frequency of REFCLK, which is equal to the PLL input frequency divided by the
pre-divider value) is less than 100 kHz or greater than 20 MHz. In these cases, the PLL
may be assumed to be stable after a start-up time has passed. This time is 500 μs when
FREF is greater than 400 kHz and 200 / FREF seconds when FREF is less than 400 kHz
Here FREF is the reference frequency, PLL clock in / N. in my driver FREF is always greater than 400 kHz so I guess that means locking the PLL takes (less than) 500 μs.
That's a real guess though ... I have just scanned across some pages to see what I could find regarding the PLL lock timing.
The quickest way to switch clocks is to just reprogram the CPU clock divider (the one after the PLL). That gives the faster response when needing a higher frequency.
Still - both ways of increasing/reducing the clock mean that you have to reprogram all timing dependent things (e.g. uart baudrate, SPI/I2C clock, Systick) and that also takes some extra time.
Finding an optimum way to use this feature is a good question.
I don't know (yet) :eek:
Most users will just determine different use cases in the application and adjust the clock to fit the needs for these cases.
Just as an example:
[LIST]
[*]* user interface handling only:
Slow clock, just fast enough to keep the user interface respond quick enough
[*]* Logging data to SD card:
Keep the clock high enough to prevent filling up the buffers (only possible when the speed of the data to log is known).
[*]* Attaching to USB to read the SD card and program parameters:
fast is good. The device is now powered over USB so no need to save batteries.
[/LIST]
Rob
