> 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. > >
