tests: drivers: adc: adc_dma: increase sampling interval for MCUX ADC16

[danieldegrasse]

tests: drivers: adc: adc_dma: increase sampling interval for MCUX ADC16

Increase hardware sampling interval to 30ms for MCUX ADC16. The ADC
callback in the repeated_samplings test takes roughly 27ms to execute,
so a sampling frequency of this interval still allows the ADC test to
verify the ADC is being sampled at a given interval, while avoiding the
pitfalls that result from a kernel timer shorter than the duration the
ADC callback takes to run.

Fixes #58467

[danieldegrasse]

@heinwessels I'd like to understand the changes in #52965 a bit better- particularly the change to use SAMPLE_INTERVAL_US here: https://github.com/zephyrproject-rtos/zephyr/pull/56104/files#diff-0f2bf1897d5421331070f482911ef31bdf0fe065480deeeff59f0065c5ed6554R294. Using SAMPLE_INTERVAL_US, particularly with an interval shorter than (1/CONFIG_SYS_CLOCK_TICKS_PER_SEC), will result in a kernel timer that fires sporadically.

Moreover, on the FRDM-K64F the repeated_samplings_callback in the ADC test takes ~27ms to execute. So for any kernel timer interval less than 27ms, the timer may fire before the callback completes. This will result in the EBUSY error for the adc_read call, as the ctx->sampling_requested variable the ADC timer expiration handler checks against is not decremented until the user's ADC callback completes.

However, if the sampling interval is set to 0 (as you did in your initial PR #52965, the ADC context subsystem will correctly attempt to sample as soon as the ADC driver indicates a previous sample has completed, and will not start a kernel timer.

Is there a particular reason you changed the interval back to SAMPLE_INTERVAL_US?

[heinwessels]

@heinwessels I'd like to understand the changes in #52965 a bit better- particularly the change to use SAMPLE_INTERVAL_US here: https://github.com/zephyrproject-rtos/zephyr/pull/56104/files#diff-0f2bf1897d5421331070f482911ef31bdf0fe065480deeeff59f0065c5ed6554R294. Using SAMPLE_INTERVAL_US, particularly with an interval shorter than (1/CONFIG_SYS_CLOCK_TICKS_PER_SEC), will result in a kernel timer that fires sporadically.

Moreover, on the FRDM-K64F the repeated_samplings_callback in the ADC test takes ~27ms to execute. So for any kernel timer interval less than 27ms, the timer may fire before the callback completes. This will result in the EBUSY error for the adc_read call, as the ctx->sampling_requested variable the ADC timer expiration handler checks against is not decremented until the user's ADC callback completes.

However, if the sampling interval is set to 0 (as you did in your initial PR #52965, the ADC context subsystem will correctly attempt to sample as soon as the ADC driver indicates a previous sample has completed, and will not start a kernel timer.

Is there a particular reason you changed the interval back to SAMPLE_INTERVAL_US?

As mentioned in the commit message, I changed it back due to #56070. The reason is that I will simply reverting things back to how I found it, because it apparently caused issues. I don't work with NXP, nor have devices available, so I'm not really sure which the right approach is. Even though I do believe the sampling_interval_us should be 0, as this PR is doing.

[danieldegrasse]

After discussing with @hakehuang, I have increased the sampling interval to 30ms. This way the test still verifies that the ADC hardware sampling is triggered on the timer interval, but we do not run into the pitfall of using a kernel timer shorter in duration than the time the ADC callback takes to execute (27ms on the FRDM-K64F)