Skip to content

Conversation

@rnd-ash
Copy link
Contributor

@rnd-ash rnd-ash commented Jun 25, 2025

Summary

This PR switches the buffered reading implementations of the ADC/FutureADC to use DMA transfers rather than trying to do it via the CPU in free running mode.

This is because, at high ADC clock speeds, and low CPU clock speeds, it is very easy (Especially with ISRs running), to encounter ADC overrun errors when trying to read into an array.

By using DMA, this can be avoided completely.

For consistency reason, DMA Blocking reading is only for ADC, and DMA Async reading is only for FutureADC, even though, DMA Async reading can be done without a FutureADC (Since it does not depend on ADC IRQs)

No examples were changed here since there was no existing example using buffered ADC reading

@ianrrees
Copy link
Contributor

ianrrees commented Jul 1, 2025

We discussed this a bit in chat, but just to have a coherent discussion here: my feeling is that DMA support for peripherals like ADCs and DACs should provide an ability to stream data such that either samples move at a consistent rate, or there's a detectable error produced. An example would be a good way to demonstrate (and verify) this behaviour.

I see that this uses free running mode, which is a good step in the right direction, but clearing errors at the beginning of the read method is a problem. In practice, this sort of thing usually ends up involving a double-buffer, one approach to consider is a method that both takes a buffer as an argument, and returns one in a Result-like type. The return type needs to be capable of reporting two kinds of errors: the normal kind that indicate the operation failed, and an additional kind that were noted but didn't stop the operation (like the overruns before the next read).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants