raiden00pl opened a new issue, #18894: URL: https://github.com/apache/nuttx/issues/18894
### 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): https://github.com/apache/nuttx/issues/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 - [x] I have verified before submitting the report. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
