How can I speed up the ADC?

I want to speed up the ADC, because it takes me about a milisecond to sample my entire sensor array.

So, you have an array of eight or nine sensors?
You're still sampling every two millimetres.

The analogRead (you have the source) splits neatly into four sections:

  1. Setup input mux
  2. start conversion
  3. busy-wait for conversion to complete
  4. read result.

Eliminate 3), and you're probably a good way to doing what you want.
Or think about using the end-of-conversion interrupt.

So how do I change the analogRead? I'm still a bit of a newbie, I haven't tinkered with existing instructions yet.

Go to the source in "wiring_analog.c"

AWOL:
Go to the source in "wiring_analog.c"

Sorry for being a huge noob, but where do I find the source?

/hardware/arduino/cores/arduino/wiring_analog.c

Thanks, I found it. With a lot of help from my teacher, I was able to fix it. I'll soon post myAnalogRead here, for people who want to speed things up on their uno or duemilanove :wink:

uint8_t myAnalogRead(uint8_t pin)
{
uint8_t low;//, high;

// set the analog reference (high two bits of ADMUX) and select the
// channel (low 4 bits). this also sets ADLAR (left-adjust result)
// to 0 (the default).

/*mask ADMUX see http://www.atmel.com/Images/doc8161.pdf point 23.9!!!
set refs1 and refs0 by shifting 3(high high) six bits to the left to use the internal voltage reference
shift high to ADLAR to place the most significant bits in ADCH
and then mask the last nibble with the channel of the pin
*/
ADMUX = (0x3 << 6) | (1 << ADLAR) | pin;

// start the conversion
sbi(ADCSRA, ADSC);

// ADSC is cleared when the conversion finishes
while (bit_is_set(ADCSRA, ADSC));

// we have to read ADCL first; doing so locks both ADCL
// and ADCH until ADCH is read. reading ADCL second would
// cause the results of each conversion to be discarded,
// as ADCL and ADCH would be locked when it completed.
low = ADCL;
//high = ADCH;

// read the high byte
return ADCH;
}

Then in setup, you can also set the division factor to speed things up.

void setup()
{
setDivisionFactor(128);

}

And for setting the division factor, I wrote this little void:

void setDivisionFactor(byte divisionFactor)
{
switch(divisionFactor)
{
case 2 :
cbi(ADCSRA, ADPS2);
cbi(ADCSRA, ADPS1);
sbi(ADCSRA, ADPS0);
break;
case 4 :
cbi(ADCSRA, ADPS2);
sbi(ADCSRA, ADPS1);
cbi(ADCSRA, ADPS0);
break;
case 8 :
cbi(ADCSRA, ADPS2);
sbi(ADCSRA, ADPS1);
sbi(ADCSRA, ADPS0);
break;
case 16 :
sbi(ADCSRA, ADPS2);
cbi(ADCSRA, ADPS1);
cbi(ADCSRA, ADPS0);
break;
case 32 :
sbi(ADCSRA, ADPS2);
cbi(ADCSRA, ADPS1);
sbi(ADCSRA, ADPS0);
break;
case 64 :
sbi(ADCSRA, ADPS2);
sbi(ADCSRA, ADPS1);
cbi(ADCSRA, ADPS0);
break;
case 128 :
sbi(ADCSRA, ADPS2);
sbi(ADCSRA, ADPS1);
sbi(ADCSRA, ADPS0);
break;
}
}

I hope someone turns all of this in a special analogReadspeedy or something like that and introduces it into the standard Arduino library!

And for setting the division factor, I wrote this little void:

"void" is the type of the function - you call it a "little function", not a "little void".

To call it a "void" is like Prince singing "Raspberry" or "Little Red"

AWOL:

And for setting the division factor, I wrote this little void:

"void" is the type of the function - you call it a "little function", not a "little void".

To call it a "void" is like Prince singing "Raspberry" or "Little Red"

:cold_sweat: Sorry oh master! I shall wash my keyboard and cleanse myself of this noobishness. Anyway, thanks for the help! If you spot anything else that can be improved, please do tell me!

