raiden00pl opened a new pull request, #19004: URL: https://github.com/apache/nuttx/pull/19004
## Summary This PR is the first step toward unification and reorganisation of STM32 ports. This is a huge, breaking change that impacts many users. It also introduces the standard for STM32 ports described in the documentation page. Any new STM32 port or new STM32 feature should adhere to these rules. This reorganization allows for the separation of STM32 families with minimal code duplication. Ultimately, we'll be able to eliminate most of the duplication between STM32 families, but this is a long-term task. Subsequent changes won't be as invasive, and most won't require breaking changes. This PR focuses on the first step in the STM32 redesign, which is the most invasive and includes a lot of breaking changes. Summary of changes: 1. Each STM32 family has its own directory. 2. STM32 families can use the STM32 common directory, which allows them to use common drivers and common hardware definitions shared between families. 3. Peripheral drivers included by a family depend on the peripheral's IP core version. 4. STM32 Kconfig option names are unified. 5. STM32 boards can use common board drivers. 6. STM32 hardware definition names are unified. 7. Kconfig files have been split into smaller ones, which makes them much easier to manage. This was proposed several times for new STM32 ports before, but doing it for one STM32 port and leaving the rest untouched didn't make sense. Now it's done for all STM32 ports, as it should be. 8. Added a documentation page discussing STM32 ports organisation. 9. Add boards/common/stm32 support for STM32L4 What is not done yet: 1. Migrate all other families to STM32 arch common directories. The stm32f7, stm32h7, and stm32l4 should be easy. The rest, based on the Cortex-M33, will require more time because I'm not familiar with these chips yet. After this migration, support for the missing stm32 families should be much easier. 2. Migrate all other families to STM32 board common directories. This change will later enable us to solve another problem - the standardization of ST boards, so all nucleo board follows the same patterns and provide the same features. 3. Unify and clean up Kconfig options and families features. Ultimately, each family should support the same features as the hardware allows. At the moment Kconfig has some long and ugly lines, they need to be analyzed and simplified. Kconfig still has a few sections that have not been generalized, mainly due to drift of some families from other implementations. 4. Some families have driver changes that haven't been propagated to other families. This needs to be properly analyzed and ported where possible. 5. regenerate CODEOWNERS **I know this PR is huge, but it can't really be done in smaller steps. This is an attempt to fix a problem that's been building for over a decade. I will create a separate PR so it is easier to review, this PR is to show the final effect** . The best way to review this change is to download the entire branch and view it locally. **If the community deems this change desirable, it should be included in version 13.0, as it's a significant change that's causing a lot of disruption. I think this is the best time for this reorganization, even if it will upset many users and likely break something.** For all AI skeptics here - this PR was created with AI assistance and burned hundreds of dollars worth of tokens. There is no other way to do it, doing it manually is unrealistic, especially if you do it alone and for free :) This PR doesn't add new code, it only organizes the old code, so the code license remains the same as the original code References: https://github.com/apache/nuttx/issues/18894 https://github.com/apache/nuttx/issues/16172 ## Impact Breaking change that impacts many users. There should be no functional changes; users should only need to update defconfig options in theory, but this is a huge change done mostly with AI assistance, so there is some chance that things will be broken. The larger the PR, the greater the chance that something will break uncontrollably. Therefore, if this change is to be implemented upstream, it should be in release 13.0, which already contains a lot of breaking changes. I tried to preserve the git history as much as possible, but for Kconfig it was not possible. What we gain from this PR: 1. Unification and standardization of STM32. Portability between STM32 families will finally be as it should be. No more questions about how to create new STM32 ports, everything is set in advance and the user has to comply. 2. After the migration of the remaining families to common/stm32 is completed, maintaining the families will be much easier. Fewer files to track, less duplicate code. 3. Adding support for new STM32 families will be easier. Reusable blocks can be easily included by new ports. 4. All STM32 boards can use the same boards/common, which can significantly simplify boards code. Ultimately, it should be possible to standardize all STM32 boards like nucleo and create common board initialization logic. ## Testing CI TODO upstream build and test: * nucleo-l073rz:nsh - OK * nucleo-f103rb:nsh * nucleo-l152re:nsh * nucleo-f091rc:nsh * nucleo-c071rb:jumbo * nucleo-h743zi2:jumbo * nucleo-f446re:jumbo Later I will do tests with my Dawn project (https://github.com/railab/dawn) where I have a lot of HW automated tests based on NTFC, so it should catch most of the regressions. -- 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]
