Go Down

### Topic: code size (Read 7335 times)previous topic - next topic

#30
##### Jul 12, 2012, 09:46 pm
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.

#31
##### Jul 12, 2012, 09:56 pm
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.

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

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

#32
##### Jul 12, 2012, 10:34 pm
Code: [Select]
`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.

#### ardnut

#33
##### Jul 12, 2012, 11:16 pm
jraskell, what was the input signal for that test?

#### AWOL

#34
##### Jul 12, 2012, 11:34 pm
Do you seriously think it matters?

Quote
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.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.
I speak for myself, not Arduino.

#### nickgammon

#35
##### Jul 12, 2012, 11:46 pm

If you can't I suggest you learn some better manners before threatening people with mallets.

It's a Ban Hammer, not a mallet.

http://en.wikipedia.org/wiki/Ban_hammer
Please post technical questions on the forum, not by personal message. Thanks!

#### nickgammon

#36
##### Jul 12, 2012, 11:49 pm

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.
Please post technical questions on the forum, not by personal message. Thanks!

#37
##### Jul 12, 2012, 11:54 pm

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.

#### nickgammon

#38
##### Jul 13, 2012, 12:01 am
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: [Select]
`752830897949981995989964919857781695599501403309223149895228161835641051712493364305326297218068769329729939939739358808077276355364383422541708843201939831422443624906207418469269789979799298507456244953662471467233162050971652693905206487678689429869959709128257165914613332191255726162863118210323449578703814905966994987947876780663533402280175904420163776137235352480611733840922975995980932853750630501373253151763617214795159264385514643762863939983995972916832722600470342224129602715265911120331644257269780990096299398995188278466954241128817994472116347313222934647360272583391997399598393686075963950837925815679371719449015425537850463575685893598299597592183672960747735023213664301625551081963074325626908038969609929919558887926765494192941869851221632701262233394665977208299139709959849408657646475173882671628240171741851482493694976267478519319799959759248427386164843562381396731162453105191301426556682797890957991991957891799685558425300190103431916377813923835548361373584192497699598093185375062949936824914873341620489516326538651564376586594098499597091583071959646633822312759251527601142043184445736998139029649939899508807846685394082851789547211735761342303464776067298369199739969839358577556365063782571567736172046921582583805086377578599359839959739198357286054763462291336329152657108199311436566692805896960992989952885789674546417290182974922163370129225340468597720831916972995984939864763642513385263160823918204287149251370501631751854932980995976922840735612483355237139653115245410619230242756068679989295899199195688879568155442429919010343191838801402403574856177388449249759959809308507466254963672481477233162248981622683895196487668659419849949699128277185954653372211255826152661115206320446577702813902964993988948877781664538406283175924620163676135234351479608731838922975996981934857754634503373254152763517204692157259380509639759861937983994973918832725601472344228132612815265811120131343856869680889996399398995288478667154441428918296492116347313022534347060172483291697299598393786376164251238326216079381819448915325537550363275285593298199597592083873361047935123313664301625551061953064315616868018939589919909548877936795524202961871004219173981142243361489618740845926977995978928849744623494363245145703216225098166270391521648767868943985994969912825714590461333219124562515286211720932144857870381690496599398794787677866053340228017491452017367813723535248261273484192397599698193285475163050137225315274351721479416026438551464276186293898499497191583172259947034222512960271727601122043154425726978099009639939889518827856695424132861799447211634731342293464736037258349199739949839378607586395083792591567837182044911542543755056357558579349819969749208377306074783502321356329162557108197308433565691804Min: 108Max: 116Avg: 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):

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

Please post technical questions on the forum, not by personal message. Thanks!

#### nickgammon

#39
##### Jul 13, 2012, 12:06 am

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.
Please post technical questions on the forum, not by personal message. Thanks!

#### ardnut

#40
##### Jul 13, 2012, 12:53 amLast Edit: Jul 13, 2012, 12:56 am by ardnut Reason: 1
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.

Quote

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

Quote

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:
Quote

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.

#### nickgammon

#41
##### Jul 13, 2012, 01:00 am

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).
Please post technical questions on the forum, not by personal message. Thanks!

#### nickgammon

#42
##### Jul 13, 2012, 01:31 am
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.
Please post technical questions on the forum, not by personal message. Thanks!

#### ardnut

#43
##### Jul 13, 2012, 01:59 am
Thanks, I just found that.

Quote

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.

#### nickgammon

#44
##### Jul 13, 2012, 02:13 am

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:

Even has a nice graph of resolution vs frequency.

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

Also: