Hi, had to modify this file
SDK nRF5_SDK_15.3.0_59ac345 in file apply_old_config.h
line 818
(SPI_ENABLED && (NRFX_SPIM0_ENABLED || NRFX_SPIM1_ENABLED || NRFX_SPIM2_ENABLED))
Should be
(SPI_ENABLED && (NRFX_SPIM0_ENABLED || NRFX_SPIM1_ENABLED || NRFX_SPIM2_ENABLED || NRFX_SPIM3_ENABLED))
Hi,
apply_old_config.h is intended only for use with legacy drivers. SPIM3 is not supported by the legacy driver. If you want to use SPIM3, I would recommend completely removing the legacy SPI_ENABLE config from sdk_config.h and configure the nrfx_spim driver directly using NRFX_SPIM_ENABLE configs.
Best regards,
Jørgen
I think you misunderstood Einars answer. He is not saying that you should not use nrfx API, only that it is not necessarily required and that you should take care when using it together with the softdevice (as nrfx does not use softdevice APIs for clocks etc.) The softdevice does not use app_timer, app_timer is a SDK library. App_timer does not depend on the legacy driver either, as it use its own custom RTC driver.
Einar also told you that you can use nrfx driver for SPIM:
Einar Thorsrud said:
Nicholas Lee said:
How "exactly" are we supposed to implement the SPIM, PPI, GPIOTE, and Timer call-back functionality from our original project if we aren't allowed to use the NRFX drivers??
Provided you stay away from TIMER0 and RTC0 neither of those peripherals have any conflict with the SoftDevice, so you can use the nrfx drivers out of the box. However, you will see that the higher level libraries we provide for SPI transactions. You must remember to use the SoftDevice API (or nrf_drv_timer) if you need to interact with the clocks.
Best regards,
Jørgen
Einar said the following perfectly clear things against using NRFX directly:
"In fact, nrfx is a low-level driver layer, and for instance it does not handle the SoftDevice dependencies."
and
"Therefore using nrfx directly is not recommended and does not provide any benefits."
and
"I am painfully aware of the documentation suggesting that you use the nrfx API direclty. It has been reported internally and will hopefully be fixed at some point."
Starting with the "Blinky app", I found was completely unable to use the SPIM3 module using nrf libraries, as that hardware does not seem to be supported, (i.e. NRFX_SPIM3_ENABLED is missing)
Once an app contains Bluetooth and the SoftCore, then the app_timer gets included which ties the code to the legacy configuration and the file "apply_old_config.h" gets included.
By default, sdk_config.h includes a definition of SPI_ENABLED, and whether this is set to 0 or 1, the apply_old_config.h file undefines NRFX_SPI_ENABLED, and that prevents customers from using the NRFX module required to actually use the new SPIM3 hardware.
I consider the use of "#ifdef" in the apply_old_config.h to be a software bug that needs fixing.
This issue was reported here 10 months ago: https://devzone.nordicsemi.com/f/nordic-q-a/33944/nrfx_spi-instantiation-fails-using-nrfx-why/142878#142878
This whole issue of two competing sets of drivers, and the massive over-use of macros is a complete mess, and it makes debugging a nightmare.
You are over-generalizing his statements. This only relates to drivers that can conflict with softdevice resource requirements, like CLOCK, POWER and RNG, and if you are using libraries that depend on legacy API. For any other peripherals, there should be no issues with using nrfx API.
SPIM3 is only supported in nrfx_spim driver, and an example is available in the SDK.
Nicholas Lee said:This whole issue of two competing sets of drivers, and the massive over-use of macros is a complete mess, and it makes debugging a nightmare.
The nrfx and legacy APIs should not be considered "competing sets", the low level drivers was taken out of nRF5 SDK and put into a separate module to allow easy integration with 3rd party software (RTOS'es, etc), and to have a common driver implementation for all Nordic products (nRF5 SDK, nRF Connect SDK for nRF91, etc.). The integration with the existing nRF5 SDK is not trivial, as the legacy drivers had closer integration with the softdevice. This is the reason that the legacy layer have been kept, to allow existing projects to continue using the legacy drivers.
You are over-generalizing his statements. This only relates to drivers that can conflict with softdevice resource requirements, like CLOCK, POWER and RNG, and if you are using libraries that depend on legacy API. For any other peripherals, there should be no issues with using nrfx API.
SPIM3 is only supported in nrfx_spim driver, and an example is available in the SDK.
Nicholas Lee said:This whole issue of two competing sets of drivers, and the massive over-use of macros is a complete mess, and it makes debugging a nightmare.
The nrfx and legacy APIs should not be considered "competing sets", the low level drivers was taken out of nRF5 SDK and put into a separate module to allow easy integration with 3rd party software (RTOS'es, etc), and to have a common driver implementation for all Nordic products (nRF5 SDK, nRF Connect SDK for nRF91, etc.). The integration with the existing nRF5 SDK is not trivial, as the legacy drivers had closer integration with the softdevice. This is the reason that the legacy layer have been kept, to allow existing projects to continue using the legacy drivers.
Please try and take some of these constructive criticisms on-board and show some sympathy rather than being defensive, as we both want Nordic's customers (i.e. product designers) to have an improved experience and to get products to market in a timely manner.
1) I conveyed to you the understanding I had been given, by virtue of cutting-and-pasted direct quotes from your own support engineer. The problem is that customers are getting mixed messages about how to use the various drivers and libraries you provide.It is very confusing, and the documentation is now fragmented.
2) There are no clear developer guides available, just a few example projects which don't contain any explanatory code comments or associated text documents to explain how they work in plain English. Customers are left to reverse-engineer the design-intent and meaning from the code, which is a slow, frustrating, and very expensive process. As a business owner I hate wasting money, especially mine!
3) Obviously I know that SPIM3 is only supported in nrfx_spim, as I already told you that. The nrfx_spim gets disabled by default when starting from the "nordic blinky" example project. Only by hacking the sdk_config.h file can this be worked-around.
4) "apply_old_config.h" disables access to the NRFX drivers and enables the SPI Libraries which implement a sub-set of the same functionality. To your customers, that looks a lot like you have two "competing sets" of drivers, even if you say they aren't competing.
5) I would much rather use purely the new NRFX drivers, but this doesn't seem to be possible, as when customers include the SoftDevice, that also seems to automatically includes translation layers for legacy code I really don't want, such as the "apply_old_config.h" file, and the app_timer and its legacy includes, and probably cludges like nrfx_glue.h
