Skip to content

[Question] when is F_CPU macro set? #612

Closed

Description

@GianniDPC

I am trying to use the following F_CPU macro in a library:
#define F_CPU SystemCoreClock

This macro is found in stm32_def.h.

The problem is that SystemCoreClock is not resolved to a value at that time and the compiler complains that it is not a compile time constant when I try to use it.

Is there any way I can use it properly in a library? I expect to get the SystemCoreClock value.

Activity

  1. fpistm commented on Aug 24, 2019

    @fpistm
    Member

    SystemCoreClock is not a constant so you cannot use it at compile time with pre preprocessor test.

  2. GianniDPC commented on Aug 24, 2019

    @GianniDPC
    Author

    SystemCoreClock is not a constant so you cannot use it at compile time with pre preprocessor test.

    Is there an alternative I can use depending on the board?

  3. fpistm commented on Aug 24, 2019

    @fpistm
    Member

    What is your use case? Sketch?

  4. GianniDPC commented on Aug 24, 2019

    @GianniDPC
    Author

    I am trying to add support for FastLED using this Arduino STM32 Core.

    It defines F_CPU but it seems to be overwritten during compile time by the macro used here, that is why during compilation it complained about not being a compile time constant.

    the value of 'SystemCoreClock' is not usable in a constant expression

    F_CPU declaration in FastLED

    I already added support for the BluePill (See PR on the FastLED project) but I wanted to add all STM32 boards which this core supports.

    It would be easier if I could use some macro that specifies the clock frequency for the board. Because now I had to use some workaround and speciffy the frequency manually.

  5. added a commit that references this issue on Aug 26, 2019
  6. fpistm commented on Aug 26, 2019

    @fpistm
    Member

    Well after looking at FastLed, it seems it was mainly oriented to STM32F1xx based board.

    I proposed to be able to redefined F_CPU in stm32_def.h.

    #ifndef F_CPU
    #define F_CPU SystemCoreClock
    #endif

    But be aware that if a user redefine the SystemClock_Config then this would not be aligned if the F_CPU is fixed in FastLed library.
    Else it is possible to define it at build time using build_opt.h or hal_conf_extra.h:
    https://github.com/stm32duino/wiki/wiki/Custom-definitions

    Note that, the best should be to be able to handle F_CPU during execution as the SystemCoreClock
    can change during execution (low power mode,...). In fact, this is not a constant value even in the most use case it is.

  7. added a commit that references this issue on Aug 27, 2019
  8. fpistm commented on Aug 27, 2019

    @fpistm
    Member

    F_CPU can now be redefined.

  9. self-assigned this
    on Aug 27, 2019
  10. rtek1000 commented on Sep 27, 2019

    @rtek1000

    Hi,

    I would like to lower the clock, to try to reduce the consumption (currently about 27mA and 9mA in sleep mode) found a reference (Table 6*) that may indicate a significant reduction in consumption by reducing the clock.

    How can I implement the clock setting during operation?

    Table 6*:
    https://www.st.com/content/ccc/resource/technical/document/application_note/ff/0a/dc/d2/5e/f5/4b/5a/CD00171691.pdf/files/CD00171691.pdf/jcr:content/translations/en.CD00171691.pdf

    https://electronics.stackexchange.com/questions/294209/stm32f103-arm-modifying-clock-at-runtime-flash-latency

  11. fpistm commented on Sep 28, 2019

    @fpistm
    Member

    You can redefine SystemClock_Config at sketch level to change running freq F_CPU do not forgot using extern "C" in front of the definition.
    Else try the STM32LowPower library.
    Else you can create dedicated function to change it during execution but ensure that all peripherals clock kept the same freq or if you change it ensure to reinit them properly to take in account your changes. Ex if you use Serial and you change its input clock freq then you will hace to reinit it else the baudrate would probably not correct.

  12. rtek1000 commented on Sep 28, 2019

    @rtek1000

    Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions