Tidying up clock config of H5.

[dojyorin]

Summary

The generic clock config for STM32H5 series will be made as common as possible.
As a result, only differences will be the number of peripherals that vary by part number, clock source and peripherals used by each variant, etc.

We have also tidied up the writing style, such as commenting out.

This fixes H503KBU which was not included in #2598 fix.

Common changes

• Common to all
  • USB uses HSI48
• Common in H503
  • Peripherals: RCC_PERIPHCLK_ADCDAC RCC_PERIPHCLK_LPUART1 RCC_PERIPHCLK_USB RCC_PERIPHCLK_SPI1 RCC_PERIPHCLK_SPI2 RCC_PERIPHCLK_SPI3
• Common in H562 H563 H573
  • SDMMC1 operates at 50MHz.
  • Peripherals: RCC_PERIPHCLK_SDMMC1 RCC_PERIPHCLK_ADCDAC RCC_PERIPHCLK_LPUART1 RCC_PERIPHCLK_USB RCC_PERIPHCLK_SPI1 RCC_PERIPHCLK_SPI2 RCC_PERIPHCLK_SPI3 RCC_PERIPHCLK_SPI4 RCC_PERIPHCLK_SPI5 RCC_PERIPHCLK_SPI6
    • RCC_PERIPHCLK_SPI4 and RCC_PERIPHCLK_SPI5 is only for models with high pin count.

Variant-specific changes

• H503CB(T-U)
  • Writing style has been improved.
• H503KBU
  • Writing style has been improved.
  • [STM32H503] SPI1 does not send anything #2598 has been fixed.
  • PLL1Q value has been made consistent with H503CB(T-U) and H503RBT values.
• H503RBT
  • Writing style has been improved.
• variant: NUCLEO_H503RB
  • Follow H503RBT.
• H562R(G-I)T
  • Writing style has been improved.
  • PLL2R and USB value has been made consistent with H563R(G-I)T, H563IIKxQ_H573IIKxQ and H563Z(G-I)T values.
• variant: WEACT_H562RG
  • Follow H562R(G-I)T.
• H563IIKxQ_H573IIKxQ
  • Writing style has been improved.
  • OSPI removed.
• variant: STM32H573I_DK
  • Follow H563IIKxQ_H573IIKxQ.
  • Since SAI is enabled, I have not touched PLL2 multiplex.
• H563R(G-I)T
  • Writing style has been improved.
  • PLL2R and SDMMC1 value has been made consistent with H562R(G-I)T, H563IIKxQ_H573IIKxQ and H563Z(G-I)T values.
• H563Z(G-I)T
  • Writing style has been improved.
  • SDMMC1 value has been made consistent with H562R(G-I)T, H563IIKxQ_H573IIKxQ and H563R(G-I)T values.
• variant: NUCLEO_H563ZI
  • Follow H563Z(G-I)T.
  • Since PLL is HSE, adjust multiplex so that final frequency is same as H563Z(G-I)T.

[dojyorin]

Ah, I'm stupid.
I forgot to add HSI48 and CSI to the clock sources for NUCLEO_H563ZI.
Sorry.

[fpistm]

Hi @dojyorin
I don't see any benefits from this PR except for the H503K.

[dojyorin]

@fpistm
I've been working on a project that uses H5 continuously for some time, and I thought that if I could tidy up the code base, I'd be able to comfortably expand future H5 variants.
If this PR increases the likelihood of serious issues, I think you should withdraw it, but if it's OK from the perspective of tidying up the code base, would you consider merging it?

[dojyorin]

For example, by organizing things in this PR, it will be easier to visually distinguish the differences in a diff editor, making it easier to add new variants and apply patches.

I'm currently developing several custom H5 boards, and when I was referencing the code of existing variants to add a variant, I was a little confused by the subtle variations in numbers and notation.

I submitted a PR to reduce experiences like this.

[dojyorin]

@fpistm
Thank you for understanding the purpose.
And thank you for correcting my work.

I'll fix the corrections this weekend.

[fpistm]

Honestly, I understand your point to change config order will help ton compare anyway changing several values just to have less difference is risky and probably add regressions.
Current config is know to work and I have no time to test this PR on each target to ensure it is correct.

Please revert to CSI the Nucleo H503RB config as the one you set is not correct.

[dojyorin]

I thought I had checked datasheets, but it seems I still didn't fully understand it.
I'm sorry for bothering you repeatedly.
Thank you for your detailed explanation.
I will fix it soon.

[fpistm]

I've updated the PR. Honestly, anytime a new H5 board will be added the clock config will not be aligned with your reordering.
Cube MX generate config in different order and ofeten with different values.
I have some doubt about the disco but as said would not like spent too much time on this kind of PR.
For me it is ok like this.

[fpistm]

LGTM. No test performed.

[dojyorin]

I understood that code cleanup does not make much sense.
As this project is largely founded on your contribution, I have decided to follow your opinion.

[fpistm]

Not agreed. I understand your point about diff but you changed some configurations for specific hardware which could bring some regressions. And as stated above cube mx does not follow this rules. Anyway any contributions are welcome. I'd like to have more contributions and hope to find new maintainers. Moreover some of your changes seems go to have a better configurations. 😉