next topic »

[Reply #15 on:]

If I'm limited to circa 200us per sample I may be as well using a ...

An ADC conversion takes 104 uS, and you can do it asynchronously. That is, do other stuff in the meantime.

As for your original point, I am staggered that to install something like Windows Vista requires something like one Gigabyte (yes, I'm not joking) of RAM.

http://windows.microsoft.com/en-us/windows-vista/products/system-requirements

So 1 Gb for something that "does nothing". You are getting off lightly with 1084 bytes.

The thing about things like digitalWrite is that it can write to a pin defined by a variable. So straight away it needs a table of pins to port mappings. And per port, bits. But as the others have pointed out, once you have the basic libraries there (and you don't have to use them) the memory usage goes up slowly.

[Reply #16 on:]

An ADC conversion takes 104 uS, and you can do it asynchronously. That is, do other stuff in the meantime.

I looked at the spec for the 328 and it said between 35 and 250us. If I'm working out how fast I can sample a obviously need to take the worst case figure, where did you get 104? Is that an empirical result?

What is the accuracy of the result when running async ? It does not even seem to be included in the spec. All figures are given with the rest of processing shut down. I doubt that they would have provided separate clocks and means to shut down the rest of the chip if it did not make a significant difference.

It makes sense , having the ADC on the same piece of silicon with all the digital circuitry must be a horrendously noisy environment.

Now the ADC is 10b with 2LSB of error in quiet mode. That's 9 bit accuracy ADC.

If I run async what am I going to get? If they don't even put it in the spec sheet, it seem fair to assume it ain't that good. That may be OK for "fun" projects but it will not give an accurate enough result for what I need.

I will have to see if I can work with 5-10 kSps but it's about on order of magnitude below what I had originally intended.

Could you clarify the 104us ? Thanks.

[Reply #17 on:]

If I run async what am I going to get?

I don't know anything about the accuracy of ADCs, but the accuracy of running it async is the same as running it with the analogRead function, since analogRead doesn't sleep the chip. It just goes into a busy wait.

[Reply #18 on:]

If I'm working out how fast I can sample a obviously need to take the worst case figure, where did you get 104?

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

Is that an empirical result?

No.

What is the accuracy of the result when running async ?

The same as running synchronously.  There is not a special asynchronous converter.

I doubt that they would have provided separate clocks and means to shut down the rest of the chip if it did not make a significant difference.

The point is to reduce the effect of noise not increase the accuracy.

Now the ADC is 10b with 2LSB of error in quiet mode. That's 9 bit accuracy ADC. If I run async what am I going to get?

The same.

[Reply #19 on:]

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

So why does the atmel spec sheet say 35 to 250 us, are you saying they are incorrect?

For the rest of you comments try to understand the difference between the terms resolution and accuracy and reply again to my question.

[Reply #20 on:]

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.

[Reply #21 on:]

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.

[Reply #22 on:]

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

[Reply #23 on:]

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.

[Reply #24 on:]

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.

[Reply #25 on:]

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.

[Reply #26 on:]

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

[Reply #27 on:]

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.

[Reply #28 on:]

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.

[Reply #29 on:]

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.