SAADC nrfx very slow with SDK 17.1.0 on nRF52832

RE: SAADC nrfx very slow with SDK 17.1.0 on nRF52832

Karl Ylvisaker — Thu, 12 Jan 2023 08:59:45 GMT

Hello RVM,

[quote user="RMV"]Thanks for your responses.[/quote]

No problem at all, I am happy to help! :)

[quote user="RMV"]What should be the value of the 'size' parameter passed in to nrfx_saadc_buffer_convert()?[/quote]

The size parameter should be the size of the buffer that you are providing in the first argument. A larger buffer will let the SAADC sample longer before needing the CPU to process the buffer. I.e if you have a buffer size of 2 then the CPU will have to wake up and process the buffer every time you perform a single sample of 2 channels, while if your buffer size if 100 it will only need to wake up every 50th sampling to process the buffer.

[quote user="RMV"]In other words do I need to use a large enough buffer that maps ALL 8 CHANNELS to unique indexes in the buffer array?[/quote]

No, only the enabled channels will provide an output. The samples will be stored like described in this figure.

[quote user="RMV"]My initial observation was with the BLE broadcasting continuously. When I disabled the BLE broadcast (I still needed to enable the BLE SD because without it the RTC did not advance) I did not see any noticeable changes in the time required to complete the capture.[/quote]

That sounds reasonable - if it was BLE activity keeping the CPU from capturing the RTC count it would be nowhere 500-700 ms in length, so there is likely something else playing into this.
Is this the only other thing happening in your application?

Best regards,
Karl

RE: SAADC nrfx very slow with SDK 17.1.0 on nRF52832

RVM — Wed, 11 Jan 2023 18:39:22 GMT

Hi Karl,

Thanks for your responses. I am definitely inclined to get the PPI based solution to work for us.

What should be the value of the 'size' parameter passed in to nrfx_saadc_buffer_convert()?
I am sampling channels 0 and 1 (in either 10-bit or 12-bit range -- will chose at a later date).
And what exactly is the correlation between the buffer address (i.e. array index) and the channel I am trying to sample?
Does the index depend on the actual channel number itself (i.e. does channel 0 map to index 0, etc.)?
In other words do I need to use a large enough buffer that maps ALL 8 CHANNELS to unique indexes in the buffer array?

Regarding your question about what else is going on: My initial observation was with the BLE broadcasting continuously. When I disabled the BLE broadcast (I still needed to enable the BLE SD because without it the RTC did not advance) I did not see any noticeable changes in the time required to complete the capture.

Thanks

RVM

RE: SAADC nrfx very slow with SDK 17.1.0 on nRF52832

Karl Ylvisaker — Wed, 11 Jan 2023 07:33:09 GMT

Hello RMV,

[quote user=""]I am using software triggered task to sample the two channels in scan mode. [/quote]

When you say software triggered do you mean that the sampling is triggered by the CPU, such as through a call to nrfx_saadc_sample?
If so, the sampling could be delayed in the case that the CPU is busy processing a higher level interrupt when the sampling should have been triggered.

If your application requires that the samples are collected periodically with high accuracy you should instead use the PPI + easyDMA approach that you mention, to trigger the samplings, but connecting the SAADC SAMPLE task to your periodic TIMER CAPTURE event, so that the sampling will be triggered immediately when the TIMER CAPTURE event is generated, completely without CPU intervention.
This could also reduce your power consumption in the case that you are sampling at a high frequency and have to wake the CPU up to trigger these samples.
If you are to switch to the PPI based sample triggering you could take a look at this example as a reference, to see how it could be done.

[quote user=""]I am observing the value returned by app_timer_cnt() before and after the sample task but I am observing that inspite of configuring an acquisition time of around 3uS, the task takes about 500 mS (yes, 500 milli-seconds) to complete. Increasing the acquisition time to around 10 uS results in the task completion time fo around 700 mS.[/quote]

Using the app_timer_cnt to measure things in the µs is not the best approach, both due to the resolution of the RTC but also due to the fact that the app_timer_cnt needs CPU intervention to do a capture, which could be delayed if the CPU is pulled away to a higher priority task - making it look like the operation you are trying to measure took much longer than expected.
Nevertheless, 500 ms is still an incredibly long time. Could you share the snippet of code in which this measurement was taken? Could you also detail what else is going on in your application at the time of sampling?

Best regards,
Karl