So why does the atmel spec sheet say 35 to 250 us, are you saying they are incorrect?
No, not at all - the speed of the ADC depends on its clock rate, and the Arduino sets it at 125kHz.
A conversion takes 13 cycles of this clock.
104 is between 35 and 250, so everyone is happy.
ADC on these chips is succ. approx, the time to convert depends upon the data. That is why is can be anywhere within the stated range. Where do you get your stated 13 cycles from?
I presume when showing the spec for conversion timing they are showing its best value , not an artificialy slow one calculated by underclocking the chip.
Since the ADC cct has its own clock this conversion time probably does not even depend on what the main clock rate is set to.
A normal conversion takes 13 ADC clock cycles. The first conversion after the ADC is switched
on (ADEN in ADCSRA is set) takes 25 ADC clock cycles in order to initialize the analog circuitry.
ardnut:
Since the ADC cct has its own clock this conversion time probably does not even depend on what the main clock rate is set to.
More nonsense. Datasheet, page 264.
Bits 2:0 – ADPS2:0: ADC Prescaler Select Bits
These bits determine the division factor between the system clock frequency and the input clock to the ADC.
The ADC clock is scaled from the system clock.
I strongly suggest you read the data sheet before insulting people here, lest trouble falls.
@OP, a successive approximation A-to-D consists of a D-to-A and a comparator.
The conversion is essentially a binary chop, starting with the MSB, and it necessarily has to perform at least as many comparison cycles as there are bits to be converted.
OK, so now you've read it , rather than being pedantic about whether the lower limit is 13 or 35 perhaps you could explain why the manufacturer puts such was wide range on possible convertion times if ,as everyong here seems to think a succ-approx ADC always takes the same amount of time which is 13 clock cycles.
@AWLO: you posted "104 is between 35 and 250, so everyone is happy." Hardly a sensible comment, that is why I asked if you were being serious. Nothing troll-like about that. I'm trying to have a technical discussion about what is written in the spec sheet. You flippant comment was not that helpful.
@OP, a successive approximation A-to-D consists of a D-to-A and a comparator.
The conversion is essentially a binary chop, starting with the MSB, and it necessarily has to perform at least as many comparison cycles as there are bits to be converted.
Consider what happens if the first approximation just happens to match the input data within the required resolution. The comparator output shows conversion is finished.
If the data happens to be that really unlucky value that means the binary chop has to go all the to the last bit, it will take a lot more iterations.
I suppose you also think that quicksort also takes exactly the same number of iterations irrespective of the data it is sorting.
Nick , you may wish to consider what is meant by a "normal" conversion. Perhaps they meant "typical".
Now since that is roughly midway between 13 and 250 us , perhaps the "typical" conversion time is indeed 13 clock cycles or 104 us .
That's complete nonsense. Read the datasheet:
I did read the data sheet and I quoted it saying there was a large range of conversion times. AWOL seems to have been able to find the relevant page. If you can't I suggest you learn some better manners before threatening people with mallets.
ardnut:
Consider what happens if the first approximation just happens to match the input data within the required resolution. The comparator output shows conversion is finished.
Nope. The comparator indicates less-than or greater-than but not equals. AWOL is correct. One clock cycle per bit plus a few for overhead.
I suppose you also think that quicksort also takes exactly the same number of iterations irrespective of the data it is sorting.
Why do you mention quick sort? It's a successive approximation converter not a quick sort converter.
Now since that is roughly midway between 13 and 250 us , perhaps the "typical" conversion time is indeed 13 clock cycles or 104 us .
A conversion is always 13 clock cycles (25 after changing channels).
I suppose you also think that quicksort also takes exactly the same number of iterations irrespective of the data it is sorting.
No, that would be foolish.
Think, it's a RISC processor, and an extremely low cost one at that.
Ever seen quick sort or anything similar implemented in RISC hardware?
Thought not.
Yesterday I deleted a post by a user on this thread that I thought was inflammatory, but now I'm beginning to see the truth in it.
ardnut:
I suppose you also think that quicksort also takes exactly the same number of iterations irrespective of the data it is sorting.
Now that's insulting, in case you don't realize it. A quicksort is mathematical operation in a sequence of data points. Clearly it will not run in fixed time. The initial permutation of the data to be sorted would affect it.
We are discussing the behaviour of some computer hardware here, hardly the same thing.
I ran jraskell's test above, feeding in a sine wave of 100 Hz from 0 to 5V from the function generator. The values detected are printed so you can see they are not all the same. I added noInterrupts () and interrupts() around the analogRead so a timer interrupt would not throw out the results.
Good distribution around the average. It's more than 104 but it would take a few cycles to get the time, save the analogRead result, etc.
I also did a version which toggled a pin and checked with the logic analyzer. Indeed, there is a small variation (agreeing with the above figures).
So we really need to ask: why 108 to 116 (difference of 6) and not just 113 every time? Well, back to the datasheet (page 253):
When initiating a single ended conversion by setting the ADSC bit in ADCSRA, the conversion starts at the following rising edge of the ADC clock cycle.
OK, so since "a cycle" in this case will be 8 uS we can see a range will be required (maximum 8) because we are looking for that rising edge of the ADC clock.
So it would be fair to say the analogRead will take 104 uS plus up to 8 uS extra depending on where the ADC clock is when the conversion starts. However, not at all data dependent.