This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NCS settings subsystem loading order

Hello everyone,

I'm using the NCS/Zephyr settings subsystem to store some application data in non-volatile memory.

The settings structure looks something like this:

app/peripherals
app/config/0

I use the SETTINGS_STATIC_HANDLER_DEFINE to register two set-functions one for <app/peripherals> and one for <app/config>. I would like to have the <app/peripherals> settings before the other stuff but the set-function for <app/config> is always called before the other one.

I was wondering if I could affect the order in which the set-functions are called?

Thanks in advance!

  • Hi 

    Have you tried to change the order of your calls to settings_register() to see if it changes the order in which the set functions are called?

    If this doesn't work I will check with the software developers if there is some way to influence this. 

    Best regards
    Torbjørn

  • Hello Torbjørn,

    at the moment I don't use the settings_register() function, instead I use the SETTINGS_STATIC_HANDLER_DEFINE() because I don't need the dynamic handler. If I change the order of this macro calls it doesn't influence the settings read order.

    Best regards,
    David

  • Hi David

    Apparently there is no API to set the order explicitly, but they are organized alphabetically by the handler name. 

    In other words you can influence the order by adding a prefix to the handler name, something like this:

    aa_first_handler
    ab_second_handler

    Best regards
    Torbjørn

  • I can't get it to work, that the settings are read in the order i want.

    Here is a basic example that I tried:

    static int alpha_handle_set(const char *key, size_t len_rd,
    			settings_read_cb read_cb, void *cb_arg)
    {
        LOG_INF("ALPHA");
    
        return 0;
    }
    
    
    SETTINGS_STATIC_HANDLER_DEFINE(alpha_handler, "alpha", NULL, alpha_handle_set,
    			       NULL, NULL);
    
    static int beta_handle_set(const char *key, size_t len_rd,
    			settings_read_cb read_cb, void *cb_arg)
    {
        LOG_INF("BETA");
    
        return 0;
    }
    
    SETTINGS_STATIC_HANDLER_DEFINE(beta_handler, "beta", NULL, beta_handle_set,
    			       NULL, NULL);
    
    static int store_settings(void)
    {
        int err;
        static uint32_t value[] = {0xAAAAAAAA, 0xBBBBBBBB};
        const char alpha[] = "alpha";
        const char beta[] = "beta";
        const char *key[] = {alpha, beta};
    
        for (uint8_t i = 0; i < ARRAY_SIZE(value); i++) {       // VARIANT 1 (Save alpha first)
        //for (int8_t i = ARRAY_SIZE(value) - 1; i >= 0; i--) { // VARIANT 2 (Save beta first)
            err = settings_save_one(key[i], &value[i], sizeof(value[i]));
            if (err) {
                LOG_ERR("Couldn't save %s", key[i]);
                return err;
            }
        }
    
        return 0;
    }

    When I use this code it doesn't matter how I name the handlers but the order how I write the settings entries is relevant. If I write alpha and then beta the beta handler is always called first and if I write beta and then alpha the alpha handler is called first.

    In other words you can influence the order by adding a prefix to the handler name, something like this:

    aa_first_handler
    ab_second_handler

    In my case the alpha_handler should always be called before the beta_handler am I right?

    Best regards,
    David

  • Hi David

    You mean to say the order at which you call the SETTINGS_STATIC_HANDLER_DEFINE macros decide which of the set functions is run first?

    db_lw said:
    In my case the alpha_handler should always be called before the beta_handler am I right?

    That was my expectation, yes, but based on your findings this might not be the case. 

    Best regards
    Torbjørn

Related