Remove usage of SystemClock from examples

[salkinium]

xpcc::stm32::SystemClock is a really nice interface, but it cannot easily be ported to new chips.

I'd prefer to replace all occurances of SystemClock in the examples with the fake SystemClock approach, which makes it easier to port to new boards.
The fake SystemClock uses xpcc::stm32::ClockControl, which is ported for a much, much wider range of devices.

[strongly-typed]

I think that's a step back for the most supported platforms like STM32F407 Discovery Board. At least leave a hint what's the better alternative to using the fake SystemClock.

[salkinium]

I disagree. This code is fundamentally broken and it is absolutely incomprehensible for anyone not deeply involved with the SystemClock.

I'm not saying we'll remove the code, so you'll still be able to use SystemClock in your code.
BUT: SystemClock holds back porting, since it is not available for all devices and the "only" reason is that the data is not available.

I'm also not sure if SystemClock is even possible with complex clock trees, due to them being graphs, rather than pure trees. (See #39).

[ekiwi]

How about adding a porting guide to the xpcc.io website?
In it we could point out that it is a good idea to start with porting the xpcc::stm32::ClockControl interface.

While it is difficult to implement, I still think, that the static clock interface is a good idea.
We probably need to move parts of the C++ template generation from Jinja2 to real Python code and find a way to generate the Pll constant calculator programmatically from the clock tree.

I'm also not sure if SystemClock is even possible with complex clock trees, due to them being graphs, rather than pure trees

@salkinium can you point me at a concrete example, for which the concept does not work?
Is there any STM32 device for which the clock tree is more complicated than for the STM32f407? I am asking because the STM32F407 and the STM32F303 were the two controllers for which the static clock code was originally designed.

[salkinium]

How about adding a porting guide to the xpcc.io website?

Drop everything and start writing. Now!

While it is difficult to implement, I still think, that the static clock interface is a good idea.

I'm not debating the usefulness of SystemClock.

It is basically the same issue as with the linkerscripts before they were generated.
The steps you had to do to enable a new device with a linkerscript were simple, but they weren't documented and for someone not familiar with embedded development, probably impossible to execute.

At the moment you can choose to do two things:

1. port SystemClock for your one device, which probably doesn't work for anything else than F3/F4,
2. use the common (!) ClockControl HAL to setup your board clock, incl. domains which SystemClock can't touch, like RTC.

Given that choice, I'd go for 2.

generate the Pll constant calculator programmatically from the clock tree.

The issue is understanding and parsing ST clock graph data to get to this form (or comparable).
ST doesn't have that many different PLL types, so the difficulty is in configuring the rest of the tree. SystemClock has no concept of dealing with any decisions past the SysClk node.

@salkinium can you point me at a concrete example, for which the concept does not work?

The STM32F072 for example has shortcuts in the "tree" (see USART1). RTC and Watchdog don't fit well either. ADC have their own clock.
AHB prescalers, timer prescalers aren't particularly easy to integrate, if you don't want max frequency.