[FEATURE] reorganization of STM32 ports

[raiden00pl]

Is your feature request related to a problem? Please describe.

STM32 ports are a complete mess. Some have their own directory, some don't. Adding new ports means duplicating a whole bunch of code or adding a new family to already existing ports, which is also not elegant.

There is also a problem with naming (kconfig options, port directory, board directory): #16172

Maintaining such code is becoming increasingly difficult and we already have differences in the features supported by STM32 families. We need a better solution that will work better in the long term.

Here is a previous discussion on this topic: https://groups.google.com/g/nuttx/c/G3-EWjjVIT8
Since then, no one has proposed any solution, the number of STM32 maintainers in the project has decreased and the situation with code duplication and chaos in the code has become even worse.

Describe the solution you'd like

I think we should do it like risc-v ports from Espressif. Introduce common directory for STM32, move all duplicated code there and gradually clean up duplicates.

https://github.com/apache/nuttx/tree/master/arch/risc-v/src/common/espressif
https://github.com/apache/nuttx/tree/master/arch/risc-v/src/esp32c3
https://github.com/apache/nuttx/tree/master/arch/risc-v/src/esp32c6
https://github.com/apache/nuttx/tree/master/arch/risc-v/src/esp32h2

This is a really nice solution. Ultimately, the family-specific directory should contain only the family-specific code. No code shared between families in the family-specific directory.

This requires a breaking change on the Kconfig options side. All Kconfig options must be generalized:

CONFIG_STM32L4_ -> CONFIG_STM32_
CONFIG_STM32H7_ -> CONFIG_STM32_
CONFIG_STM32F7_ -> CONFIG_STM32_

and so one. Common Kconfig with common options must be placed in arch/arm/src/common/stm32/Kconfig to avoid Kconfig complaining.

This is the only breaking change that is necessary, and it's the first necessary step to reorganize the STM32. The breaking change is rather easy to fix on the user side, as it requires simply replacing CONFIG_STM32XX_ with CONFIG_STM32_. This change should be implemented in release 13.0 if we want to reorganize STM32 ports as this is significant change. Further work can be done later, gradually, as it's a lot of work.

The longer we wait with this reorganization, the worse it will get. With each new STM32 family, the problem will only get worse.

Work plan:

1. generalize Kconfig options for STM32. Use the same prefix for all STM32 chips CONFIG_STM32_. Breaking change.
2. New page in Docoumentation with descriptions of all supported and unsupported STM32 families. Listing of all IP cores used by the families. Chibios may be helpful here: https://github.com/ChibiOS/ChibiOS/tree/master/os/hal/ports/STM32/LLD
3. move common source code to arch/arm/src/common/stm32/. Keep all reusable sources in one place. No code will be removed yet, there are still a lot of duplicates, but reusing files for new architectures will be easier.
4. split arch/arm/src/common/stm32/ into arch/arm/src/common/stm32f1/, arch/arm/src/common/stm32f2/, arch/arm/src/common/stm32f3/, arch/arm/src/common/stm32f4/, arch/arm/src/common/stm32g4/, arch/arm/src/common/stm32l1/. The same for boards.
5. split arch/arm/src/common/stm32f0l0g0/ into arch/arm/src/common/stm32f0/, arch/arm/src/common/stm32g0/, arch/arm/src/common/stm32l0/, arch/arm/src/common/stm32c0/. The same for boards.
6. unify common sources, remove duplicates and so one. The longest and most difficult step, but it can be done gradually.

The remaining problem is how to handle drivers that are shared between arm and arm64 cores (as in the case of stm32mp). One approach is to create arch/common/src/stm32 shared by different archs, another is to just duplicate the code in arm64.

Describe alternatives you've considered

No response

Verification

• I have verified before submitting the report.