apply_old_config.h quietly overwrites my settings.

[charles]

Many of the sdk_config.h examples have both NRFX_FOO_ENABLED and FOO_ENABLED defined.

So, imagine my surprise when I change, say, NRFX_TIMER3_ENABLED to 1, still get link errors about undefined nrfx_timer symbols, and eventually chase it down to apply_old_config.h simply stomping on my explicitly-defined symbol.

Please change apply_old_config.h to emit a compiler error via the #error directive if both the NRFX_FOO_ENABLED and FOO_ENABLED variables are defined.

#if defined(NRFX_PPI_ENABLED) && defined(PPI_ENABLED)
  #error The NRFX_PPI_ENABLED and PPI_ENABLED flags are incompatible and can not both be set. Please choose one.
#endif

#if defined(PPI_ENABLED)
  #define NRFX_PPI_ENABLED PPI_ENABLED
#endif

This approach will preserve the automatic application of old pre-NRFX_ config macros and guide users towards the correct implementation. I would much rather be steered by compiler errors than spend time navigating a twisty maze of macro definitions trying to figure out why the .c file I'm trying to compile, with the correct NRFX_FOO_ENABLED flag supplied via my sdk_config.h, is getting #ifdef-d into oblivion.

[Edvin]

Hello,

Several users have reported this. I agree that it is not intuitive that it works the way it does. But when you are aware of the apply_old_config.h file, it should be possible to follow how these settings work.

I guess the reason for the apply_old_config.h file is to make the SDK backwards compatible with the old sdk_config.h names. The way I see it there are 3 options:

1: You can exclude the apply_old_config.h file from your project, and use NRFX_FOO_ENABLED instead of FOO_ENABLED

2: You can use the "legacy" (FOO_ENABLED) definitions in sdk_config, and ignore the NRFX_FOO_ENABLED.

3: You can use both, but make sure that FOO_ENABLED = NRFX_FOO_ENABLED (a bit cumbersome, but it may be easier if you are just changing something in a project).

Thank you for the feedback. I will take this onward to our SDK team.

Best regards,

Edvin

[charles]

Thanks for the response.

1. Doesn't seem feasible, since #including various nrfx_ headers pull this in. (nrfx.h -> nrfx_glue.h -> apply_old_config.h). This isn't a header I choose it include; it's forced on me every time I include a nrfx header.

2. Yes, except this doesn't appear to be documented anywhere, and almost all of the Nordic-supplied sdk_config.h files #define both the regular and NRFX_ flavors by default, with no indication that the NRFX_ ones are effectively ignored.

3. Yup, we ended up doing something close to this and just deleting the versions of the parts we weren't using.

This gets especially delicate when nrf_ drivers use some resources and nrfx_ drivers use others. For example, we use app_timer2 against RTC1, which demands NRF_RTC_ENABLED and NRF_RTC1_ENABLED or it won't compile. Then, we get guidance fromhttps://devzone.nordicsemi.com/f/nordic-q-a/65106/nrfx_rtc_init-vs-drv_rtc_init that we should always prefer using the new nrfx drivers for direct HAL work.

So, as a result, our sdk_config.h looks roughly like:

#define NRF_RTC_ENABLED 1

#define NRFX_RTC_ENABLED 1

#define NRF_RTC1_ENABLED 1

#define NRFX_RTC2_ENABLED 1

Because we have two separate nrf drivers competing with each other, and they both redefine the various IRQ handlers required to make them work. So, we have drv_rtc.c claiming the RTC1 IRQ handler and nrfx_rtc.c claiming the RTC2 IRQ handler. This whole thing is kind of a mess.

The code should be written such that the compiler helps us navigate this, but instead the code is written such that we have to spend hours spelunking through preprocessor macro details to find when it's silently overwriting our configurations. It would have been equally easy to emit helpful compiler error directives; I truly hope that there's a philosophical shift towards user-friendliness coming.