ADC - how to consume fast samples while avoiding race conditions?

RE: ADC - how to consume fast samples while avoiding race conditions?

mikemike651 — Tue, 31 Aug 2021 16:09:07 GMT

Thank you Einar! The atomic functions might just be what I need.

RE: ADC - how to consume fast samples while avoiding race conditions?

Einar Thorsrud — Tue, 31 Aug 2021 08:47:07 GMT

Hi,

OK, now I see. This is not directly related to the SAADC driver, then. If you are only interested inthe very last sample and you want to do this simply and safely, perhaps you could stay with the buffer size you had (one sample for each channel in each buffer), and simply copy out to a variable which is not one of the two buffers in the event handler. This is a quite fast operation, so it should be OK to do this in the SAADC interrupt.

The above can be done atomically using the LDREX/STREX instructions, and the SDK has a helper library for that: nrf_atomic. IThat could be used direclty, but it is used to implement other modules as well, such as nrf_ringbuf. I am sure there are other methods as well, some may be better for your use case, but this gives an idea of the toolbox you have at hand.

RE: ADC - how to consume fast samples while avoiding race conditions?

mikemike651 — Mon, 30 Aug 2021 15:56:04 GMT

Thanks for your patience Einar, sure I'll try to explain.

With your suggestion I will have a dual buffer scheme that is updated every 100ms:

static nrf_saadc_value_t m_buffer_pool[2][ADC_NUM_SAMPLES_IN_BUFFER];

While the hardware updates index 0, the user can consume index 1, and vice-versa (the active buffer is marked by m_buffer_index in my code). My concern is that because the consumption is done asynchronously (it is unaware of when the last batch of fresh samples has arrived), it can happen at the end of the 100ms window just before the ISR fires with new samples.

In the code I posted, the ISR updates m_buffer_index, and I'm worried it will happen while the user is trying to access it (and the buffer), in the function adc_get_latest_values() which I posted originally.

What I'm trying to ask is, is there a software solution, say a FIFO, a ring buffer, or some synchronization trick, that can help with this potential issue?

Thanks again for your help.

RE: ADC - how to consume fast samples while avoiding race conditions?

Einar Thorsrud — Mon, 30 Aug 2021 15:42:03 GMT

Hi,

I am not sure I understand the context here. If you sample every 10 ms and use the buffer size I suggested, that means buffers swap every 100 ms (you can use lager buffers as well). And so, from you get the event/interrupt with the buffer filled you know it will take at least 100 ms (in this example) before any data can change. That should give you a lot of time to use this data, copy it somewhere or whatever you need to do before there is any risk of it being corrupted.

I do not see why disabling interrupts would be relevant in this situation, as we are not talking about short times here. So you are right it would not work, but also It does not seem relevant. Or perhaps I don't understand where you mean there is a race condition? If so, perhaps you can explain in more detail in that case?

RE: ADC - how to consume fast samples while avoiding race conditions?

mikemike651 — Mon, 30 Aug 2021 15:32:12 GMT

Thanks for your answer Einar.

Even if we use larger buffers, there is still the chance that while (asynchronously) reading the buffer that's not being currently used by hardware, a new ISR will kick in and change the buffer pointer. Are you aware of any software tricks that might help with that, or maybe have a code example that would show a guaranteed way to avoid a race condition?

Usually in such scenarios, disabling interrupts is a decent solution, but I read that in the nRF SDK it may mess up the SoftDevice stack (which in our case needs to be running while using the ADC).

Appreciate your help!

RE: ADC - how to consume fast samples while avoiding race conditions?

Einar Thorsrud — Mon, 30 Aug 2021 15:22:58 GMT

Hi,

In principle 10 ms should be enough time for most tasks. Do you have a rush to use the values from the SAADC? If you do not need the latest samples every 10 ms, then you could use larger buffers, so that you would not have to swap buffers every 10 ms. Lets say you use set ADC_NUM_SAMPLES_IN_BUFFER to (NUM_SAADC_CHANNELS * 10) that would give you more time to process the data before they are updated. (I just suggested 10 here, a different number might make more sense in your application).