SAADC - triggering SAMPLE task while sampling is still in progress

[KWolfe81]

I am using the SAADDC in continuous mode with a PPI event triggering the SAADC's sample task.  This works perfectly fine.  It would be convenient to occasionally trigger a sample manually by calling nrf_saadc_task_trigger(NRF_SAADC, NRF_SAADC_TASK_SAMPLE).  There would be no coordination/scheduling between the PPI event and the manual trigger. What are the implications of triggering the SAMPLE task while a conversion is actively in progress?

[Karl Ylvisaker]

Hello,

Could you elaborate some more on the sampling you are currently using the SAADC with PPI for, like the frequency of this sampling? Are you just sampling a single channel, or are you using the SAADC in scan mode? How big of a SAADC buffer are you suing? Will there be any way for you to ensure that you do not trigger the 'manual' sampling at the same time as a PPI triggered sampling?

I am also interested in hearing more about why you would like to perform a manual sampling inbetween the PPI samples to better be able to advise you on this.

What are the implications of triggering the SAMPLE task while a conversion is actively in progress?

In the case that the manual sampling always is triggered between the PPI samplings (so that the PPI triggered samples have sufficient time to complete as well), the main implication would be that you suddenly have an additional sample in your buffer that you need to account for.

Best regards,
Karl

[KWolfe81]

Karl Ylvisaker said:

In the case that the manual sampling always is triggered between the PPI samplings (so that the PPI triggered samples have sufficient time to complete as well),

I am specifically asking about the case when the manual sampling is triggered during the PPI sampling, not between.  I can handle any buffering and interrupt concerns so long as I can clearly understand the hardware's behavior in such a case.  Would another conversion immediately begin after the first one is completed?  Would the second trigger get ignored?  Would the first conversion get interrupted and restarted?

My specific use case: I have 5 analog channels I need to sample.  4 of the channels need to get sampled once every BLE connection interval.  The 5th channel is used for device's state of health and only needs to get sampled once every few seconds but needs to happen regardless of whether the radio is connected or not.  My approach is to sample all 5 channels on each ADC 'sample' task (scan mode), have the wireless application task connect a radio event via PPI to the SAADC, and have the system state application task periodically issue the manual trigger whenever it requires an ADC as well.  

In the ideal case, there would be no need for coordination between the wireless and system state tasks.  Yes, I could come up with ways to communicate between tasks, and only issue manual ADC triggering when the wireless events aren't being generated but as a general design philosophy, the less entangled and complicated the code can be the better.  I'd rather handle this at the hardware interface layer.

[Karl Ylvisaker]

Hello,

KWolfe81 said:

I am specifically asking about the case when the manual sampling is triggered during the PPI sampling, not between.  I can handle any buffering and interrupt concerns so long as I can clearly understand the hardware's behavior in such a case.  Would another conversion immediately begin after the first one is completed?  Would the second trigger get ignored?  Would the first conversion get interrupted and restarted?

I must begin the answer by saying that this is not something that we recommend doing, since the behavior is undefined when triggering another SAMPLE task before the previous EVENTS_RESULTDONE have been generated.
That disclaimer being said, if you manually trigger the SAMPLE task through the CPU using nrf_saadc_task_trigger at the same time that it is triggered through PPI I would expect the second of these calls to be ignored since the task is already triggered.

The documentation reads:

Care shall be taken to ensure that the sample rate fulfils the following criteria, depending on how many channels are active:

f_SAMPLE < 1/[t_ACQ + t_conv]

I am not sure what you should expect if you are able to set the SAMPLE task again in the time between it is cleared by the hardware, and the EVENTS_RESULTDONE is generated.

KWolfe81 said:

My specific use case: I have 5 analog channels I need to sample.  4 of the channels need to get sampled once every BLE connection interval.  The 5th channel is used for device's state of health and only needs to get sampled once every few seconds but needs to happen regardless of whether the radio is connected or not.  My approach is to sample all 5 channels on each ADC 'sample' task (scan mode), have the wireless application task connect a radio event via PPI to the SAADC, and have the system state application task periodically issue the manual trigger whenever it requires an ADC as well.  

Thank you for elaborating, this is very helpful for me to know.
If you are already sampling all 5 channels is the issue here that your 'device health' sampling must happen at a very particular time, or is the issue primarily to make sure that the device health is sampled regardless of whether the device is in a connection or not?
In case of the latter you could perhaps instead have a conditional on whether or not the device is in a connection or not instead of potentially getting into undefined behavior with the SAADC.

Best regards,
Karl

[KWolfe81]

Karl Ylvisaker said:

the issue primarily to make sure that the device health is sampled regardless of whether the device is in a connection or not?

That.  OK, if the behavior is undefined, I'll put the protections in.  Messier than not having to do anything, but c'est la vie.  Thanks!