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.

[Keton]

+1 for this also I've so far noticed that not all options of given module are included in example configuration. For example NRF_LOG module has option to define log output colors only for some levels only whereas code of that module allows to configure them for all levels. Another thing is pin definitions for TWI, SPI, etc. Those used to be defined in nrf_drv_config.h but are absent from sdk_config.h

[Ray]

@keton this is a very good point. I'm actually a bit confused about "officially" whether Nordic is suggesting that we put our pin definitions into sdk_config.h, or into custom_board.h (via boards.h && -DBOARD_CUSTOM).

Right now I am maintaining pins in custom_board.h and stripped out the handful of spurious pin definitions from sdk_config.h.

I think it would be helpful for Nordic to give us some definitive guardrails here - such as "put all SDK config parameters into sdk_config.h, and put all your board/pin definitions into custom_board.h", and put all your app and peripheral definitions into your own header files".

If on the other hand we are moving to put all custom board/bsp information into sdk_custom.h, that's also fine. I just think the dev community could use some prescriptive guidance here.

thanks

[Susheel Nuguru]

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 am bit confused here Ray, are you saying that the needed flag was not enabled causing the example to not work?

@Keton, Ifyou go to SPI example you can see that the pins are added in sdk_config.h file. So to answer your question, pin configuration goes into sdk_config.h file for configurable peripherals like TWI, SPI etc, similar to what it was before in SDK11->nrf_drv_config.h

I will talk to the team of what they think about the master_config.h file.

[Ray]

I am not talking about any Nordic example here, Aryan. Rather, to be clear, I'm talking about what I found when trying to convert my own app.

What I did (and likely most developers would do) is to first browse the Nordic examples to get some idea of changes that will need to be made to a) makefile, b) .ld file, c) config files. And that's what I did.

I copied/modified and assembled parameters from various Nordic example sdk_config.h's, trying to put one together that would match my app's needs.

By the time I did the first builds of my app, things compiled cleanly however there were a number of things that couldn't be found at link time.

At that point, I eventually figured out that I'd negledted to set some variables in sdk_config to 1 - like APP_SCHEDULER_ENABLED.

For one set of unresolved references in my app (GPIOTE), I couldn't find any #define in any of the Nordic-supplied sdk_config.h's that related to GPIOTE. However, when I finally looked at the app_gpiote.c source code, I saw that APP_GPIOTE_ENABLED is required.

The fact that Nordic engineers neglected to put APP_GPIOTE_ENABLED into any of the sdk_config.h's was likely an oversight, which is no big deal but it just cost a bit of time.

And so again, to help other developers, I was suggesting a /documentation/config/sdk_config.h or somesuch that would serve as the "truth" that would be easily diff-able by developers from one version of the SDK to the next, that would be the master aggregation of #definess controlling all SDK functionality.

[Susheel Nuguru]

you will soon get an answer from Krzysztof, who have better hold on this topic.