I am developing some code which involves an external interrupt and a 2 KHz. timer. This project also involves reading in an analog voltage on one of the analog pins on the UNO. I have read that an analog read requires about 100 usec., which isn't insignificant relative to a 2 KHz. interrupt rate, along with other randomly arriving external nterrupts. So the thought naturally occurs: are analog reads protected from interrupts?
The analog read I am doing is of the LM35 temperature sensor, and I seem to get occasional wacky answers from it.
you can decrease ADC prescaler to increase analogRead() speed by manipulating
ADPSx in ADCSRA: http://forum.arduino.cc/index.php/topic,6549.0.html
arduino tries to maximize ADC resolution, that's why a slow conversion speed is chosen by default.
i dunno what u mean "protected from interrupts"...
(simplified) analogRead() works like this:
bitSet(ADCSRA, ADSC); // tell the hardware to do the conversion
while (bitRead(ADCSRA, ADIF); // wait for the conversion to complete
return (ADCH << 8) & ADCL; // return the result
if a interrupt is issued during 2, the CPU will go serve the ISR, the come back after ISR served.
jrdoner:
So the thought naturally occurs: are analog reads protected from interrupts?
The question requires context to have an answer. The most effective way to convey that context is to post your sketch. Please use </mark> <mark>[code]</mark> <mark>
jrdoner:
So the thought naturally occurs: are analog reads protected from interrupts?
If you mean will an interrupt affect an in-progress conversion by the ADC, the answer is no. The ADC is separate "peripheral" hardware. Basically it just needs to be told to start a conversion. While it's doing its thing, it's not executing instructions or relying on the CPU in any way. When it's finished, it will set a flag and/or fire an interrupt. Conversions can be started individually, they can be automatically started on a fixed cycle based on a timer interrupt, or they can run continuously, i.e. as soon as a conversion finishes, the ADC starts another immediately.
The analog read I am doing is of the LM35 temperature sensor, and I seem to get occasional wacky answers from it.
We could analyze the interrupt concerns and apply our interlect, or simply make multiple readings and average. The package mass of the sensor will retard instanteous thermal accuracy anyway, thus averaging will eliminate those wacky answers and not affect the +/- 0.5C accuracy.