I need to read an analog signal at about 50khz (for maybe 50-500 samples, not sure yet).  The reference seems to indicate the analogRead() takes about 100us, which is good enough for 10khz.  Is this limitation set by the Arduino libraries, or the ATMEGA chip?

Any help much appreciated,
Chris

P.S. does anyone know how fast the digital read is?

According to the specs:

Quote:


The ADC clock is 16 MHz divided by a prescale factor. The prescale is set to 128 (16MHz/128 = 125 KHz) in wiring.c. Since a conversion takes 13 ADC clocks, the sample rate is about 125KHz/13 or 9600 Hz.

So anyway, setting the prescale to, say, 16, would give a sample rate of 77 KHz. Not sure what kind of resolution you would get though!

EDIT:

Found this reference:

http://www.atmel.com/dyn/resources/prod_documents/DOC2559.PDF

Here's a relevant quote:

Quote:


So looks like using a prescale of 16 as above would give an ADC clock of 1 MHz and a sample rate of ~77KHz without much loss of resolution. BTW, this is the code to set the prescale to 16:

Code:

// defines for setting and clearing register bits
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif

// set prescale to 16
sbi(ADCSRA,ADPS2) ;
cbi(ADCSRA,ADPS1) ;
cbi(ADCSRA,ADPS0) ;
 

Bear in mind that the Arduino digital and anlog read/write abstractions that make this platform so easy to use, do reduce the execution time over what could be achieved if one used low level code to directly access these functions. The arduino functions will be slower than the timings quoted above.

For example, the Arduino digitalRead function first does a lookup to convert the Arduino pin number to an actual port and pin. It then disables any PWM function that could be running on this pin. And finally, it executes another dozen instructions or so to actually read the port. I would think it would take well over twenty times longer for each digitalRead compared to directly accessing a specific low level port pin.

AnalogRead also does the Arduino pin mapping lookup and it sets the analog reference bits each time analogRead is called, although this probably represents a small fraction of the total ADC conversion time.

If your application does need digital read times under a microsecond, you can read more about direct port manipulation here: http://www.arduino.cc/en/Reference/PortManipulation

Do you guys have a sense of how much the resolution or accuracy of the inputs vary as the speed increases?  I'm happy to decrease the default prescale factor if we still get accurate readings.  (I think it's better in most cases to be accurate and a bit slow than the other way around.)  Any thoughts on which value provides the best balance of accuracy and speed?

mellis wrote on 21.04.2008 at 15:24:06:


I don’t know how much the accuracy drops if you exceed the recommended rates in the datasheet, but I would think it would not be good practice to add functionality to the standard Arduino platform that clocked the ADC faster then the manufactures recommendation. And if my math is correct, at 16mhz, a prescale of 64 or less will exceed the 200khz max ADC clock rate stated in the datasheet.

Perhaps someone who has the time to explore and document the affect on accuracy could post some information and code in the playground.

Oracle, did you have a chance to do any tests on accuracy when you ran the speed tests?

mem wrote on 21.04.2008 at 17:35:58:


Still, the Atmel document referred to above (http://www.atmel.com/dyn/resources/prod_documents/DOC2559.PDF) says:

Quote:


To me, that's as good as a green light, direct from the manufacturer, to go to 1 MHz and a 77k sample rate--with no significant effect on resolution.

mem wrote on 21.04.2008 at 20:53:18:


But the note says that calibration applies only to differential ADC mode:

Quote:


I believe the note uses accuracy/resolution interchangeably:

Quote:

I have used the MUX shield to read 16 analog pots, one every 16th cycle of the main loop (which also counts through the MUX output), previously I had used separate analog inputs, each also on a main loop based counter.

Only taking one reading per main loop cycle made a huge difference, and this ought to help it even more.

edit:
Ok i got home and tried it, My ISR which generates sound uses about 40% of the processing time, and I have a lot of stuff going on in my main loop and there i one analogread per loop(different pots through MUX)

test bit was cycling at:
460hz
changed 3 analogwrites to OCRxx and some digitalwrites to direct bitwrite to the ports., the speed improved to
480hz
then i did this tweak and the speed improved to
530hz
so even with all the other things happening in my loop
(quite a lot, including a lot of "map" and other multiplication and division) thats quite a nice improvement!

edit:
oh yes i do not notice any difference in the accuracy of the potentiometers as far as i can tell i cant hear any wavering of the controls when set the filter frequency or whatever.