[SAADC] Zephyr's SAADC Driver (DMA Design choices analysis)

RE: [SAADC] Zephyr's SAADC Driver (DMA Design choices analysis)

Kazi Afroza Sultana — Wed, 23 Jul 2025 14:52:33 GMT

Hello,

This should work for more than one channels as well: https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-6-analog-to-digital-converter-adc/topic/exercise-3-interfacing-with-adc-using-nrfx-drivers-and-timer-ppi/

RE: [SAADC] Zephyr's SAADC Driver (DMA Design choices analysis)

Pawel(embeddedsolutions.pl) — Thu, 10 Jul 2025 09:48:35 GMT

Hi again,

I am back here to share thoughts and decisions I finally made.

I ended up with implementing NRFX_SAADC_PPI driver compatible with Zephyr's ADC API.
The driver utilizes the NRFX_SAADC, NRFX_TIMER and NRFX_GPPI APIs.
SAADC works in scan mode with double-buffering. All defined channels are sampled with specified frequency.
Users of the driver pull samples associated with requested channel/channels.

It is important to know which timer instances are used by other components of the system.
On my side it turned out that I was using the same timer instance as BLE controller, so I had to change it to different one.
Next challenge I encountered was validation of acquisition time, resolution, oversampling during build-time via preprocessor macros.
I failed at this point and the validation is done on runtime at initialization.

Thank you all for pointing me into right direction

RE: [SAADC] Zephyr's SAADC Driver (DMA Design choices analysis)

STE — Thu, 12 Jun 2025 14:37:04 GMT

Dear Sultana,
could you please let me know if by using same approach, then double buffering and PPI, instead to sample one single ADC channel as into example it is possible to sample more channels in sequence? My need is to take samples every 5ms of 4 analog input channels for a total of 400 samples for each channel, so the final buffer will be equal to 1600 samples, in such way every 2 seconds I should catch an event and then retrieve all the 1600 samples (that at the end will give to me 400 samples for each channel).

Thanks for your suggest, best regards.

RE: [SAADC] Zephyr's SAADC Driver (DMA Design choices analysis)

Turbo J — Fri, 16 May 2025 09:51:22 GMT

I don't think you can reliably hit that tiny window with the BTLE radio in operation. Keep in mind that the radio (softdevice) code has to run at the highest priority and could thus preempt ADC code.

Also seems like its the solution which would require more development work and not less to me.

Edit: You also wanted to use a dedicated chip in case you intend to use Li-Ion or LiPo battery chemistry. These need charging ICs anyway and you can get those that can tell you the voltage (and battery percent) via a digital bus, typically I²C.

No, I don't think you could run your code on a CR2032 - these won't provide enough power to run an ADC this fast.

RE: [SAADC] Zephyr's SAADC Driver (DMA Design choices analysis)

Pawel(embeddedsolutions.pl) — Fri, 16 May 2025 09:07:04 GMT

I understand your concerns but there are no ideal solutions, everything comes with a cost.

By doing that in the way you proposed, we significantly reduce the maximum amount of samples collected for single channel, reducing the capturing window time (RESULT.MAXCNT / channels used)

Battery measurement is something that could be called even once per few minutes.

If maximum allowed frequency is going to be 16.666kHz there is ~60us in between sampling.
Do you feel that it is impossible to re-run the ADC with different configuration in that time?

I got your point clearly and I am partly convinced, I would like to avoid unnecessary work at this point, that is why I investigate alternative methods

RE: [SAADC] Zephyr's SAADC Driver (DMA Design choices analysis)

Turbo J — Fri, 16 May 2025 07:13:28 GMT

Terrible idea.

The problem is that you will likely interrupt the "fast" ADC long enough that you create "gaps" where you miss sampling points. That is usually not acceptable for most applications.

The solution is to simply measure all ADC channels at the high frequency. Then either throw away the data that you don't need or you take an average value and use that for the "slower" channels.

This way you have constant time between all sampling points - most applications prefer this method.

RE: [SAADC] Zephyr's SAADC Driver (DMA Design choices analysis)

Pawel(embeddedsolutions.pl) — Thu, 15 May 2025 12:14:47 GMT

Hi,

Thank you for bringing up this Nordic academy exercise.

As far as I understood the code there, I believe it is suitable for the scenarios where the SAADC peripheral is used only for single purpose.

What I encountered is that I need to sample the ADC channels for different purposes e.g Audio + Battery voltage and these two cases are far far away from being similar.

What I have done so far is bringing up the HAL NRF API and use it together with Zephyr's ADC ASYNC API.
That make my code Nordic specific but I am totally fine with it.

