Tuning ADC to a specific sample rate (i.e. 8000Hz)

LeafLabs Garden » Support » Maple IDE Support

Tuning ADC to a specific sample rate (i.e. 8000Hz)

(13 posts) (5 voices)

Started 4 years ago by robodude666
Latest reply from gbulmer

robodude666
Member

Hey guys,

I'm starting to play around with the ADC functionality and was wondering: How would one configure the ADC for a specific sample rate (i.e. xxx samples per second)?

I noticed that the adc.h header file defines an adc_smp_rate enum which features sample rates in a # of ADC cycles per sample, but that seems rather fast. I also understand (I hope) the ADC clock is running at 12MHz (72MHz / 6 divider). At the very slowest sample rate of 239.5 ADC clocks per sample that's 20uS per sample, or 50kHz. That's great, but what if I want a 8000Hz sample rate, or 44.1kHz sample rate?

I've gotten ADC samples to be stored in SRAM via the DMA1 Channel 1 controller, but it's going too fast (I know, right?). Very primitive benchmarks [1] suggest a ~550kHz sample rate with ADC_SMPR_7_5, though I know my benchmark is VERY bad (polling the ISR bit !== smart) but the DMA interrupt stuff isn't working right just yet.

Would I be best off setting up a timer with a xxxHz interrupt and sample the ADC manually rather than using the ADC's DMA? It's probably meant for people who need high sample rates.

Cheers,
-robodude666

[1] https://gist.github.com/1019639 - My primitive ADC + DMA testing/benchmarking. There, it's on gist and not inline =].

Posted 4 years ago #
poslathian
LeafLabs

robodude,
For 44KHz, I would probably just use (have used in the past) a timer interrupt. BUT, even if you dont need a crazy sample rate, if you are doing some serious crunching on those samples, the DMA might give you the extra performance you need elsewhere. The is a fairly high cost incurred for going the interrupt route.

My advice would be go with interrupts until you run out of performance, then upgrade to DMA style.

Posted 4 years ago #
gbulmer
Moderator

robodude666

I noticed that the adc.h header file defines an adc_smp_rate enum which features sample rates in a # of ADC cycles per sample, but that seems rather fast. I also understand (I hope) the ADC clock is running at 12MHz (72MHz / 6 divider). At the very slowest sample rate of 239.5 ADC clocks per sample that's 20uS per sample, or 50kHz.

