cpu/sam0_common/periph/dma: add ADC sampling via DMA by fabian18 · Pull Request #22626 · RIOT-OS/RIOT

fabian18 · 2026-08-26T12:41:43Z

Contribution description

Implement ADC sampling via DMA, using circular DMA descriptors as in #22261.

Testing procedure

BOARD=same54-xpro make -C test/periph/adc_dma
The test application samples ADC at most possible speed for a given timespan.

Issues/PRs references

Declaration of AI-Tools / LLMs usage:

AI-Tools / LLMs that were used are:

Gemini added the DMAC_BTCTRL_BLOCKACT_INT

The `dac_set()` API says > The value is always given as 16-bit value and is internally scaled to the > actual resolution that the DAC unit provides (e.g. 12-bit). We didn't do that scaling before - enable it even though it breaks existing users.

…utput

…nce" This reverts commit 5765ebb.

crasbe · 2026-08-26T13:11:04Z

This includes the previous two PRs, right?

fabian18 · 2026-08-26T14:24:15Z

does only depend on #22261

riot-ci · 2026-08-26T14:53:06Z

Murdock results

❌ FAILED

f7f6d3d fixup! test/periph/adc_dma: add test for ADC DMA based sampling

Success	Failures	Total	Runtime
87	1	10268	01m:16s

Build failures (1)

Application	Target	Toolchain	Runtime (s)	Worker
tests/build_system/cpp_exclude	samr21-xpro	llvm	1.45	mobi6

Artifacts

benpicco · 2026-08-27T09:18:45Z

+
+int main(void)
+{
+    adc_continuous_begin(ADC_RES_12BIT);


Wouldn't it make sense to move this into adc_dma_setup()?

You already forgot the adc_continuous_stop() after adc_dma_release() - if those always go together, just reduce them to one function.

adc_continuous_begin is handy because of _adc_configure which is in the non continuous variant tied to direct sampling. I would assume adc_continuous_begin/stop is used already by people, so using DMA is like on top of that. Before I call adc_continuous_, I would rather reuse _adc_configure(). I dont know/remember, why I did not do this. That way, there would be no dependency to adc_continuous.
But using both could be in conflict, because adc_continuous set up ADC already and the DMA could reconfigure it.

benpicco · 2026-08-27T09:19:38Z

+    adc_dma_setup(adc_arg.adc, _adc_dma_cb, &adc_arg);
+    adc_dma_start(adc_arg.adc, _buf, adc_arg.avg_samples_numof);
+
+    xtimer_msleep(CONFIG_TEST_ADC_SLEEP_SEC * MS_PER_SEC);


Is there no way to get a notification / wait until the sample buffer is full?

The sample buffer (2048) is full every time when a DMA interrupt happens. The interrupt triggers an event to copy the samples to a separate buffer and process them. The second buffer exists so that sampling can continue while processing is ongoing. The xtimer_msleep was for me a cheap alternative to a shell command to stop sampling. The shell is flooded with DMA samples anyway.

So the DMA is always looping around?
Since you only have a single buffer, how do you know your memcpy is faster than the DMA already writing the next sample to the beginning again?

In the DMA ISR, samples are copied form sampling to processing buffer, so there are 2 buffers. When processing was too slow the event would still be queued and "ADC: processing too slow\n" prints.

I assume that DMA does not continue when I am in the ISR

Swapping buffers is favorable. By using properly, you mean calling dma_prepare from ISR to swap buffers?
I think still the BLOCKACT_BOTH is required, because the DMA could continue until buffers are swapped, so a few newer samples could still override the sampling buffer.

I would wrap this in adc_dma_continue(), calling dma_prepare and continuing execution from ISR

You can chain the buffers together, so no additional call to dma_prepare() is needed.

It would still be good to also support single shot operation if one want to only get one buffer full of samples.

What do you mean by chaining them together?

One shot or n-shot could be realized with calling adc_dma_stop instead of adc_dma_continue from ISR.

With dma_append_dst() you can specify the next buffer that should be used when the first buffer is full.

If you then chain the last buffer to the first, you get a loop (this is what dma_enable_loop() does)

benpicco · 2026-08-27T09:53:16Z

@@ -477,3 +526,89 @@ int32_t adc_sample(adc_t line, adc_res_t res)

    return val;
 }
+
+int adc_dma_setup(adc_t line, dma_cb_t cb, void *arg)


In #20622 I could specify the sampling frequency - here we just use whatever was configured on the board level for all ADC channels?

Yes whatever is configured with ADC_GCLK_SRC and ADC_PRESCALER. Do I have to do it like in in your PR, or can it stay like this now?