I don't have a proper sensor yet(other teammembers are working on it), but when I do, I'll analyze which is the lowest acceptable division factor.

AWOL:
"void" is the type of the function - you call it a "little function", not a "little void".

I dunno. I looked at that function and it seemed a 'little void' to me. :smiley: (Sorry it's bad joke day and I am just trying to fill my quota).

AWOL:

And for setting the division factor, I wrote this little void:

"void" is the type of the function

No, void is the result-type of the function :wink:

Hi Firemann00b,

Just a few design considerations before you max out on the ADC.

  • Do you really need to sample that fast. Controlling stuff is about controlling or changing the state they are in. Speed is a state. What is important is how fast does your robot CHANGE speed / steer. I take it it is not going to make a U-turn with a radius of 1 cm if it's doing 2 m/s. There is no point in having a very fast controller if the robot cannot comply with the commands its been given. It will cause the controller to oversteer, and can cause stability issues (oscillations)
  • Fast sampling creates noisy readings. You will have to filter the readings.
  • Fast sampling creates lots of data. Arduinos do not have lots of memory to store that information, nor do they have a lot of CPU power to process it in real time.
  • Look ahead. Knowing what's coming gives you more time to react. Faster sampling won't.

regards,

Pieter

If you want to maximise the ADC conversion rate, use the conversion complete interrupt (see the atmega328p datasheet). In the interrupt service routine, read the adc result and store it in a variable appropriate to the channel you have just sampled. Then set the adc mux to the next channel (or back to the first channel, if you have done all the channels of interest) and kick off another conversion. Like this:

const byte numAdcChannels = 6;
volatile unsigned int adcResult[numAdcChannels];
volatile byte currentAdcChannel = 0;

void startConversion()
{
  ADMUX = (B01000000 | currentAdcChannel);   // Vcc reference, select current channel
  delayMicroseconds(5);    // only needed if using sensors with source resistance > 10K
  ADCSRA = B11001111;   // ADC enable, ADC start, manual trigger mode, ADC interrupt enable, prescaler = 128
}

// Interrupt service routine for ADC conversion complete
ISR(ADC_vect) 
{
  // The mcu requires us to read the ADC data in the order (low byte, high byte)
  unsigned char adcl = ADCL;
  unsigned char adch = ADCH;
  adcResult[currentAdcChannel] = (adch << 8) | adcl;
  ++currentAdcChannel;
  if (currentAdcChannel == numAdcChannels)
  {
     currentAdcChannel = 0;
  }
  startConversion(); 
}

void setup()
{
   ...
   startConversion();
}

Then in loop() you can look at the adcResult variables and work out what needs to be done. You should disable interrupts while reading them in loop(). If you change program the ADC to use only 8-bit accuracy, then you can use a byte array instead of an unsigned int array, then you do not need to disable interrupts when reading them.

BTW using a delay inside an isr should generally be avoided, however very short delays to allow hardware to settle are OK.

dc42:
void startConversion()
{
ADMUX = (B01000000 | currentAdcChannel); // Vcc reference, select current channel
delayMicroseconds(5); // only needed if using sensors with source resistance > 10K
ADCSRA = B11001111; // ADC enable, ADC start, manual trigger mode, ADC interrupt enable, prescaler = 128
}
...
BTW using a delay inside an isr should generally be avoided, however very short delays to allow hardware to settle are OK.

I'm trying to understand what the delay will do to the ADC process, but my understanding of the manual isn't great. I've reread the manual on ADC several times but I cannot make sense of statements such as:

An analog source applied to ADCn is subjected to the pin capacitance and input leakage of that pin, regardless of whether that channel is selected as input for the ADC. When the channel is selected, the source must drive the S/H capacitor through the series resistance (combined resistance in the input path).

Does this imply that the ADC circuit starts charging once a channel is selected in ADMUX but before the ADCSRA ADSC bit is set? Elsewhere the manual states that the sample & hold of a channel only starts after the ADSC bit in ADCSRA is set, so a delay before setting ADCSRA shouldn't affect the charging of the ADC cap?

Christo:
I'm trying to understand what the delay will do to the ADC process, but my understanding of the manual isn't great. I've reread the manual on ADC several times but I cannot make sense of statements such as:

An analog source applied to ADCn is subjected to the pin capacitance and input leakage of that pin, regardless of whether that channel is selected as input for the ADC. When the channel is selected, the source must drive the S/H capacitor through the series resistance (combined resistance in the input path).

Does this imply that the ADC circuit starts charging once a channel is selected in ADMUX but before the ADCSRA ADSC bit is set?

Yes. When no conversion us in progress, the sample capacitor is connected to the input channel pin selected by the mux.

Christo:
Elsewhere the manual states that the sample & hold of a channel only starts after the ADSC bit in ADCSRA is set, so a delay before setting ADCSRA shouldn't affect the charging of the ADC cap?

As far as I can tell, "sample and hold" comprises waiting 1.5 ADC clocks, then disconnecting the capacitor from the selected input pin and connecting it to the converter. I have found that a delay (between setting the mux and starting the conversion) of about one microsecond per 10K source resistance is needed to achieve accurate results. There is some delay built in to the sample process already, so no delay is needed when the source resistance is 10K or less (as recommended in the datasheet).

pbrouwer:
Hi Firemann00b,

Just a few design considerations before you max out on the ADC.

  • Do you really need to sample that fast. Controlling stuff is about controlling or changing the state they are in. Speed is a state. What is important is how fast does your robot CHANGE speed / steer. I take it it is not going to make a U-turn with a radius of 1 cm if it's doing 2 m/s. There is no point in having a very fast controller if the robot cannot comply with the commands its been given. It will cause the controller to oversteer, and can cause stability issues (oscillations)
  • Fast sampling creates noisy readings. You will have to filter the readings.
  • Fast sampling creates lots of data. Arduinos do not have lots of memory to store that information, nor do they have a lot of CPU power to process it in real time.
  • Look ahead. Knowing what's coming gives you more time to react. Faster sampling won't.

regards,

Pieter

I plan to read the interrupts on a cyclic basis. I'm not going to implement it fully, but my aim is to make my program run hard real time(for those who aren't into controller theory, this means there is no jitter on the delay between reading the input and writing the output). So it's of great importance I generate an input fast, so there's enough time left in the cycle to calculate the output. The cycle time for the whole algorithm is about 5 ms to make turns with a minimal radius of 10cm. It's calculated that if the car keeps going forward for 10 cycles, it will have lost the line. For 8 sensors, it takes about 1 ms to read them all with a division factor of 128. This means a fifth of the cycle is lost just to reading the sensors. And I have to use linear interpolation to translate the sensor values to an error and then calculate the motor speeds to compensate for the error.

