Rework PLL calculation and utilize oscillator clock divison

[Sh3Rm4n]

Rework

This PR turned out to be rework of the PLL setup.

Now get _sysclk will choose, whether PLL is needed as the source for the system clock.

The usb_valid check should work just fine, as we need the PLL anyways to get the supported frequencies (48 MHz and 72 MHz). Both can not be directly generated from the external oscillator as the HSE OSC does only allow up to 32 MHz.

calc_pll does now calculate the optimal divisor and multiplier values to generate the system clock, which the user provides. For that the greatest common divisor calculation is used, because the range of the possible values, which the PRE_DIV and PLL_MUL can take is 16 in both cases.

calc_pll is split into 2 implementations, one for devices which only can adjust the division of the clock of the external oscillator.
The other one, where both HSI and HSE division can be adjusted.

Both can not be directly generated from the external oscillator as the HSE OSC does only allow up to 32 MHz.

Now that the divisor (PRE_DIV) is utilized, 48 MHz and 72 MHz can be generated out of a 32 MHz

48 MHz / 32 MHz can be simplified to 3 / 2 as the greatest common divisor is 16. PLL_MUL is now set to 3 and PRE_DIV is set to 2.

Similarly, 72 MHz / 32 MHz can be simplified to 9 / 4 as the greatest common divisor is 8.

Fix

Initially a fix, which removes HSI division for devices, which do not divide HSI.

Fix #57

Ref #57 (comment)

Relevant parts in the reference manual:

with /2 divisor after HSI

without /2 divisor after HSI

[Sh3Rm4n]

Reminder: Compare with stm32f30x-hal, as this crate does not have this bug.

[Sh3Rm4n]

For stm32f302 devices there is also a distinction between B/C and D/E devices.

This distinction (as features) between these devices do not exist yet.

[Sh3Rm4n]

Going through these quite complicated clock trees: Another reminder.

stm32f303d/e does have an extra PREDIV block, while stm32f302d/e does not.

stm32f303d/e:

stm32f302d/e:

[Sh3Rm4n]

So I tested it on different clock configuration on hardware, seeing if the clock configuration is correctly initialized and most things worked as expected. Now it is possible to choose clocks like 14 MHz on an 8 MHz based Oscillator clocks.

However, with 9 MHz I had a strange problem I used itm (iprintln!) to print out the clock configuration return from freeze(). I always had to adjust the gdb config according to the system clock.

monitor tpiu config internal /tmp/itm.fifo uart off 9000000

But on 9 MHz itmdump return garbage. I don't really know why, I haven't looked into much further. But looking into the register settings and variables via gdb, everything was set up correctly.

[Sh3Rm4n]

I feel like this is ready to be review again.

I don't like the way that the rcc module contains so many asserts, which keeping coming up, when using a wrong configuration. A better documentation for valid clock settings or a way to propagate the error to the user is needed. But this is not scope of this PR.

@russellmcc maybe you'd like to take another look. If not I'll ask somebody else. I'm comfortable merging this code as is but would like to have it reviewed, as this is code everybody depends upon, when using this hal.