Nathan, If you look at the Kinetis, https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63
You can see the gist of that approach. It idea was as developers on the outside of the MFG, we only see the deltas in datasheets. We do not know, the feature set that was added to add to the silicon. So if the IP versioning is not described by the MFG we can make up names. https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63 Then add the "HAS"s. To a feature set or chip and have reuse at the chip level and not litter the code with partnumber. David -----Original Message----- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, April 16, 2020 7:47 AM To: dev@nuttx.apache.org Subject: Re: Adding support for STM32G474RET6 > One thing you can do to keep prevent the runaway dependencies on > specific chips is to parameterized the features. For example, if > STM32abc, STM32def, and STM32ghi and have FEATURE_X, then instead of > conditioning the implementation of FEATURE_X on all of those MCUs, you > could minimize the chaos by defining a single CONFIG_STM32_FEATURE_X > Then conditioning the implementation of FEATURE_X on only that one > parameter. > > Also, use separater files when the logic is vastly different. Look, > for example, at how many stm32*_rcc.c files there are in stm32/. The > correct one is selected in the Make.defs. > Mateusz and DavidS have also been championing the use of versioned driver files. Look at how stm32_dma_v1.c and stm32_dma_v2.c are managed under stm32/ as an example. I have not looked at ChibiOS, but my understanding is that they share all of the drivers for all of the STM32's in some fashion using some versioning. But then the author works for STM32 a surely has a better understanding of the IP versioning than we do. There are a few things that you can do to order support several large families of STM32 parts under a single directory. I am glad you are considering this seriously. Most people have not.