kfessel · 2026-08-27T10:40:04Z

+/**
+ * @brief   Update the DMA Completion callback context
+ *
+ * @param   dma[in] DMA channel to release


Suggested change

* @param dma[in] DMA channel to release

* @param[in] dma DMA channel to release

kfessel · 2026-08-27T10:40:39Z

+ * @brief   Update the DMA Completion callback context
+ *
+ * @param   dma[in] DMA channel to release
+ * @param   ctx[in] DMA complete callback context


Suggested change

* @param ctx[in] DMA complete callback context

* @param[in] ctx DMA complete callback context

kfessel · 2026-08-28T10:36:16Z

be sure to adjust the PR description to match the actual amount of changes

does a makeover of the sam0/dma
removes dma_wait in for a callback based implementation
adds a DMA based DAC play
adjust DMA based SPI implementation

benpicco and others added 18 commits May 8, 2026 18:15

boards/same54-xpro: use analogue supply voltage as DAC reference

5765ebb

cpu/sam0_common/dma: Add functions to enable / disable DMA looping

08555f4

cpu/sam0_common/dma: add DMA callback

be4697d

drivers/periph/dac: add dac_play API for multi sample output

1d483c2

cpu/sam0_common: implement periph_dac_play

23866db

tests/periph: add test app for periph_dac_play

7c0cf01

fixup! boards/same54-xpro: use analogue supply voltage as DAC reference

23af2af

fixup! cpu/sam0_common/dma: add DMA callback

03d1857

fixup! cpu/sam0_common: implement periph_dac_play

8f9e6fb

fixup! cpu/sam0_common/dma: add DMA callback

ac1c56c

fixup! drivers/periph/dac: add dac_play API for multi sample output

a521d1f

fixup! tests/periph: add test app for periph_dac_play

d94210f

fixup! fixup! drivers/periph/dac: add dac_play API for multi sample o…

5d13ad0

…utput

Revert "boards/same54-xpro: use analogue supply voltage as DAC refere…

bcdf052

…nce" This reverts commit 5765ebb.

cpu/sam0_common/periph/adc: implement DMA sampling

0d592c7

test/periph/adc_dma: add test for ADC DMA based sampling

308c796

cpu/sam0_common/periph/dma: looped DMA transaction IRQ

baa7213

fabian18 requested review from MichelRottleuthner, MrKevinWeiss, aabadie, benpicco, dylad, keestux and leandrolanzieri as code owners August 26, 2026 12:41

github-actions Bot added Platform: ARM Platform: This PR/issue effects ARM-based platforms Area: tests Area: tests and testing framework Area: build system Area: Build system Area: drivers Area: Device drivers Area: cpu Area: CPU/MCU ports labels Aug 26, 2026

fixup! cpu/sam0_common/periph/dma: looped DMA transaction IRQ

af97097

crasbe added the State: waiting for other PR State: The PR requires another PR to be merged first label Aug 26, 2026

benpicco reviewed Aug 27, 2026

View reviewed changes

kfessel reviewed Aug 28, 2026

View reviewed changes

fabian18 added 7 commits September 2, 2026 13:17

fixup! cpu/sam0_common/periph/dma: looped DMA transaction IRQ

6667a14

cpu/sam0_common/periph/dma: add block action to dma_prepare

4d00c85

cpu/sam0_common/periph/dma: add dma_resume

bcee469

cpu/sam0_common/periph/adc: add adc_dma_continue

c5f1b49

cpu/sam0_common/periph/adc: allow double buffering

0e28f42

fixup! cpu/sam0_common/periph/adc: implement DMA sampling

c07861e

fixup! test/periph/adc_dma: add test for ADC DMA based sampling

f7f6d3d

	* @param dma[in] DMA channel to release
	* @param[in] dma DMA channel to release

	* @param ctx[in] DMA complete callback context
	* @param[in] ctx DMA complete callback context

Uh oh!

Conversation

fabian18 commented Aug 26, 2026

Contribution description

Testing procedure

Issues/PRs references

Declaration of AI-Tools / LLMs usage:

Uh oh!

crasbe commented Aug 26, 2026

Uh oh!

fabian18 commented Aug 26, 2026

Uh oh!

riot-ci commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Murdock results

Artifacts

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

benpicco Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fabian18 Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

benpicco Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kfessel commented Aug 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

riot-ci commented Aug 26, 2026 •

edited

Loading

benpicco Aug 27, 2026 •

edited

Loading

fabian18 Aug 27, 2026 •

edited

Loading

benpicco Aug 27, 2026 •

edited

Loading