SystemClock_Config Visivility

[dhs]

The image below shows how Cube MX allows us to control the visibility of some functions.

Uncheking a prototype moves it from main.c (private) to main.h (public). When unchecking for SystemClock_Config, its  prototype is still generated on main.c, only the static keyword is removed.

It is a bug or for some reason is intented do not calll SystemClock_Config outside main()?

 

 

[Tesla DeLorean]

Unchecking presumably meaning YOU want to call it from outside main.c, but whether you do or not is then in your hands. Typically being called along with HAL_Init() from within main()

A better location might be SystemInit() instead? That way the static can get initialized much faster.

[dhs]

Hi Tesla Guru

It's not a problem fo rme, easy to code a custom solution, but CubeMx is not consistent. Please se my response to Andrew.

[Andrew Neil]

Yes, I agree it's silly that SystemClock_Config()  is not made public.

If (as is common)  the user code puts the chip to sleep, it's likely to adjust clocks for sleep and, therefore, need to restore them on wakeup - calling SystemClock_Config() would seem the obvious way to do that.

 

[Andrew Neil]

---

@dhs wrote:

unchecking for SystemClock_Config, its  prototype is still generated on main.c, only the static keyword is removed.

---

Does a prototype still get generated in main.h ?

[dhs]

---

@Andrew Neil wrote:

---

@dhs wrote:

unchecking for SystemClock_Config, its  prototype is still generated on main.c, only the static keyword is removed.

---

Does a prototype still get generated in main.h ?

---

 

No,

Uncheking (Visibility Static) remove the static keyword, but prototype is still on main.c.

Checking (Visibility Static) puts extern keyword back, as expected prototype is on main.c

All the orthers functions in the visibility list work as expected, unchekeing removes prototypes from main.c and adds it  to main..h