ADCV2 - Switch buffered readings to use DMA#905
ADCV2 - Switch buffered readings to use DMA#905rnd-ash wants to merge 3 commits intoatsamd-rs:masterfrom
Conversation
|
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). |
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