Related area

adc continuous in its entirety

Hardware specification

Improvements to the robustness and usefulness of adc_continuous, and better examples with real world use cases

Is your feature request related to a problem?

I have spent the last week trawling around the innards of adc_continuous and I'm surprised anyone is using it as it is way too complicated for its own good, and needs to be set 'just right' to work at all. I'm pleased to say I can now see the sine wave I am inputting but to get to this point was a trial too far with too many asserts() crashes, missing data, loops misaligning. I couldn't even get the non-DMA version to work at all as copying the data out of the buffer would cause a crash. What I'm trying to say is it is too complicated to set up. The examples are almost useless and do not support any use cases other than voltmeter style readings. Please provide better guidance, simpler configuration, and some examples of proper use cases. For example, I am trying to read 1ms of data from 2 channels into a buffer, stop the adc, do some processing and start the adc again. As the acd uses a circular buffer of its own, aligning the data I get with the point at which I start the adc_continuous_read is difficult as the function just returns its buffer, I need an option to clear the buffer and start again at 0. Or even better, start at -x, so I can sample from a fixed point back in time.

Describe the solution you'd like

int16* buffer[channel_countfrequencynumber_of_samples];
// I'd rather avoid defining a pool size for a smaller intermediate buffer but will if I have to
adc_continuous_setup(channels, frequency, number_of_samples, &buffer);
adc_continuous_start(&callback);

// a minimum freq of 20kHz is reasonable as this can be achieved with analogRead() or adc_get_raw()
// get rid of one_shot. it muddies the water, requires further examples and has no benefit other than reading multiple channels. adc_continuous_one_read is an oxymoron.

Describe alternatives you've considered

There are no alternatives for faster reading. adc_get_raw() offers no benefit over analogRead() although I haven't tried the DAM version for speed.
IRAM/DMA adc_get_raw(GPIOPin, frequency, number_of_samples, &buffer); would be magic and I could forget I ever wasted a week trying to understand adc_continuous :)

Additional context

No response

I have checked existing list of Feature requests and the Contribution Guide

• I confirm I have checked existing list of Feature requests and Contribution Guide.