The ADC sample rate is actually made up of two parts.
1. Sample the input signal by charging a 'sample and hold circuit' (a capacitor). This is the part affected by adc_smp_rate
2. Convert the voltage on the sample and hold circuit (capacitor) to a binary number. The conversion takes a fixed number of ADC cycles (12.5 cycles). The ADC electronics disconnects the sample and hold circuit from the outside world (so it won't change while it is converting it) and uses the voltage value on the sample and hold circuit for the conversion.

For 1 to work properly, the capacitor needs to be charged up to match the input voltage.
If the input signal has a very high output impedance (it can't supply much current), the sample capacitor charges slowly.
If the input signal is a low impedance (it can supply lots of current), the sample capacitor charges quickly.

The sample part of the ADC can be programmed to allow for a sample time as short as 1.5 clocks (of that 12MHz ADC clock) upto 239.5 clocks (Section 11.12.4 "ADC sample time register 1 (ADC_SMPR1)" of RM0008).

So this isn't quite setting the conversion rate. It is allowing the ADC to adjust the time to charge the sample and hold circuit (capacitor) to account for the output impedance (ability to supply current) of each source signal connected to each ADC channel.
The ADC can be used as slow as you like, but it can't be faster than this time.

The library sets the sample time to a conservative value (55.5 cycles?) to allow for quite high output impedance signals. This allows Maple users to get reasonable results without dipping into the underlying details.

I'm with poslathian; use a timer to set the sample rate.
It is possible to trigger an ADC conversion from a timer, and a DMA, but it will be much easier to code and debug if you keep things simple and do the work 'by hand' in your own code. People have written straightforward code which runs at well over 100,000 samples/second.

(full disclosure: I am not a member of LeafLabs staff)

Posted 4 years ago #
mbolivar
LeafLabs

gbulmer,

Thanks for the clarifying remarks. I now see that the comment describing adc_smp_rate was misleading, and have replaced it with one that should be more accurate:

https://github.com/leaflabs/libmaple/commit/76b9fd0a7b9dd3b09f16aeb5ff98d57df2a86386

In particular, the comment no longer specifies that an adc_smp_rate determines "conversion" time.

Posted 4 years ago #
robodude666
Member
Okay, so I'm finally getting around to driving my ADC sampling via a timer interrupt. I've so far been using delayMicroseconds(), and while it's working, I need to clean up my main() function to be less blocking.

I'm trying to sample two ADC inputs (D2 and D3) at a rate of 44.1kHz (audio sample rate) and store the value into a circular buffer. I've come to the following timer configuration:
```
uint32_t cycles = (uint32_t)(22.671f * (float)CYCLES_PER_MICROSECOND);
uint16_t pre = (uint16_t)((cycles >> 16) + 1);

timer_pause(TIMER3);

timer_set_mode(TIMER3, TIMER_CH1, TIMER_OUTPUT_COMPARE);
timer_attach_interrupt(TIMER3, TIMER_CC1_INTERRUPT, handler3b);

timer_set_prescaler(TIMER3, pre);
timer_set_reload(TIMER3, cycles / pre - 1);
timer_set_compare(TIMER3, TIMER_CH1, 1);

timer_resume(TIMER3);
```
This configures cycles to 1632, prescaler to 1, and a reload value of 1631. I've found that handler3b gets called 21,760 within 1 second (by monitoring handler3b's counts++ value using a millis() loop in main). Is this value right? Shouldn't it be called ~44,100 times in a single second?

Thinking it may be an issue with my configuration, I looked at the deep note Maple Mini example and tried this:
```
Timer3.pause();
Timer3.setChannel1Mode(TIMER_OUTPUTCOMPARE);
Timer3.setPrescaleFactor(pre);
Timer3.setOverflow((cycles / pre) - 1);
Timer3.setCompare1(1);
Timer3.attachCompare1Interrupt(handler3b);
Timer3.resume();
```
With the same pre and cycles values as calculated above. The overflow "reload" value still comes out to 1631. This time the interrupt is called 43,520 times per second -- twice that of the previous configuration getting closer to the desired 44.1kHz. Is this a designed feature of HardwareTimer ? I don't see HardwareTimer doing anything outside of calling the low-level C libmaple functions I previously configured.

-robodude666
Posted 4 years ago #
gbulmer
Moderator

robodude666 - have you printed the value of pre and cycles in both example programs?

As 43,520 is exactly twice 21,760, I guess the interrupt is firing only half as often. My suspicion is, in the higher frequency the counter is in 'upcounting' mode, and in the lower frequency case, it is in 'center-aligned' or 'up/down counting' mode (section 15.3.2 of RM0008). In center-aligned, it might generate only one interrupt/up+down cycle.

Maybe print out TIM3_CR1 register (in hex) to see if the bits are set in the same way for both cases.
If they aren't, try assigning to the register.

Posted 4 years ago #
robodude666
Member
Sorry for the late response.

I printed out the CR1 register using:
```
Serial2.print("CR1: ");
Serial2.println((TIMER3->regs).bas->CR1, HEX);
```
and in both cases the CR1 register is set to 0x81. This configures the timer to be in up-count mode using edge-alignment.
Posted 4 years ago #
mbolivar
LeafLabs

With the same pre and cycles values as calculated above

Careful! timer.h uses prescaler values appropriate for writing to the PSC registers (i.e., 0-based). HardwareTimer uses 1-based prescalers.

Are you sure you're not off by one?

Posted 4 years ago #
gbulmer
Moderator

robodude666 - dump all the TIMER3 registers. There must be something different.

I calculate as follows:
uint32_t cycles = (uint32_t)(22.671f * (float)CYCLES_PER_MICROSECOND);
is 22.671 * 72 -> cycles is 1632
uint16_t pre = (uint16_t)((cycles >> 16) + 1);
1632 >> 16 = 0, so pre is 1

so
timer_set_prescaler(TIMER3, pre); is timer_set_prescaler(TIMER3, 1);
and
Timer3.setPrescaleFactor(pre); is Timer3.setPrescaleFactor(1);
In which case mbolivar's point would explain it. In one case the precscaler divides the clock by 1, and in the other, by 2.

If you dump TIM3_PSC in both cases, it should be clear. (if that isn't the explanation, dump all the registers :-)

Posted 4 years ago #
hbdgas
Member

Hi,

I'm currently working on a school project that involves sampling audio data from a microphone and saving the data to a SD card. In order to give the CPU as much time as possible to write to the SD card, I'm considering using DMA. The desired sampling rate is 16kHz, but I read earlier in this topic that the slowest sample time for the adc is equivalent to 50kHz. Does anyone have any suggestions on how to slow the sampling rate further?

Posted 4 years ago #
gbulmer
Moderator
hbdgas - it is relatively straightforward to slow anything down by using a busy loop.

If you want roughly a 16KHz sample rate, you could do something like:
```
const unsigned usecs_duration = 1000000/16000;   // actually 62.5 usec, but this is integer division
//...

loop() {
    // ...
    unsigned now = micros();
    int val = analogueRead(pin);
    while ((micros()-usecs_duration) < now) ; /* do nothing */
    //...
}
```
This won't be very accurate though, because the amount of time is actually 62.5 usec (so almost 1% error), the micros() function doesn't take the same amount of time every time it is called, and there are concurrent interrupts stealing time.

So a better approach would be to trigger the ADC conversion with a timer.
This is described in the manual RM0008 (from ST Micro) in section 11.7 "Conversion on external trigger".
You could save the converted values to RAM with DMA, and move it to SD using DMA.

The desired sampling rate is 16kHz, but I read earlier in this topic that the slowest sample time for the adc is equivalent to 50kHz.

As you will have read in post http://forums.leaflabs.com/topic.php?id=849#post-5140
this adjustable sample time is primarily intended to ensure the electronics of the ADC gets an accurate sample of the input voltage. It is not really intended to be used to adjust the ADC to a specific sample rate, it is a bit too crude for that. Using this mechanism in this case would have the effect of blocking a program inside the analogRead() function, unless you implemented that yourself. Blocking inside analogRead() would just waste time that you might need to do some processing (though it is no more wasteful that the busy loop I wrote here).

(full disclosure: I am not a member of LeafLabs staff.)
Posted 4 years ago #
hbdgas
Member

gbulmer,

Thank you for the quick response. I think I will try the external trigger. One more question, admittedly I am not a great programmer, and I was planning on using the SDFat library to do the SD writes. I do not think the library supports DMA at this time(I could be wrong). How hard is it to write to SD using DMA?

Posted 4 years ago #
gbulmer
Moderator

hbdgas - there is an ongoing development of SD access using DMA by polpla, see:
http://forums.leaflabs.com/topic.php?id=112&page=5#post-6711

Edit: oops you already have :-)

Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.