Difficult to customise the initialization of clocks and peripherals #748

New issue

Closed

opened 2022-03-05 16:45:37 -06:00 by MichaelBell · 7 comments

MichaelBell commented

2022-03-05 16:45:37 -06:00

(Migrated from github.com)

The default runtime_init calls clocks_init, which sets up the external crystal and PLLs, and configures all the clocks, and then takes all peripherals out of reset, blocking until they come up.

This is a sensible default for standard use cases, but for low power use cases you might not want to bring up, or might not even have, an external crystal. This configuration is discussed in a reasonable amount of detail in the RP2040 datasheet. Alternatively you might want to bring up the crystal but not the PLLs, or only configure the clocks and systems that you are actually going to use.

It would be good to have a fully supported way of bringing the system up just off the ring oscillator, and only configuring a minimal set of clocks - REF, SYS and maybe PERI. The user could then bring up any other clocks and peripherals they need. This could be controlled by a simple define.

Alternatively (or in addition), it might be nice to allow the user to specify their own custom clocks_init function, and have that function return a mask of peripherals to take out of reset.

Note that it is possible to workaround this by setting SKIP_PICO_RUNTIME and/or SKIP_HARDWARE_CLOCKS in cmake, and then making a modified copy of these files in your own project - that's obviously not a great solution as you probably only want to customize a small amount of the functionality, and your copy would miss any later fixes applied to the rest of the code that you had to copy.

The default `runtime_init` calls `clocks_init`, which sets up the external crystal and PLLs, and configures all the clocks, and then takes all peripherals out of reset, blocking until they come up. This is a sensible default for standard use cases, but for low power use cases you might not want to bring up, or might not even have, an external crystal. This configuration is discussed in a reasonable amount of detail in the RP2040 datasheet. Alternatively you might want to bring up the crystal but not the PLLs, or only configure the clocks and systems that you are actually going to use. It would be good to have a fully supported way of bringing the system up just off the ring oscillator, and only configuring a minimal set of clocks - REF, SYS and maybe PERI. The user could then bring up any other clocks and peripherals they need. This could be controlled by a simple define. Alternatively (or in addition), it might be nice to allow the user to specify their own custom `clocks_init` function, and have that function return a mask of peripherals to take out of reset. Note that it is possible to workaround this by setting `SKIP_PICO_RUNTIME` and/or `SKIP_HARDWARE_CLOCKS` in cmake, and then making a modified copy of these files in your own project - that's obviously not a great solution as you probably only want to customize a small amount of the functionality, and your copy would miss any later fixes applied to the rest of the code that you had to copy.

👍 3

lurch commented

2022-03-06 10:17:45 -06:00

(Migrated from github.com)

Sounds like this touches (slightly) on #712 too?

arg08 commented

2022-09-13 13:47:57 -05:00

(Migrated from github.com)

A simple PICO_XOSC_HZ or somesuch, preferably supporting the full range (50MHz) that the XOSC can accept from an external oscillator rather than just permitted crystals.

In addition to the full-blown customisation suggested above, may I also suggest a simple mechanism for the board file to specify a different crystal frequency? At the moment it's all totally hard-wired in clocks_init(). A simple PICO_XOSC_HZ or somesuch, preferably supporting the full range (50MHz) that the XOSC can accept from an external oscillator rather than just permitted crystals.

kilograham commented

2022-09-13 14:07:24 -05:00

(Migrated from github.com)

In addition to the full-blown customisation suggested above, may I also suggest a simple mechanism for the board file to specify a different crystal frequency? At the moment it's all totally hard-wired in clocks_init().

A simple PICO_XOSC_HZ or somesuch, preferably supporting the full range (50MHz) that the XOSC can accept from an external oscillator rather than just permitted crystals.

Yup; that seems like a reasonable request - fancy submitting a separate PR?

> In addition to the full-blown customisation suggested above, may I also suggest a simple mechanism for the board file to specify a different crystal frequency? At the moment it's all totally hard-wired in clocks_init(). > > A simple PICO_XOSC_HZ or somesuch, preferably supporting the full range (50MHz) that the XOSC can accept from an external oscillator rather than just permitted crystals. Yup; that seems like a reasonable request - fancy submitting a separate PR?

MichaelBell commented

2022-09-13 14:10:59 -05:00

(Migrated from github.com)

Can you not already set that by defining XOSC_MHZ? It appears to accept a range 1-50.

Can you not already set that by defining `XOSC_MHZ`? It appears to accept a range 1-50.

arg08 commented

2022-09-13 14:31:34 -05:00

(Migrated from github.com)

Can you not already set that by defining XOSC_MHZ? It appears to accept a range 1-50.

Unfortunately not:

XOSC_MHZ is hard-defined so you can't override it (rather than the usual #ifndef then #define).
clocks_init() (in src/rp2_common/hardware_clocks/clocks.c) almost entirely ignores XOSC_MHZ and hard-wires "12" (apart from configuring the watchdog, where it does use XOSC_MHZ!).

I will raise a separate issue as suggested, noting these points. (#1024)

Ooops - point 1) above is wrong - I was accidentally looking at the "host" version of platform_defs.h. The rp2040 version does have the #ifndef wrapper around the definition of XOSC_MHZ. However point 2) is the key issue here.

> Can you not already set that by defining `XOSC_MHZ`? It appears to accept a range 1-50. Unfortunately not: 1) XOSC_MHZ is hard-defined so you can't override it (rather than the usual #ifndef then #define). 2) clocks_init() (in src/rp2_common/hardware_clocks/clocks.c) almost entirely ignores XOSC_MHZ and hard-wires "12" (apart from configuring the watchdog, where it does use XOSC_MHZ!). I will raise a separate issue as suggested, noting these points. (#1024) Ooops - point 1) above is wrong - I was accidentally looking at the "host" version of platform_defs.h. The rp2040 version does have the #ifndef wrapper around the definition of XOSC_MHZ. However point 2) is the key issue here.

optlink commented

2023-11-23 15:57:06 -06:00

(Migrated from github.com)