code size

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.

Are you being serious??

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.

Are you being serious??

Are you being a troll?

RTFM.

So why does the atmel spec sheet say 35 to 250 us

It doesn't; it says 13 to 260us

Where do you get your stated 13 cycles from?

Datasheet - 21.4:

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:
ADC on these chips is succ. approx, the time to convert depends upon the data.

That's complete nonsense. Read the datasheet:

A normal conversion takes 13 ADC clock cycles.

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.

Nick Gammon says:

I strongly suggest you read the data sheet before insulting people here, lest trouble falls.

Where's the insults ?! The only thing I see that is offensive is RTFM and it was not me that posted it.

AWOL:

Are you being serious??

Are you being a troll?

RTFM.

So why does the atmel spec sheet say 35 to 250 us

It doesn't; it says 13 to 260us

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.

AWOL:

@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:
explain why the manufacturer puts such was wide range on possible convertion times

13/125000*1000000 ...13 clock cycles / 125000 clock cycles per second * 1000000 microseconds per second.

The 125000 can be configured and depends on the processor's clock rate.

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).

void setup()
{
    Serial.begin(115200);
    unsigned int maxReadTime = 0, minReadTime = 1000, singleReadTime, ReadVal;
    unsigned long AccumulatedTime = 0;
    ReadVal = analogRead(A0);
    for(int x = 0; x < 1000; x++)
    {
        singleReadTime = micros();
        ReadVal = analogRead(A0);
        singleReadTime = micros() - singleReadTime;
        
        AccumulatedTime += singleReadTime;
        
        if(singleReadTime > maxReadTime) maxReadTime = singleReadTime;
        if(singleReadTime < minReadTime) minReadTime = singleReadTime;
        
    }
    
    Serial.print("Min: ");
    Serial.println(minReadTime);
    Serial.print("Max: ");
    Serial.println(maxReadTime);
    Serial.print("Avg: ");
    Serial.println(AccumulatedTime/1000);
    
}


void loop()
{
    
}

Running that code, I get the following output (thereabouts anyways, there is some occasional variation)
Min: 112
Max: 124
Avg: 116

Comment out the initial analogRead, and you'll see Max jump to around 212, which nicely correlates with the 25 cycles for the initial conversion.

There is simply no rational arguing with empirical data.

jraskell, what was the input signal for that test?

Do you seriously think it matters?

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:
If you can't I suggest you learn some better manners before threatening people with mallets.

It's a Ban Hammer, not a mallet.

Here, read about them:

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.

ardnut:
jraskell, what was the input signal for that test?

Input signal doesn't matter. Tie it to ground, to 5v, set up a voltage divider with a pot. The results won't vary.

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.

Output:

