next topic »

[Reply #30 on:]

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.

[Reply #31 on:]

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

[Reply #32 on:]

Code:

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.

[Reply #33 on:]

jraskell, what was the input signal for that test?

[Reply #34 on:]

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.

[Reply #35 on:]

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:

http://en.wikipedia.org/wiki/Ban_hammer

[Reply #36 on:]

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.

[Reply #37 on:]

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.

[Reply #38 on:]

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:

Code:

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.

[Reply #39 on:]

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.

[Reply #40 on:]

http://www.maxim-ic.com/app-notes/index.mvp/id/1080

having researched this a bit, it is indeed one cycle per bit as someone pointed out above. I was mistaken in thinking the conversion time of succ. approx depended on the data.

Thanks to Nick for demonstrating with full scale input.

9.1.5
ADC Clock – clkADC
The ADC is provided with a dedicated clock domain. This allows halting the CPU and I/O clocks
in order to reduce noise generated by digital circuitry. This gives more accurate ADC conversion
results.

ADC Noise Reduction
Mode
When the SM2..0 bits are written to 001, the SLEEP instruction makes the MCU enter
ADC Noise Reduction mode, stopping the CPU but allowing the ADC, the External Inter-
rupts, the Two-wire Serial Interface address watch, Timer/Counter2 and the Watchdog
to continue operating (if enabled). This sleep mode basically halts clkI/O, clkCPU , and clk-
, while allowing the other clocks to run.
FLASH

Atmel state that the CPU clock can be halted for noise reduction mode while doing ADC. So it is not using the CPU clock.


That still leaves the question of what this means:

24.1
 Features
•
 10-bit Resolution
•
 0.5 LSB Integral Non-linearity
•
 ± 2 LSB Absolute Accuracy
•
 13 - 260 μs Conversion Time
•
 Up to 76.9 kSPS (Up to 15 kSPS at Maximum Resolution)

76.9k seems to match 13us , that means adc clock of 1MHz based on 13 cycles.

but what does the proviso "at Maximum Resolution" imply? What is the resolution at 76.9 kS/s ?

Why the "up to" ?  Does this mean those speeds can be obtained reliably using maximum cpu clock and minimum adc divider ratio. Perhaps "upto" just means if the cpu is not loaded doing anything other than the sampling.

[Reply #41 on:]

Atmel state that the CPU clock can be halted for noise reduction mode while doing ADC. So it is not using the CPU clock.

You need to read that statement carefully. The clock is running ("while allowing the other clocks to run") but the CPU is not being clocked from it.

Let's put it another way. There is a basic clock, which could be the crystal or the internal oscillator. Other clocks are derived from it. With the CPU asleep the clock is running (in some modes anyway) but the CPU is not being clocked from it. However (in this case) the ADC is still being clocked. So it is not "using the CPU clock" per se, but it is using the CPU clock rate.

So, the fundamental clock rate, used by the CPU, is also used by the ADC.

(There is also a secondary clock for the watchdog timer).

[Reply #42 on:]

As for your other questions, for maximum resolution we appear to need an ADC frequency of 50 kHz to 200 kHz, and the default prescaler (set in init) of 128 is the only one that falls in that range (125 kHz). The next prescaler (64) would give use 250 kHz which is too fast.

I can't really see where they say what resolution loss you get at higher frequencies, except page 323, which appears to indicate that a (ADC) clock rate of 1 MHz would give an error of 4.5 bits.

[Reply #43 on:]

Thanks, I just found that.

23.4
Prescaling and Conversion Timing

By default, the successive approximation circuitry requires an input clock frequency between 50
kHz and 200 kHz to get maximum resolution. If a lower resolution than 10 bits is needed, the
input clock frequency to the ADC can be higher than 200 kHz to get a higher sample rate.

Seems the 250us figure comes from the _slowest_ acceptable ADC clock of 50kHz that will give full 10b resolution, so that explains that part.

13us is the 1MHz clock but outside the range giving 10b resolution.

 200kHz x 13 = 65us  would seem to be the fastest 10b sampling freq.  sounds like this is the freq limit of required accuracy from the comparator, so running at 250kHz (52us) would probably introduce some small additional error (prob < 1LSB ?) into the conversion.

So to get full spec it looks like we're limited to the 104us figure you originally stated as the only "choice".

Thanks for you help in getting to the bottom of all this.

[Reply #44 on:]

200kHz x 13 = 65us  would seem to be the fastest 10b sampling freq.  sounds like this is the freq limit of required accuracy from the comparator, so running at 250kHz (52us) would probably introduce some small additional error (prob < 1LSB ?) into the conversion.

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

Also check out:

http://www.openmusiclabs.com/learning/digital/atmega-adc/

Even has a nice graph of resolution vs frequency.

Bear in mind the datasheet quotes 2 bits of error even at 200 kHz.

Also:

http://www.openmusiclabs.com/learning/digital/atmega-adc/in-depth/

Thanks for you help in getting to the bottom of all this.

You are welcome, I think we all learned something here.