On Thu, Apr 16, 2020 at 10:41 AM Gregory Nutt <spudan...@gmail.com> wrote: > 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.
I agree. Runaway ifdefs are a nightmare to maintain and, what's worse, the compiler isn't much help at detecting mistakes. I like the idea of parameterizing on CONFIG_STM32_FEATURE_X, using logic in Kconfig to decide which features and versions of features a MCU P/N has, using Make.defs to choose the correct files, and then balancing between adding minimal ifdefs to an existing similar file or creating a new file if the logic is too different. I think that will give the cleanest design. Hopefully I'll still think so after I get neck deep into the code. :-) > 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. I'm leaning more and more toward doing it in the stm32 directory. I prefer not to have duplicate copies of code sitting around and slowly getting out of sync. > Greg > > PS: I see that you are a VP now! Yes, in the Subversion project. You've been paying attention! Cheers, Nathan
