Full RCC support for STM32F107

[algesten]

STM32F107 has a two more PLLs than F013, which means using f013.rs config options doesn't let us configure the entire RCC.

My use case is to use STM32F107 for ethernet with an external HSE.

This PR adds a special case for F107 with a fuller RCC config.

[Dirbaio]

instead of adding a new f107.rs file, could you add support for the PLLs in f013.rs using cfg's like cfg(stm32f107)?

(We used to have code duplication like this in RCC a while ago and it proved to be an unmaintainable mess. Hard to keep them in sync with fixes and features. the file you've added is already out of sync, for example it does .unwrap() instead of unwrap!(..) and is missing the asserts for min/max frequencies)

[algesten]

@Dirbaio sure. Is there some thinking of how these are bundled together? Like, why is f107 sorted under f013? Like is there some arch concept that certain groups of STM32 belongs together?

[Dirbaio]

Yes, they're grouped by "what STM32 families are more similar". ST did some design for the F1, then F107, F3, F0 are incremental improvements on top of that but the "overall structure" stays very similar. OTOH they designed the PLLs very differently for F2, then F4, F7 are incremental improvements on top of that. Etc etc.

(f013 means "STM32F0 + STM32F1 + STM32F3", not "STM32F013")

[algesten]

@Dirbaio thanks for explaining.

I have pushed an update where I try to merge the changes into f013.rs. Hopefully it's closer to what you want.

[Dirbaio]

very nice! thank you 🚀

[algesten]

@Dirbaio thanks! Just one thing more to fix. There's an exported PreDiv1Src I don't believe I need anymore.

[algesten]

Just going to check with my board as well, just to make sure I didn't break anything.

[algesten]

Yeah. It's not working. Need to figure out why.

[algesten]

@Dirbaio found it. The problem was that set_prediv1src must be set after configuring the PLL.

I think we're good to go!

[Dirbaio]

oh huh. shouldn't it be the other way around? if pll1 is fed from pll2, init order should be prediv2, pll2, prediv1, pll1.

With the previous code it'd fail because you were starting pll1 without starting pll2 first, which would hang because it'd have no clock. Now you're leaving pll1 source as default (so, from HSE), then initialize it (which works because it has a clock), then switch it to pll2 while it's already running. I don't think it's allowed to change a pll source clock while it's running.

[algesten]

I don't think it's allowed to change a pll source clock while it's running.

Right. It works, but maybe is dodgy :)

I'll revise the code to ensure the order is correct for: prediv2, pll2, prediv1, pll1

[Dirbaio]

thanks!