I think your teacher laid out, too clearly in my view, what you needed to do.

If you really want fast adc (I don't think you need), put the adc on automatic sampling and it will perform adc non-stop. Read the adc high byte, left aligned, provided you with 8-bit resolution. Read the adc high byte, right aligned, provided you with 2-bit resolution.

Let me just add one more bit: you may want to think about your implementation. For you to implement a PID on top of a fast adc to just follow a line, either your car is powered by a rocket or your implementation is seriously wrong.

dhenry:
I think your teacher laid out, too clearly in my view, what you needed to do.

.. Read the adc high byte, left aligned, provided you with 8-bit resolution. ..

That's what I ended up doing, as you can see in my code. The 8-bit resolution actually did the trick for me, it drastically reduces the processing time for normalizing the sensor values and translating those values into a line position.

dhenry:
Let me just add one more bit: you may want to think about your implementation. For you to implement a PID on top of a fast adc to just follow a line, either your car is powered by a rocket or your implementation is seriously wrong.

My car has to go 2 m/s, I really wanted some room to play in those 5 ms of cycle time. Now I've done some proper testing, apparently I've got plenty of room, even with a division factor of 128. Still, myAnalogRead is usefull, because I might want to go for fuzzy instead of PID. Once I comfortably get to those 2m/s, I might want to go even faster(but that's never going to happen in this universe :wink: )