Choosing between Zephyr ADC API and nrfx SAADC driver API
In nRF Connect SDK, there are two ways to interact with the SAADC peripheral:
- Using the Zephyr API.
- Using the nrfx drivers (nrfx SAADC API) directly.
The Zephyr ADC API is the preferred API to be used whenever the use-case can be solved properly using the Zephyr API. However, there are some use-cases where the Zephyr API has limitations, and the nrfx SAADC API could be considered. This section will describe the drawbacks of using nrfx SAADC driver directly and describe some use-cases where it would be relevant.
Advantages of Zephyr API
High portability – Zephyr driver implementations are written to be platform agnostic. If you are switching to another chip variant, chip family, or chip vendor, the Zephyr APIs should work without modifications, while the nrfx SAADC driver API could require major changes to port the functionality to a new platform.
Use Zephyr power management features – nrfx drivers are written to be OS agnostic and do not integrate any RTOS-specific power management features. While Zephyr drivers have been written to make use of and support automatic power management features in Zephyr, this must be handled manually in the application if using nrfx drivers.
nrfx SAADC use-cases
High sample rate
Some use cases require very fast sampling of the analog input(s). If each sample is triggered from software, this will cause many interrupts/wakeups of the CPU just to trigger the samples. The SAADC peripheral in nRF52/nRF53/nRF91 Series chips supports a maximum sample rate of 200 ksps, or 5us interval. Future chip variants may support even faster sample rates. It is impractical to trigger the sampling from software/CPU at such high sample rates, as this will take CPU time away from other running tasks in the application.
Precise sample interval
If you have a use case where you need to sample an analog input at a very precise interval or a specific point in time, triggering sampling from software might not be accurate enough in a single-core SoC running protocol stacks at high priority. If another interrupt/thread has a higher priority than the ADC sampling thread, the triggering of the sampling will be delayed until the higher priority task is done.
Both the above-mentioned use cases can be solved using the DPPI/PPI peripheral in Nordic chips. (D)PPI is signaling between peripherals implemented purely in hardware to trigger tasks when events occur, eliminating the need to involve the CPU to perform operations. Since the signaling is implemented in hardware, there is no interrupt delay or chance of being delayed by other higher-priority tasks. (D)PPI is a Nordic Semiconductor specific HW feature which there is no current support for in the Zephyr driver APIs.
The nrfx SAADC driver can be combined with nrfx (D)PPI driver in nRF Connect SDK to support the described use cases. In exercises 2 and 3, you will learn how to use the nrfx SAADC API in nRF Connect SDK.
The nrfx SAADC driver has two different operation modes:
The simple mode allows obtaining a single sample from each requested channel. The conversion can be done in a blocking or non-blocking manner. Sampling is initiated by a function call from software.
The advanced mode allows performing double-buffered conversions of arbitrary length. The conversions can be done in a blocking or non-blocking manner. The advanced mode can be configured to trigger sampling using an internal timer or externally (for example, by using the TIMER and/or the PPI/DPPI). The advanced mode supports double-buffering and can be configured to switch buffers externally using PPI channel. This is useful when requiring true continuous sampling without any delays by CPU to handle buffer switching.
Note
In the nRF Connect SDK, examples are available that demonstrate how to use the nrfx drivers directly for various peripherals.
These examples can be found here: <installation_path>\modules\hal\nordic\nrfx\samples.
In some scenarios, you may find yourself in a situation where you have no other option but to use the nrfx drivers directly. For instance, Zephyr RTOS, may not have certain functionalities implemented, like the I2C target (slave) API. In such cases, the only way to utilize these functionalities is by directly employing the nrfx TWIS driver.
However, in other scenarios, like when dealing with the ADC, as we have discussed, you have a choice. You can either use the nrfx drivers directly for absolute full control over the peripheral functionality, or you can opt for a more portable approach. This means you have to weigh the benefits of portability/automated power management against the advantages of having absolute control over the peripheral.
