ADC fastest channel sampling rate

[Omri Friedman]

I need to sample ADC channel at the fastest deterministic rate.

If i use burst mode with 3us acquisition time, do i get a sample exactly every 5us? 

does t(conv) is always 2us or does it vary?

should i use a timer instead of burst mode to get the rate predicted?

If yes - can i use timer that clocks every 5us when using t(acq)=3us? or can i go lower?

[Jørgen Holmefjord]

Hi,

How long sample time you get with BURST enabled will depend on the configuration of OVERSAMPLE register. From the SAADC peripheral documentation:

CH[n].CONFIG.BURST can be enabled to avoid setting SAMPLE task 2^OVERSAMPLE times. With BURST = 1 the ADC will sample the input 2^OVERSAMPLE times as fast as it can (actual timing: <(t_ACQ+t_CONV)×2^OVERSAMPLE). Thus, for the user it will just appear like the conversion took a bit longer time, but other than that, it is similar to one-shot mode. Scan mode can be combined with BURST=1, if burst is enabled on all channels.

If OVERSAMPLE is not enabled, enabling BURST mode will have no effect. If OVERSAMPLE is enabled, the sample time will be <(t_ACQ+t_CONV)×2^OVERSAMPLE

You would need a timer to trigger the SAMPLE task, regardeless of if BURTS mode is enabled or not. If you do OVERSAMPLE and BURST, you need to increase the triggering of SAMPLE task to the actual sample timing from above.

t_CONV is specified at typical <2µs, you cannot expect it to be lower than this, and it is without specs to sample more often.

Best regards,
Jørgen

[Jørgen Holmefjord]

Like I said, BURST will only work with OVERSAMPLE, and you will only get out the averaged sample in the buffer, not every sample.

You need to setup a timer to trigger sample every 5 µs, this is the fastest way to sample the channel 1000 times.

Typical <2 µs is what the specification say. I have never seen or heard about higher values. You should be fine with 5 µs sample interval.

Best regards,
Jørgen

[Omri Friedman]

I am using 3us SAADC sampling rate with double buffer EasyDMA.

The SAADC driver calls me back when one buffer is filled up by the EasyDMA.

Is it possible that during the software interrupt, when i need to call nrf_drv_saadc_buffer_convert to switch buffers, that 1 or 2 samples shall be missed?

In other words - is it a real HW double buffer where the EasyDMA automatic sampling into memory continuous while i am inside the interrupt? 

I saw that RESULT.MAXCNT and RESULT.PTR are updated within the software interrupt, so this made me think about a possible race conditions....

[Jørgen Holmefjord]

This is described in the SAADC peripheral documentation:

The RESULT.PTR register is double-buffered and it can be updated and prepared for the next START task immediately after the STARTED event is generated.

In the SAADC driver, the first buffer will be set when you call nrfx_saadc_buffer_convert. Then you call nrfx_saadc_buffer_convert the second time, the buffer will be stored in the second buffer pointer. The second buffer is set in the IRQ handler when a END event is received (NRF_SAADC_EVENT_END). The START task will be triggered when the new buffer is set, to prepare it for next event. If you need to set the new buffer before the END event is received (for instance when STARTED event is received), you need to modify the driver or setup SAADC using registers directly. This is typically not an issue in the driver as you will trigger the START task from the same interrupt where you set the second buffer. Note that some users have seen buffer-swap issues when sampling multiple channels and triggering SAMPLE task through PPI.

[Omri Friedman]

My concern is that when END event is received and i get an interrupt, by the time i trigger the START task i may miss real samples (assuming i am interrupted by the SD priority 0 interrupt that may delay my interrupt processing by up to 250us when i am connected via BLE). I am sampling every 5us.

I understand from the "buffer-swap issue" link above, that the solution is to do this: "Use PPI to trigger START task on an END event. This will avoid the delayed triggering og the START task due to a queued interrupt generated by the END event, but in the case of high sample frequency and long delays, it can cause your buffer to be overwritten before you are able to process the buffer. In case of using this solution, it is necessary to use double buffering and large enough buffers to avoid data loss."