Another problem with leaving CONFIG_STM32H7_* is the lack of standardization across other ports. Why does the STM32H7 have a suffix and the STM32G4 doesn't? If we keep suffixes, it should be added for every family, but this ultimately leads to more complex code than it currently is. As a result, the entire reorganization and unification becomes pointless.
sob., 6 cze 2026 o 10:59 raiden00pl <[email protected]> napisał(a): > > Such change is reasonable, but I think that definitions like > CONFIG_STM32H7_* should be preserved. > > Unfortunately, this can't be preserved if we want to unify ports. In fact, > it's the main blocker of any unification. > > sob., 6 cze 2026 o 10:53 <[email protected]> napisał(a): > >> Hi all, >> >> Such change is reasonable, but I think that definitions like >> CONFIG_STM32H7_* should be preserved. >> >> Best regards >> >> -----Original Message----- >> From: raiden00pl <[email protected]> >> Sent: Saturday, June 6, 2026 11:27 AM >> To: [email protected] >> Subject: [BREAKING CHANGE] Unification of STM32 ports >> >> Some time ago, I started working on reorganizing STM32 to use common >> peripheral driver code wherever possible. The goal is to standardize and >> organize >> STM32 ports >> so that they are easier to use, easier to maintain, and easier to add new >> stm32 ports >> and new features. >> >> Code duplication in STM32 ports has reached such a level that it's hard >> to maintain and synchronize. At some point, the copy-paste approach becomes >> an anti-pattern, and in the case of STM32, this has been achieved. >> Many new families are copy-pasted from old code, but some authors >> introducing new features or patterns of their own, making the ports >> incompatible with each other. Furthermore, not all changes were ported to >> other families where they should have been, and now we have a multitude of >> different, incompatible code. >> >> Draft PR with more details is here: >> https://github.com/apache/nuttx/pull/19004 >> >> The entire reorganization is a long-term effort, this PR focuses >> primarily on the initial stages and breaking changes that need to be >> applied. Ultimately, Kconfig will be cleaned up and all overly complex >> drivers that messily mix multiple IP cores will be separated so we limit >> "#ifdefs" to minimum >> >> This change requires a number of breaking changes, mainly related to >> standardizing Kconfig options and standardizing the STM32 API. The changes >> are primarily name changes, such as stm32h7_xxx() to stm32_xxx(), >> CONFIG_STM32H7_ to CONFIG_STM32_ and so one. Also most out-of-tree STM32 >> specific code will need to be migrated. >> >> In short, the main changes are: >> 1. Introduction of the STM32 port standard described in the documentation. >> All future stm32 ports must conform to this. >> 1. Unification of Kconfig options, each family uses the same names. >> (STM32_XXX not STM32L4_XXX etc) >> 2. Each family has a separate folder in /arch: stm32f1, stm32f2, stm32h7 >> etc. >> Family directory contains family-specific things that should not be >> shared, >> e.g. chip definitions, memory map, irq map, pin definitions, etc 3. >> Code that can be shared between families goes to arch/arm/src/common/stm32. >> Code that should not be shared remains in the family directory. >> 4. Peripheral drivers are divided based on the IP core. Families that use >> the >> same IP core use the same driver code. >> 5. The huge Kconfig for stm32 is divided into smaller parts: Kconfig.tim, >> Kconfig.adc, Kconfig.spi etc. >> 6. Thanks to the generalized /arch API, we can create generalized >> common board code, significantly reducing code duplication in boards. >> Later we can standardize the functions available on nucleo boards. >> >> If there is no massive community backlash against this change, I'll start >> opening smaller PRs with the changes next week. If the community agrees, >> the major breaking changes from draft PR should go into release 13.0, which >> is already a significant breaking release. >> >>
