• State Verified Answer
  • Replies 2 replies
  • Subscribers 88 subscribers
  • Views 794 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 262651
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Mismatch between nrfx 2.4.0 and SDK 17.0.2???

essele

I am now pulling my hair out with these drivers ... I'm trying to do what I think is the right thing and use the new nrfx drivers, but it's really not easy.

So this started by me trying to use the SAADC nrfx driver ... I've added the .c file from the nrfx drivers directory, but the init() call didn't match the one in the documentation. After a fair amount of faffing around I discovered that the version of nrfx included in the 17.0.2 SDK download isn't current (at all) ... in fact, according to the change log it's 1.8.6 from 2020-08-31.

So I moved that version out of the way and grabbed 2.4.0 from GitHub. A quick skim of the files and they clearly match the documentation, which is a start.

However ... the changelog show a completely different set of updates and dates, and there's no reference to 1.8.6 anywhere. Is this a different fork?

My app now won't build because the init() function of nrfx_gpiote is different than app_button.c expects for example .... plus quite a few other areas where you now need to provide IRQ levels or register details.

I notice from the "migration guide for nrfx drivers" that there are some library dependencies that "need to be resolved."

So am I right in thinking that in order to use the drivers that are not legacy I need to go and fix a load of library files that are part of the most recently provided SDK? Surely not -- that means that I'll have to do it for each future SDK version??

Lee.

Parents
  • +1

    Hi,

    nrfx v2.x.x is not supported by nRF5 SDK, and will most likely not be supported in the future either. nRF5 SDK supports the nrfx 1.8.x branch, and this is the recommended use for nRF5 SDK. For other SDKs and RTOSes, like nRF Connect SDK, nrfx v2.x.x is supported.

    Regarding the nrfx_saadc driver, there is two APIs available (#1 - #2). The driver was totally rewritten to resolve a few issues. Initially, the new API was only supported in nRFx v2.x.x, but this API was backported to nrfx v1.8.4 in used in SDK 17.0.0. Both API versions are available in nrfx v1.8.4 and later, you can switch between the APIs in compile-time with the preprocessor symbol NRFX_SAADC_API_V2. Some examples of the new API can be found in the nrfx GitHub wiki, but I also provided some examples for use with nRF5 SDK v 17.x.0 in this repository. 

    So am I right in thinking that in order to use the drivers that are not legacy I need to go and fix a load of library files that are part of the most recently provided SDK? Surely not -- that means that I'll have to do it for each future SDK version??

    I agree that legacy is not the best name for the "legacy driver APIs", integration may have been better. There is no real advantage in switching to the nrfx APIs when using nRF5 SDK, as the legacy layer will use nrfx driver in the bottom layer anyway. Most of the libraries in the SDK is also not migrated to use the nrfx APIs directly.

    Best regards,
    Jørgen

Reply
  • +1

    Hi,

    nrfx v2.x.x is not supported by nRF5 SDK, and will most likely not be supported in the future either. nRF5 SDK supports the nrfx 1.8.x branch, and this is the recommended use for nRF5 SDK. For other SDKs and RTOSes, like nRF Connect SDK, nrfx v2.x.x is supported.

    Regarding the nrfx_saadc driver, there is two APIs available (#1 - #2). The driver was totally rewritten to resolve a few issues. Initially, the new API was only supported in nRFx v2.x.x, but this API was backported to nrfx v1.8.4 in used in SDK 17.0.0. Both API versions are available in nrfx v1.8.4 and later, you can switch between the APIs in compile-time with the preprocessor symbol NRFX_SAADC_API_V2. Some examples of the new API can be found in the nrfx GitHub wiki, but I also provided some examples for use with nRF5 SDK v 17.x.0 in this repository. 

    So am I right in thinking that in order to use the drivers that are not legacy I need to go and fix a load of library files that are part of the most recently provided SDK? Surely not -- that means that I'll have to do it for each future SDK version??

    I agree that legacy is not the best name for the "legacy driver APIs", integration may have been better. There is no real advantage in switching to the nrfx APIs when using nRF5 SDK, as the legacy layer will use nrfx driver in the bottom layer anyway. Most of the libraries in the SDK is also not migrated to use the nrfx APIs directly.

    Best regards,
    Jørgen

Children
Related