Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Recommended workflow to update sdk_config.h ?

Hi,

my question might sound a bit silly, but I am certain that someone already faced the problem therefore I am wondering how it was addressed.

The question:

what is the recommended workflow to migrate the sdk_config.h file of a Nordic SDK software project from an older SDK version to a newer one?

I have started a project with SDK 15.0.0 and would like to migrate it to SDK 15.2.0 due to obvious advantages of the newer SDK version.

The problem is that sdk_config.h has undergone a large overhaul between SDK 15.0.0 and 15.2.0. It is not simply a few lines of code added at the end of the file, but the whole file structure is different (sections pertaining to certain features have been moved to other places in the file).

Since the sdk_config.h in my project contains several personalizations (which I cannot all remember with absolute certainity), I am in trouble to transfer these changes to the new sdk_config.h

I have tried to run a side-by-side file comparison between the new (v15.2.0) sdk_config.h and my (v15.0.0) personalized version of the same file. But for the reasons exposed above, this method is impractical. 

Using CMSIS configuration wizard to "copy" the changes implemented in my original sdk_config.h file to the new one does not work either, because some features have changed name or have been moved or removed. And besides, CMSIS configuration wizard is not able to show all the details in the file.

As a last resort, I tried to "manually" scan through my old sdk_config.h file and locate the corresponding items in a new "original" v15.2.0 sdk_config.h file and implement the personalizations one by one in an editor.
This took me several hours of work and the result was unsatisfactory because I must have messed up some CMSIS formatting tags with the result that the file can no longer be opened with the CMSIS configuration wizard.

I would hate having to repeat such a nightmare the next time I will have to migrate my project to a newer SDK.

Therefore here is my question:

What is the recommended workflow to migrate a (already customized) sdk_config.h file from an older SDK version to a newer one, without loosing the customizations and with the lowest risk of human errors?

THANKS for any valuable suggestion!!!

Parents
  • Hi.

    The API included in sdk_config.h in SDK 15.2 should be the same as the API included in the major versions sdk_config.h (SDK 15.0). This should apply for all major and minors (ex API should be the same in SDK 14.0, 14.1, 14.2, but it might not be the same from 14.0 to 15.0).

    With this in background, if you are working on a example project, the content of the sdk_config.h file should contain the same in SDK 15.0 as in SDK 15.2. Where the different #defines are placed should not matter, unless you want a clear structure of where you place your different #defines.

    You could use the USE_APP_CONFIG macro to place the #defines which you miss in SDK 15.2 from SDK 15.0 in a seperate configuration file you name app_config.h.

    Like this:

    #ifndef APP_CONFIG_H__
    #define APP_CONFIG_H__
    
    #include <stdbool.h>
    
    /**
     * @defgroup APP_SDK_CONFIG SDK configuration
     *
     * Application-specific SDK configuration settings are provided here.
     *
     * @{
     */
    
    /* Override default sdk_config.h values. */
    #define THE
    #define DEFINES
    #define THAT
    #define ARE
    #define DEFINED
    #define HERE
    #define WILL
    #define OVERRIDE
    #define THE
    #define DEFINES
    #define DONE
    #define IN
    #define sdk_config.h
    
    /** @} end of APP_SDK_CONFIG */
    
    #endif /* APP_CONFIG_H__ */
    

    And then you edit the top of your sdk_config.h file to:

    #define USE_APP_CONFIG
    #ifdef USE_APP_CONFIG
    #include "app_config.h"
    #endif

    Using this technique also allows you to be more thorough with adding only the nessesary defines, if you read the API on the infocenter and are aware of which defines you require.

    I hope this helps you, best regards.

    Andreas

  • Hi Andreas, thank you for this code snippet -- it is extremely helpful. Would you kindly explain how/why the defines in app_config.h override the defines in sdk_config.h? How does the preprocessor know that app_config.h should take precedence?

    Since #include app_config.h is at the beginning of the sdk_config.h file, based on this and this, you would think that when the same things get defined later in sdk_config.h, those #defines would override the #defines in app_config.h, undoing your custom configs. 

    EDIT: never mind, no reply needed. I see that sdk_config.h is full of #ifndef and #define, so that it doesn't overwrite things that are already defined.

Reply
  • Hi Andreas, thank you for this code snippet -- it is extremely helpful. Would you kindly explain how/why the defines in app_config.h override the defines in sdk_config.h? How does the preprocessor know that app_config.h should take precedence?

    Since #include app_config.h is at the beginning of the sdk_config.h file, based on this and this, you would think that when the same things get defined later in sdk_config.h, those #defines would override the #defines in app_config.h, undoing your custom configs. 

    EDIT: never mind, no reply needed. I see that sdk_config.h is full of #ifndef and #define, so that it doesn't overwrite things that are already defined.

Children
No Data
Related