Module dependencies

RE: Module dependencies

Jørgen Holmefjord — Thu, 31 May 2018 15:10:46 GMT

I'm not sure I understand your point. It is no problem to use a mix of new nrfx drivers and legacy drivers. The configuration is only overwritten if you have the configuration for that specific legacy driver in your sdk_config.h file. If you only have nrfx driver configs, this will be used. If you have SAADC legacy driver configs and NRFX SPIM driver configs in sdk_config.h, only SAADC NRFX driver config will be overwritten by apply_old_config.h. It is not possible to use a mix of legacy SAADC driver functions and NRFX_SAADC driver function calls as this will cause driver issues.

The thing I could agree on is that it should be clearified that the legacy configs need to be removed (not just set to 0) from sdk_config.h when switching to NRFX drivers. This could also have been resolved in apply_old_config.h by only overwriting the settings if the legacy drivers was enabled:

#if defined(SAADC_ENABLED) && (SAADC_ENABLED == 1)

#undef NRFX_SAADC_ENABLED
#define NRFX_SAADC_ENABLED SAADC_ENABLED

RE: Module dependencies

jev — Thu, 31 May 2018 13:14:44 GMT

That assumption is just bad practice IMHO. This way, we cannot use a mixed style drivers thus new drivers will either be written based on soon-to-be-deprecated API's or we'll have to rewrite existing drivers now too.

RE: Module dependencies

Jørgen Holmefjord — Tue, 29 May 2018 12:23:31 GMT

Hi,

I have forwarded your request on more documentation of SDK module dependencies to our SDK team.

I'm not sure I understand what you mean is the issue with the SAADC_ENABLED/NRFX_SAADC_ENABLED configs. The legacy layer was provided as a simple way to migrate projects to the new SDK/nrfx driver library without having to update the whole API. If you enable the legacy driver in the sdk_config.h file (SAADC_ENABLED), it is assumed that this will be used. Since this is just a legacy layer running on top of the NRFX_SAADC driver, the apply_old_config.h file makes sure the NRFX driver is enabled, as this is required for the legacy layer to work. If you want to use the new NRFX drivers, you should remove the legacy configs from the sdk_config.h file. If you switch to using the new drivers instead of the legacy layer, you should not face debugging issues due to function renaming using defines. We will migrate more examples to use nrfx drivers in future SDKS.

Not all examples requre all sdk_config parameters, and not every config is included in the sdk_config.h files. In the examples, only the modules that is used should be enabled. The sdk_config.h file found in config directory contains most config parameters. You should feel free to use this for your project and redefine your configs using app_config.h file.

Best regards,
Jørgen

RE: Module dependencies

jev — Mon, 28 May 2018 12:22:12 GMT

Guys... can you please fix the legacy support you tried to use in sdk_config.h? I was bitten once more with this...

Example: in the sdk_config.h you provide in the template project, you have defines for both, SAADC_ENABLED and NRFX_SAADC_ENABLED. This suggests as per comments in sdk_config.h that the latter actually enables the renames nrfx_ prefixed driver. It doesn't since the setting is silently overwritten in apply_old_config.h:

#if defined(SAADC_ENABLED)

#undef NRFX_SAADC_ENABLED
#define NRFX_SAADC_ENABLED  SAADC_ENABLED

This is not just true for SAADC, but others as well.

Also, it would make things a lot clearer if you did not include modified sdk_config.h files in the example projects. You provide a mechanism to #include "app_config.h". Why not use it? It makes things perfectly clear: "for this example, we modified this, this and this".

Thanks for listening again guys. I hope these comments help to make the SDK easier to understand. Keep up the good work!

PS: the renaming of symbols through macro's kills debugability. So please please please... don't! Example:

#define nrf_drv_saadc_uninit            nrfx_saadc_uninit

It looks like there is a function "nrf_drv_saadc_uninit" after this backward-compatibility definition, but in the debugger there is no way I can find a symbol named nrf_drv_saadc_uninit which makes it unnecessary hard to put a breakpoint on it for example.