static int read_continuous_mode(const struct device *dev)
{
	const struct amic_config *config = dev->config;
	struct amic_data *data = dev->data;

	/*
	 * Continuous mode requires bringing up the underlying HAL SAADC NRF API.
	 * The Zephyr's SAADC driver is not able to handle the continuous mode.
	 */

	/* Disable interrupts to not be preempted before calling the `adc_read_async` */
	nrf_saadc_int_disable(NRF_SAADC, NRF_SAADC_INT_END | NRF_SAADC_INT_CALIBRATEDONE);

	/* Utilize the Zephyr's ADC async API to set the resolution and oversampling configuration
	 */
	const int ret = adc_read_async(config->port.dev, &data->sequence, NULL);
	if (ret) {
		LOG_ERR("Can't read adc: %d", ret);
		return ret;
	}

	/* Immediately STOP the SAADC sampling invoked by the `adc_read_async` */
	nrf_saadc_task_trigger(NRF_SAADC, NRF_SAADC_TASK_STOP);

	/* Disable SAADC sampling to modify the configuration safely */
	nrf_saadc_disable(NRF_SAADC);

	/* Prepare buffer for SAADC DMA Continuous mode*/
	nrf_saadc_buffer_init(NRF_SAADC, (nrf_saadc_value_t *)data->sequence.buffer,
			      config->samples_num);

	/* Enable continuous mode with calculated `data->interval_us` */
	nrf_saadc_continuous_mode_enable(NRF_SAADC,
					 (SAMPLERATE_FREQUENCY_RATIO * data->interval_us));

	/* Clear the `NRF_SAADC_EVENT_END` event to ensure clear state */
	nrf_saadc_event_clear(NRF_SAADC, NRF_SAADC_EVENT_END);
	/* Enable back the interrupts handled internally by the Zephyr's ADC driver. On
	 * `NRF_SAADC_EVENT_END` event the `adc_sequence_callback_handler` is called
	 */
	nrf_saadc_int_enable(NRF_SAADC, NRF_SAADC_INT_END | NRF_SAADC_INT_CALIBRATEDONE);

	/* Start sampling in continuous mode */
	nrf_saadc_enable(NRF_SAADC);
	nrf_saadc_task_trigger(NRF_SAADC, NRF_SAADC_TASK_START);
	nrf_saadc_task_trigger(NRF_SAADC, NRF_SAADC_TASK_SAMPLE);

	LOG_DBG("ADC continuous mode requested");
	return 0;
}

The next challenge I believe is to synchronize the calls of functions which use the SAADC so they won't interrupt with each other.
That is not because I brought up the NRF HAL API but because ADC_ASYNC API is in use.

Do you have any idea how this can be achievable? or maybe it is already handled by the ADC driver?

RE: [SAADC] Zephyr's SAADC Driver (DMA Design choices analysis)

Kazi Afroza Sultana — Mon, 05 May 2025 10:42:04 GMT

Hello,

For implementing a high-frequency ADC solution you may consider using TIMER and PPI/DPPI to trigger ADC sampling at precise intervals without CPU involvement. This previous case (+) Using nRF52832 ADC for audio encoding - Nordic Q&A - Nordic DevZone - Nordic DevZone described about the implementation of TIMER and PPI.

For continuous sampling, you can implement double buffering also.

/* STEP 4.1 - Define the buffer size for the SAADC */
#define SAADC_BUFFER_SIZE 8000

/* STEP 4.2 - Declare the buffers for the SAADC */
static int16_t saadc_sample_buffer[2][SAADC_BUFFER_SIZE];
static uint32_t saadc_current_buffer = 0;

static void saadc_event_handler(nrfx_saadc_evt_t const * p_event)
{
    nrfx_err_t err;
    switch (p_event->type)
    {
        case NRFX_SAADC_EVT_READY:
            /* STEP 5.1 - Buffer is ready, timer (and sampling) can be started. */
            nrfx_timer_enable(&timer_instance);
            break;
            
        case NRFX_SAADC_EVT_BUF_REQ:
            /* STEP 5.2 - Set up the next available buffer. Alternate between buffer 0
             * and 1 */
            err = nrfx_saadc_buffer_set(
                saadc_sample_buffer[(saadc_current_buffer++) % 2], SAADC_BUFFER_SIZE);
            if (err != NRFX_SUCCESS) {
                LOG_ERR("nrfx_saadc_buffer_set error: %08x", err);
                return;
            }
            break;

        case NRFX_SAADC_EVT_DONE:
            /* STEP 5.3 - Buffer has been filled. Do something with the data */
            int64_t average = 0;
            int16_t max = INT16_MIN;
            int16_t min = INT16_MAX;
            int16_t current_value;
            
            for (int i = 0; i < p_event->data.done.size; i++) {
                current_value = ((int16_t *)(p_event->data.done.p_buffer))[i];
                average += current_value;
                if (current_value > max) {
                    max = current_value;
                }
                if (current_value < min) {
                    min = current_value;
                }
            }
            average = average / p_event->data.done.size;
            LOG_INF("SAADC buffer at 0x%x filled with %d samples",
                    (uint32_t)p_event->data.done.p_buffer, p_event->data.done.size);
            LOG_INF("AVG=%d, MIN=%d, MAX=%d", (int16_t)average, min, max);
            break;
            
        default:
            LOG_INF("Unhandled SAADC evt %d", p_event->type);
            break;
    }
}

How to set up double-buffering for continuous SAADC sampling, including the use of two buffers, the event handler, and the use of TIMER and (D)PPI for precise sampling intervals.

You can find the original source and detailed step-by-step instructions here: https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-6-analog-to-digital-converter-adc/topic/exercise-3-interfacing-with-adc-using-nrfx-drivers-and-timer-ppi/

RE: [SAADC] Zephyr's SAADC Driver (DMA Design choices analysis)

Pawel(embeddedsolutions.pl) — Fri, 02 May 2025 12:19:18 GMT

Thanks, that explains much.

Would it be possible to use custom ADC driver together with Zephyr's one?
Of course with proper synchronization.

RE: [SAADC] Zephyr's SAADC Driver (DMA Design choices analysis)

Turbo J — Thu, 01 May 2025 12:00:18 GMT

The ADC drivers are written with low power usage in mind and not to be compatible to audio frequency.

I would recommend not to fork the driver but to write a new one from scratch, possibly even without the NRFX hardware abstraction layer, as I have not check if this layer allows high sampling frequencies either.

The idea is to do something similar to the audio/I²S drivers, particularly how these handle lots of data with the k_mem_slab_ stuff.