SDKV12 sdk_config.h "master" ?

[Ray]

Hello. I have a question and a request for Nordic developers.

It is really super-helpful that in SDKV12 you converted to having a master sdk_config.h that contains what seems to be 100% of all sdk config parameters. This is terrific.

What has been making conversion from SDK11 a bit more challenging for me, however, is the fact that I can't seem to find a "master" sdk_config.h that contains 100% of all parameters. It has been a trial and error process that involves scanning the sdk_config.h's contained within the various examples, which seem to have differing subsets of sdk_config.h.

Furthermore, in at least one case I was stumped by the fact that there were no sdk_config.h's at all, in any of the examples, that had a parameter that turned out to be necessary and should have been in there: APP_GPIOTE_ENABLED.

I don't know what other developers do, but what I would like to be able to do each time a new SDK is released is this:

1. Go into a subfolder of /documentation that contains the "master" sdk_config.h for that release
2. Diff it against the "master" sdk_config for the previous release.
3. Manually upgrade my own sdk_config.h's based upon what I find.

I say this because given the number of parameters it can be tricky and error-prone to propagate an app's config parameters from one release to another. If the Nordic devs would maintain the sdk_config.h in a "readily diff-able" manner, it would really help 3rd party devs in sdk transitions.

Thanks for your consideration.

[Krzysztof Chruscinski]

Hi,

I'm glad you like moving toward single sdk_config.h. We wanted to make sdk_config.h maintainable between releases and at least all ble_peripheral examples should contain same sdk_config.h (with different modules enabled). Sections and modules in sdk_config.h are sorted in alphabetical order so changes between releases should be visible. It's a first release with common config file so we expect to get feedback and adjust.

Regarding pins configuration it was intentionally left out because sdk_config.h contains static configuration only and in case of drivers it's a default configuration (something that should help user start quickly with the driver) and it's hard to determine default pin configuration, that would be useless. Another thing is that same peripheral might have different run time configuration and then having pin configuration in sdk_config.h would be confusing.

There is a way to extend sdk_config.h with application configuration since sdk_config.h optionally includes "app_config.h".

[Keton]

In case of pins current sdk_config.h is inconsistent as it contains pin definitions for UART (in nRF_log config), PWM and QDEC but omits them for TWI, SPI and the rest. Additionally it contains clock configuration which makes it platform (nRF51/nRF52) dependent. Ideally there would be single platform independent config file containing as many SDK options as possible and other file containing everything closely related to hardware (clock, pins, platform dependent flags, etc.). Also it still would be very helpful to have official list of SDK defines along with explanation. Of course with some time and effort we could grep out all #ifdefs form SDK code but at least some of them aren't meant to be set by user.

[Paul]

I agree with Krzysztof, pin assignment shouldn't be in sdk_config.h. For example TWI pins, pin numbers are part of nrf_drv_twi_config_t being passed into nrf_drv_twi_init. Different developer has different opinion for where the pin definition needs to be. I think there could be a "master/example" sdk_config.h, but not a "standard" one. Different applications will require different project structuring. Different developers also have their unique "habits" for organizing defines. And I do agree that I spend some time every time upgrading into a new SDK revision, and got caused many times because the code did pass compiler/linker. I understand that this is probably the most efficient way for Nordic to upgrade their SDK without considering too much about backwards compatibility. But thanks to this forum, luckily most of the traps have been reported here. Bookmark the devzone and move on :-)