752
830
897
949
981
995
989
964
919
857
781
695
599
501
403
309
223
149
89
52
28
16
18
35
64
105
171
249
336
430
532
629
721
806
876
932
972
993
993
973
935
880
807
727
635
536
438
342
254
170
88
43
20
19
39
83
142
244
362
490
620
741
846
926
978
997
979
929
850
745
624
495
366
247
146
72
33
16
20
50
97
165
269
390
520
648
767
868
942
986
995
970
912
825
716
591
461
333
219
125
57
26
16
28
63
118
210
323
449
578
703
814
905
966
994
987
947
876
780
663
533
402
280
175
90
44
20
16
37
76
137
235
352
480
611
733
840
922
975
995
980
932
853
750
630
501
373
253
151
76
36
17
21
47
95
159
264
385
514
643
762
863
939
983
995
972
916
832
722
600
470
342
224
129
60
27
15
26
59
111
203
316
442
572
697
809
900
962
993
989
951
882
784
669
542
411
288
179
94
47
21
16
34
73
132
229
346
473
602
725
833
919
973
995
983
936
860
759
639
508
379
258
156
79
37
17
19
44
90
154
255
378
504
635
756
858
935
982
995
975
921
836
729
607
477
350
232
136
64
30
16
25
55
108
196
307
432
562
690
803
896
960
992
991
955
888
792
676
549
419
294
186
98
51
22
16
32
70
126
223
339
466
597
720
829
913
970
995
984
940
865
764
647
517
388
267
162
82
40
17
17
41
85
148
249
369
497
626
747
851
931
979
995
975
924
842
738
616
484
356
238
139
67
31
16
24
53
105
191
301
426
556
682
797
890
957
991
991
957
891
799
685
558
425
300
190
103
43
19
16
37
78
139
238
355
483
613
735
841
924
976
995
980
931
853
750
629
499
368
249
148
73
34
16
20
48
95
163
265
386
515
643
765
865
940
984
995
970
915
830
719
596
466
338
223
127
59
25
15
27
60
114
204
318
444
573
699
813
902
964
993
989
950
880
784
668
539
408
285
178
95
47
21
17
35
76
134
230
346
477
606
729
836
919
973
996
983
935
857
755
636
506
378
257
156
77
36
17
20
46
92
158
258
380
508
637
757
859
935
983
995
973
919
835
728
605
476
346
229
133
63
29
15
26
57
108
199
311
436
566
692
805
896
960
992
989
952
885
789
674
546
417
290
182
97
49
22
16
33
70
129
225
340
468
597
720
831
916
972
995
984
939
864
763
642
513
385
263
160
82
39
18
20
42
87
149
251
370
501
631
751
854
932
980
995
976
922
840
735
612
483
355
237
139
65
31
15
24
54
106
192
302
427
560
686
799
892
958
991
991
956
888
795
681
554
424
299
190
103
43
19
18
38
80
140
240
357
485
617
738
844
924
975
995
980
930
850
746
625
496
367
248
147
72
33
16
22
48
98
162
268
389
519
648
766
865
941
984
994
969
912
827
718
595
465
337
221
125
58
26
15
26
61
115
206
320
446
577
702
813
902
964
993
988
948
877
781
664
538
406
283
175
92
46
20
16
36
76
135
234
351
479
608
731
838
922
975
996
981
934
857
754
634
503
373
254
152
76
35
17
20
46
92
157
259
380
509
639
759
861
937
983
994
973
918
832
725
601
472
344
228
132
61
28
15
26
58
111
201
313
438
568
696
808
899
963
993
989
952
884
786
671
544
414
289
182
96
49
21
16
34
73
130
225
343
470
601
724
832
916
972
995
983
937
863
761
642
512
383
262
160
79
38
18
19
44
89
153
255
375
503
632
752
855
932
981
995
975
920
838
733
610
479
351
233
136
64
30
16
25
55
106
195
306
431
561
686
801
893
958
991
990
954
887
793
679
552
420
296
187
100
42
19
17
39
81
142
243
361
489
618
740
845
926
977
995
978
928
849
744
623
494
363
245
145
70
32
16
22
50
98
166
270
391
521
648
767
868
943
985
994
969
912
825
714
590
461
333
219
124
56
25
15
28
62
117
209
321
448
578
703
816
904
965
993
987
947
876
778
660
533
402
280
174
91
45
20
17
36
78
137
235
352
482
612
734
841
923
975
996
981
932
854
751
630
501
372
253
152
74
35
17
21
47
94
160
264
385
514
642
761
862
938
984
994
971
915
831
722
599
470
342
225
129
60
27
17
27
60
112
204
315
442
572
697
809
900
963
993
988
951
882
785
669
542
413
286
179
94
47
21
16
34
73
134
229
346
473
603
725
834
919
973
994
983
937
860
758
639
508
379
259
156
78
37
18
20
44
91
154
254
375
505
635
755
857
934
981
996
974
920
837
730
607
478
350
232
135
63
29
16
25
57
108
197
308
433
565
691
804
Min: 108
Max: 116
Avg: 113

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.

AWOL:
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.

You didn't delete my Ban Hammer, I notice. :wink: