Make clocks_init weak so a user can provide their own version #745

Closed

MichaelBell wants to merge 1 commit from allow-clocks-init-override into develop

MichaelBell commented

2022-03-04 11:15:46 -06:00

(Migrated from github.com)

The clocks_init function in the SDK unconditionally sets up the external crystal and PLLs. This function is called as part of runtime_init before the user's main function.

It would be nice to be able to override this behaviour so that the system could be started from ROSC only, or simply to avoid bringing up the PLLs. This would make it straightforward to create a project that did not use an external crystal using the standard SDK.

I propose to fix this by making the clocks_init function weak. The user project can then provide their own version that configures ROSC and the clocks they need appropriately, and their version will be preferred by the linker.

The `clocks_init` function in the SDK unconditionally sets up the external crystal and PLLs. This function is called as part of runtime_init before the user's main function. It would be nice to be able to override this behaviour so that the system could be started from ROSC only, or simply to avoid bringing up the PLLs. This would make it straightforward to create a project that did not use an external crystal using the standard SDK. I propose to fix this by making the `clocks_init` function weak. The user project can then provide their own version that configures ROSC and the clocks they need appropriately, and their version will be preferred by the linker.

kilograham commented

2022-03-04 14:19:16 -06:00

(Migrated from github.com)

I agree that the current rather monolithic and fixed runtime startup is not super flexible, and plan to reorganize it in a more customizable fashion.

Thus far we have shied away from overriding of __weak symbols (as opposed to having them be present or NULL) because I believe the various compiler/linkers do not support this correctly. I will take another look when we deal with clang support.

In any case, I'm not going to accept this for now. Feel free to open an issue to track the requirement.

You should be able to workaround it for now by setting

set(SKIP_HARDWARE_CLOCKS 1)

at the top of your CMakeLists.txt and providing your own replacement implementation of hardware_clocks. not ideal, but is should work

I agree that the current rather monolithic and fixed runtime startup is not super flexible, and plan to reorganize it in a more customizable fashion. Thus far we have shied away from overriding of `__weak` symbols (as opposed to having them be present or NULL) because I believe the various compiler/linkers do not support this correctly. I will take another look when we deal with `clang` support. In any case, I'm not going to accept this for now. Feel free to open an issue to track the requirement. You should be able to workaround it for now by setting ``` set(SKIP_HARDWARE_CLOCKS 1) ``` at the top of your `CMakeLists.txt` and providing your own replacement implementation of `hardware_clocks`. not ideal, but is should work

lurch commented

2022-03-04 14:33:52 -06:00

(Migrated from github.com)

You should be able to workaround it for now by ...

@kilograham Should that be mentioned in https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf somewhere, or is it too much of a "hack" to document?

> You should be able to workaround it for now by ... @kilograham Should that be mentioned in https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf somewhere, or is it too much of a "hack" to document?

MichaelBell commented

2022-03-05 16:50:03 -06:00

(Migrated from github.com)

Thanks for the info on the SKIP settings. I've been able to acheive what I wanted using SKIP_PICO_RUNTIME and copying that directory out into my own project and making a couple of tweaks. This was nicer than just overriding clocks_init, as I no longer have to bring the USB clock up just to take the USB device out of reset, as I can tweak rutime_init not to take it out of reset.

Overall I agree that the init code just needs to be more configurable - I've raised an issue with some discussion and ideas. Closing this request.

Thanks for the info on the `SKIP` settings. I've been able to acheive what I wanted using `SKIP_PICO_RUNTIME` and copying that directory out into my own project and making a couple of tweaks. This was nicer than just overriding `clocks_init`, as I no longer have to bring the USB clock up just to take the USB device out of reset, as I can tweak `rutime_init` not to take it out of reset. Overall I agree that the init code just needs to be more configurable - I've raised an issue with some discussion and ideas. Closing this request.

kilograham commented

2022-03-05 18:56:30 -06:00

(Migrated from github.com)

You should be able to workaround it for now by ...

@kilograham Should that be mentioned in https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf somewhere, or is it too much of a "hack" to document?

note i thought it was documented, but perhaps not very well !?

hmm; i don't obviously see it... perhaps I have just mentioned it on the forums a bunch

> > You should be able to workaround it for now by ... > > @kilograham Should that be mentioned in https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf somewhere, or is it too much of a "hack" to document? note i *thought* it was documented, but perhaps not very well !? hmm; i don't obviously see it... perhaps I have just mentioned it on the forums a bunch