sdk_config.h inconsistency

[Prasad PL]

Can a single sdk_config file that has all possible macros definitions to use with an SDK

(1) be provided ?

(2) so that an identical sdk_config file be inserted in all examples - so it is easy for customers to merge different examples to make their projects easily. 

What we have now is scrambled sdk macros spread in different examples. [This means example projects does not have all the sdk_config parameters which defeats the purpose of having and sdk_config. altogether].

A huge amount of time is wasted just trying to identify and getting a working sdk_config file. This can be avoided with a single sdk_config that has all parameters. 

using: SDK V15

Secondly:

The aspect of config for logging.

config for logging doesn't have to be mixed with SDK config - which now bloats the sdk_config.h file.

My suggestion is to consider a separate log_config.h to be provided.

Actually this separation is better, configuring logging has nothing to do with configuring SDK.

Then why should logging parameters be mixed in same config file making unnecessary development time spent to clarify clutter by customer?

[tesc]

Hi,

(1) There are sdk_config.h template files in SDK 15, found at <sdk folder>/config/<nrf variant>/config/sdk_config.h.

(2) Our goal is that all the examples have all the options in their sdk_config.h. If not then it is a bug. Note however that what those settings are set to will differ, depending on the needs of the particular example. If you merge functionality from separate examples, or add a module to the project, you must change the settings accordingly.

I will register the suggestion of putting log configuration in a separate file, although one might argue that it would defeat the purpose of having one configuration file for the project. Note that you can do this separation manually if you set the USE_APP_CONFIG flag and put log related settings in app_config.h. (All of the settings in sdk_config.h can be overridden, either by adding the setting as a project flag/define, or by the method of setting USE_APP_CONFIG and using an app_config.h file.)

Regards,
Terje

[awneil]

(I know this is old, but it just came up as a 'Related' topic)

tesc said:

Our goal is that all the examples have all the options in their sdk_config.h.

They most certainly do not:

https://devzone.nordicsemi.com/f/nordic-q-a/45366/missing-defines-in-generic-sdk_config-h

[Benjamin]

Please fix this sooner rather than later. It's obviously been an issue for a long time, and is still a mess in version 16.

The 'generic' sdk_config.h is far from comprehensive, and has duplicates (`grep "#define" sdk_config.h | sort | wc -l` vs `grep "#define" sdk_config.h | sort | uniq | wc -l`). 

The 'generic' sdk_config.h for the nRF52840 has 1149 unique defines. The 'template' (examples/peripherals/template) sdk_config.h has 968 unique defines. Together, they have a combined 1318 unique defines. Adding in ble_app_template/../sdk_config.h brings the total to 1352 unique defines.

Across all the config files for the nRF 52840 DK, it appears there are 1735 defined parameters:

$ find . -path '*/pca10056/*' -name sdk_config.h -exec grep "#define" {} + | cut -d ' ' -f 2 | sort | uniq | wc -l
> 1735

Also, FWIW, roughly 1/3 of that is logging:

$ grep -v -e LOG -e DEBUG_COLOR -e INFO_COLOR nrf52840_sdk_config.h | wc -l
> 1169
$ grep -e LOG -e DEBUG_COLOR -e INFO_COLOR nrf52840_sdk_config.h | wc -l
> 566

For the nRF52 DK there are 1815 defined parameters in total, but only 1254 in the 'generic' sdk_config.h

Now I recognize that the 'generic' config might not contain parameters specific to the DK boards intentionally, but then please update the 'template' examples appropriately, as they are most definitely targeting the dev kits.

[tesc]

Hi,

Thank you for the detailed reporting. I have notified the developers.

Regards,
Terje

[RMV]

SDK v15.3.0 does NOT contain NRF_BLE_CONN_PARAMS_ENABLED, NRF_BLE_GATT_ENABLED among others.

I had to add them to an external file (e.g. app_config.h) in order for the build system to pull in the definitions of functions such as nrf_ble_gatt_init() etc.

[tesc]

Hi,

I see that those are defined in many of the sdk_config.h files throughout the examples, so they are definitely among the defines that should have been in all sdk_config.h.

Regards,
Terje

[chroche]

Hi,

about this topic, is there a fix/update planned for the next SDK release? 

Btw. Is a new release SDK already scheduled?

[tesc]

Hi,

There will be future releases of the nRF5 SDK yes. Checking with the SDK team on the status of this issue with regards to next release.

Regards,
Terje

[JonasJ]

tesc

I count 622 sdk_config.h in the 7.0.2 release. Wouldn't it make more sense to only have one sdk_config.h in the config/nrfXXXX/config/ directory (why the extra config dir?) and make all the examples use the app_config.h feature.

This way it's very obvious what changes the examples has made to the default configuration.

Thanks.

[tesc]

Hi,

Thank you for the suggestion, it is always appreciated! That would be one way to do it, yes. I have forwarded the suggestion to the SDK team.

What we are talking about is the second option for overriding the sdk_config.h configuration file, as documented here: Overriding the sdk_config.h configuration.

Please note that this could still mean mulitple "standard" sdk_config.h files, as there are some differences with regards to e.g. what peripherals are available and in what quantities for the different SoCs.

Regards,
Terje

[__Tom]

It is 2022.10.12 and I'm using SDK17.1.0. sdk_config.h in folder "nRF5_SDK_17.1.0_ddde560\config\nrf52840\config" is still not generic as it's designed for. I wonder whether you guys really have been focusing on improving your sdk. Such issue is driving our company away from your ICs. 

[tesc]

Hi,

You are correct that focus has not been on nRF5 SDK over the past couple of years, since that SDK is now in maintenance mode. Instead we are focusing on the scalable and future-proof nRF Connect SDK. See our nRF Connect SDK and nRF5 SDK statement for details.

Regards,
Terje