This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SDKV12 sdk_config.h "master" ?

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.

Parents
  • 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".

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

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

Children
No Data
Related