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

migrating from nrf_drv_spi to nrfx_spi

gauthamranganathan

Hello, 

I am trying to migrate to nrfx drivers in my project. Currently using SDK15.2 and nrf52840. I have 2 SPI peripherals in my application. One being an SD card and the other is an ECG sensor by maxim. I am using the SD card library in the nordic SDK. I understand that the there is a dependency of this library with nrf_drv_spi drivers. I  want to know a couple of things here. 

1. Can i have one instance of SPI running with legacy SPI driver (for SD card library) and another with nrfx_drivers?

2. Is there any updated version of the SD card library using nrfx drivers?

3. Are there any issues/bugs associated with nrf_drv_spi library?

4. Would it be advisable for me to try and migrate the SD card library?

Thank you. 

Parents
  • 0

    Hi,

    First, I would like to say that I cannot see any good reason for migrating to the nrfx API instead of using the legacy API. For the SPIM driver, all the API changes are handled by the preprocessor, so you will not see any benefit of migrating (essentially it is a bit of work with no return). In other cases, the nrf_drv_* is a higher level than nRFx and is needed (for instance for peripherals which are protected by the SoftDevice). Therefore, the term "legacy API" used in the SDK documentation is somewhat misleading. There is no good reason for moving away from it, and there will probably never be an nRF5 SDK where the examples use nrfx API directly.

    Now, for the specific questions: 

    1. Can i have one instance of SPI running with legacy SPI driver (for SD card library) and another with nrfx_drivers?

     Yes, that is no problem. It is essentially the same driver after all, but with some macro magic for providing the "legacy" API.

    2. Is there any updated version of the SD card library using nrfx drivers?

     No.

    3. Are there any issues/bugs associated with nrf_drv_spi library?

     No. At least none that differ from nrfx, as it is the same implementation for SPIM in SDK 15.x.

    4. Would it be advisable for me to try and migrate the SD card library?

    No.

  • 0 in reply to Einar Thorsrud

    Thank you for your reply Einar Thorsrud. I have a few more questions on this, It would be of great help if you could answer them. 

    I am currently not using the SPIM driver. I am using the SPI driver as I am not using EasyDMA. 

    It's unusual that there is a guide to migrate to nrfx* on the Nordic DocLib and I am unable to find all the information you just said there. Additionally, could you tell me why there is a nrfx_spi driver and nrf_drv_spi as there are macros taking care of this in the pre processor stage.

    Is there any difference between them at all? (lower HEX size? I am assuming there cannot be any functional difference as they are both adhering to SPI protocol on the bus lines)

    Is this the case with the rest of the drivers as well? Earlier, I experienced some issues in the TWI legacy drivers as it wasn't supporting the transfer of larger data packet (greater than 256 bytes). Since I didn't have the time to get into all the changes made in the drivers of all peripherals, I decided to migrate to the latest drivers to avoid any possible bugs and possible end of support from Nordic.

    Will Nordic ever terminate support for projects using the legacy layers?

    thank you. 

      

Reply
  • 0 in reply to Einar Thorsrud

    Thank you for your reply Einar Thorsrud. I have a few more questions on this, It would be of great help if you could answer them. 

    I am currently not using the SPIM driver. I am using the SPI driver as I am not using EasyDMA. 

    It's unusual that there is a guide to migrate to nrfx* on the Nordic DocLib and I am unable to find all the information you just said there. Additionally, could you tell me why there is a nrfx_spi driver and nrf_drv_spi as there are macros taking care of this in the pre processor stage.

    Is there any difference between them at all? (lower HEX size? I am assuming there cannot be any functional difference as they are both adhering to SPI protocol on the bus lines)

    Is this the case with the rest of the drivers as well? Earlier, I experienced some issues in the TWI legacy drivers as it wasn't supporting the transfer of larger data packet (greater than 256 bytes). Since I didn't have the time to get into all the changes made in the drivers of all peripherals, I decided to migrate to the latest drivers to avoid any possible bugs and possible end of support from Nordic.

    Will Nordic ever terminate support for projects using the legacy layers?

    thank you. 

      

Children
  • +1 in reply to gauthamranganathan

    Hi,

    gauthamranganathan said:
    I am currently not using the SPIM driver. I am using the SPI driver as I am not using EasyDMA. 

    Everything we discuss here is equally valid for the SPI and SPIM peripheral drivers.

    gauthamranganathan said:
    It's unusual that there is a guide to migrate to nrfx* on the Nordic DocLib and I am unable to find all the information you just said there.

     Yes, the migration guide for nrfx drivers describes how you can migrate to nrfx. However, I advise against it as there is no good reason for doing so in this case.

    gauthamranganathan said:
    Additionally, could you tell me why there is a nrfx_spi driver and nrf_drv_spi as there are macros taking care of this in the pre processor stage.

    The actual implementation is in nrfx (nrfx_spi.c for the peripheral without DMA). The nrf_drv_spi.c is virtually empty, because all it does is call underlying nrfx drivers (either SPI or SPIM).

    gauthamranganathan said:
    Is there any difference between them at all?

    No. For some drives there are minor differences, but for SPI and SPIM the result is the same. The preprocessor handles almost everything, and optimization should do the rest.

    gauthamranganathan said:
    Is this the case with the rest of the drivers as well? Earlier, I experienced some issues in the TWI legacy drivers as it wasn't supporting the transfer of larger data packet (greater than 256 bytes).

    Generally, yes. However for some drivers using nrfx is more hassle, as it is a bit lower-level (no concept of SoftDevice etc.). There might have been problems with DMA transfers larger than 256 bytes due to historic reasons (this is the limitation on the nRF52832, though longer transfers are supported on nrF52840 and nRF52810).

    gauthamranganathan said:
    Since I didn't have the time to get into all the changes made in the drivers of all peripherals, I decided to migrate to the latest drivers to avoid any possible bugs and possible end of support from Nordic.

    The SDK is tested with the legacy API layer, which as mentioned use nrfx underneath. I do not see any reason for believing that you will get better quality by skipping the legacy layer (perhaps the opposite, if you make some mistakes in your migration).

    gauthamranganathan said:
    Will Nordic ever terminate support for projects using the legacy layers?

    I cannot make any promises for the future, but at this point there is no reason to believe that the nRF5 SDK will ever use the nrfx drivers directly. As a parallel you can look at the Zephyr RTOS project, which use nrfx for low level drivers on Nordic devices. However there as well, the application developer is supposed to use a higher level driver API, and not nrfx directly. In fact, this is the main reason nrfx was created in the first place - make a low-level driver layer that can be used by different higher layer driver APIs.

Related