-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better clock selection #4
Comments
As a workaround in the meanwhile, one can define e.g. The default define |
Hmm yes this could work.. the builder script in platform-gd32 could then be expanded to accept some |
Looks like the default code in Also for some reason I had to call |
No, actually this can't be right. The variable has an initial value that should be correct according to its clock settings.. gd32-pio-spl-package/gd32/cmsis/variants/gd32f30x/system_gd32f30x.c Lines 64 to 96 in d8af9a4
something else must going on in your example. You did define your clock macro |
Oh, I missed that. Indeed I just defined it to '1' for enable. |
The original GD32 SPL code sadly does a static clock source selection in the
system_xxx.c
file.gd32-pio-spl-package/gd32/cmsis/variants/gd32f30x/system_gd32f30x.c
Lines 42 to 55 in d8af9a4
This means that users who want to change which clock their firmware uses need to edit SPL package files. This is not how it's supposed to be, the SPL files are supposed to be constant but externally user-configurable.
A solution must be engineered that allows, e.g. via global macro setting, to influence the clock selection logic of the SPL framework easily.
Idea: global
CLOCK_SOURCE
macro with numeric values selecting the source? Or better a more dynamic "target frequency" macro, HSE or HSI clock flag, PLL factors macros, ...?It should also be a choice to not compile in the clock selection code, but have the user provide it via one of the project files (and the linker).
The text was updated successfully, but these errors were encountered: