LPCXpresso IDEのトピックRe: main clock vs system clock confusion

main clock vs system clock confusion

lpcware — Thu, 16 Jun 2016 01:18:05 GMT

Content originally posted in LPCWare by borik2003 on Thu Nov 25 01:00:37 MST 2010
I have some missunderstanding for main clk and system clk.

for example UART:

Is it get its clock from "main clk" or from "system clk"

I found that it get its clock from "main clk" , but what clock the bit 12 in
[B][FONT=Arial][SIZE=1][COLOR=#005042][FONT=Arial][SIZE=1][COLOR=#005042][FONT=Arial][SIZE=1][COLOR=#005042]SYSAHBCLKCTRL register enable ? "main clk" or "system clk" ?

[/B][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT]

Re: main clock vs system clock confusion

lpcware — Thu, 16 Jun 2016 01:18:06 GMT

Content originally posted in LPCWare by Luis Digital on Thu Nov 25 07:30:04 MST 2010
Hello,

[COLOR=#000000]The "Main clock" is not an oscillator, but a clock source, you can select different oscillators.

[/COLOR]The main clock feeds the "System clock", and is used by the system (memory, peripherals, etc.).
[COLOR=#000000]
[/COLOR]The UART uses two clock sources:

Quote:
The UART block is gated by the AHBCLKCTRL register (see Table 3–19). The peripheral
UART clock, which is used by the UART baud rate generator, is controlled by the
UARTCLKDIV register (see Table 3–21).

The UART_PCLK can be disabled in the UARTCLKDIV register (see Section 3–4.16) and
the UART block can be disabled through the System AHB clock control register bit 12
(see Section 3–4.14) for power savings.
Remark: The UART pins must be configured in the corresponding IOCON registers
before the UART clocks are enabled.

We now understand a little better how it works. ;)

Re: main clock vs system clock confusion

lpcware — Thu, 16 Jun 2016 01:18:07 GMT

Content originally posted in LPCWare by borik2003 on Thu Nov 25 10:53:09 MST 2010
I am sorry , i am still not understand.

if i look on schematic

there are 2 clocks :

1) main_clk (not oscilator)
2)system_clk that derived from main_clk.

the boud rate generated from "main_clk/uartdiv" (that what i found when played with a code) and it can be seen also
on schematics.

What i can't understand - What for used "system_clk" enabled via AHBCLKCTRL register ?

Can be that "system_clk" used for UART register accsess and "main_clk" for UART baud rate only ?

In general the NXP technical staff whrite very bad user guides in my openion . The datasheet and user guide of lpc1114 seems writen for themselfs and not for one that wonts to learn how this chip
works exactly for the first time.

Re: main clock vs system clock confusion

lpcware — Thu, 16 Jun 2016 01:18:07 GMT

Content originally posted in LPCWare by gbm on Thu Nov 25 12:22:38 MST 2010
No, NXP has simply "not very good" manuals. In "very bad MCU manual" competition first place belong to Nuvoton and second - to Renesas.

Re: main clock vs system clock confusion

lpcware — Thu, 16 Jun 2016 01:18:08 GMT

Content originally posted in LPCWare by Luis Digital on Thu Nov 25 15:00:24 MST 2010
"System clock" is the heart of the UART, the other clock is to generate the baud rate.

The manuals are of low quality, but these microcontrollers are difficult by definition. In other microcontrollers simply modify a registry to be put to work a peripheral, but in the ARM we have to modify several, usually: power, clock (sometimes several), and of course activate the peripheral.

And I was forgetting that there is usually a register to divide the clock frequency.

Too many things that can easily forget a human, and very much a beginner.

ARM: complicated unnecessarily.

Re: main clock vs system clock confusion

lpcware — Thu, 16 Jun 2016 01:18:08 GMT

Content originally posted in LPCWare by TheFallGuy on Fri Nov 26 07:00:34 MST 2010

Quote: Luis Digital

ARM: complicated unnecessarily.

This is nothing to do with ARM. It is the peripheral(s) chosen by NXP to put into their devices. They are NXP's and AFAIK, have nothing to do with ARM. ARM supply the processor and, on Cortex-Mx, the NVIC and SYSCTRL peripherals. Everything else is up the NXP (or any other MCU vendor).