Thoughts on clock config

[David-OConnor]

It seems like the current system fails silently, and gives the user too many degrees of freedom. Eg the illusion you can set whatever speeds you want. I think the STM32Cube IDE visual clock config is a good guide for what configs are valid.

Suggestion: Instead of setting speeds, set the various scalers. This alone reduces the degrees of freedom. Have a helper method to show what speeds these output. Calculate the speeds, and validate before setting. This deals with errors in 2 ways: Prevents requesting speeds that can't be set using the scalers and 2: Fails explicitly if the resulting speeds are out of range.

[David-OConnor]

Closing in favor of #159

[Sh3Rm4n]

Also some ideas came up in #156.

[David-OConnor]

I just noticed that the L0 hal implementation is very similar to the clocks module in my fork. Its base struct holds prescaler values. Its primary API is to use a default. It uses enums for the various scalers, and has functions to show you the resulting speeds.

[Sh3Rm4n]

This is an issue, I still want to tackle, but had no time as of now. I summarized my preferences how to implement a more robust and flexible clock configuration in #156 (review)