GetADC Conversion time on mega328

jboavida · Joined: 12 Feb 2005 Posts: 94 Location: Portugal

Hello,
Does anyone know the actual time that getadc() function needs to return a value?
Assuming a 14745600 oscillator, whit a prescaler of 128 will give an ADC clock of 115.200Khz.
The ADC takes 13 clock cycles to convert so it will be a conversion rate of about 8.8Khz giving a result every 114 uS (more or less)
I«m assuming that the getadc() function will add some more cycles. Does anyone know?
Can I consider for example 200uS to be a "safe" conversion time?

I need to switch off a LED panel and read an ambient light sensor in the shortest time possible. This way LED's wont alter the light reading value.

Thanks in advance.

JB

(BASCOM-AVR version : 2.0.8.3 )

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Hi
At this prescaler about 242us
If you change it to 64 so 171us

RS

jboavida · Joined: 12 Feb 2005 Posts: 94 Location: Portugal

Thanks for your answer.

I think 242us it is ok. I don't want to change the prescaler to a lower value, because it will fall off the 200Khz maximum recommend ADC clock range.

Regards
JB

hgrueneis · Joined: 04 Apr 2009 Posts: 902 Location: A-4786 Brunnenthal

The ADC is actually read twice. You can change that to one reading but need to do a dummy read at turn on.
Mark explained that some years ago.
You can also go higher with the ADC-clock. The result is that you will have a bit higher error in reading. I tested it to 1MHz and for some applications it is OK.

Regards
Hubert

JC · Joined: 15 Dec 2007 Posts: 586 Location: Cleveland, OH

You may well have already soved your question, but I'll add a comment about measuring software timing.

One approach is to load the program into a simulator count instructions and clock cycles.
That is very accurate, but still some work is required, and there is a learning curve for doing this.

An easier approach that I often use when wanting to look at timing for ISRs, etc., is to measure the timing with an O'scope.

Even a "toy" O'scope can be used to measure the duration of a section of code very easily.
Simply set a spare I/O pin high when you enter the code, clear it before you exit the code.
Then measure the pulse width on the O'socpe.

This actually gives one an estimate, as if one is measuring an ISR there is some overhead to push and pop, (save and restore), some registers when entering and exiting the ISR.
That time isn't include in the pulse width.

One doesn't need an expensive O'scope to do this.
A cheap O'scope "kit", $17 USD, from Banggood Electronics, for example can do this easily.

JC

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Or use a clone of the logic analyzer that does a slightly better job than the oscilloscope in this case.
The advantage is also the higher sampling frequency and the possibility of automatic bus decoding.
We do the rest the same.
I would just draw attention to the fact that not all simulators are capable of counting time according to a set frequency.

RS

p.s Sorry, I didn't realize. Deleted inappropriate ad.

EDC · Joined: 26 Mar 2014 Posts: 971

Do you must probe more than one input? This is really question.

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Hi EDC
if there was a question to me then in this case I do not need. But in other cases quite often I have to. And I must admit that often these 8 inputs are not enough.
The logical analyzer has the advantage of know what he expects from it. the state is clear log0 or log1 nothing between that.
In the case of a digital oscilloscope, if I don't know what to see then I'm often surprised by the signal. When I take the standard osciloscope referred to above, tz DSO from China, I have a few options what to choose. At the price it will be DSO138 or equivalent. If you look at the parameters (they are quite limited used STM32) then for standard measurements on processors is simply better logical analyzer.
Everyone is used to what they have, or to what they have. It is ideal to use what is intended for this purpose. In this case, the price also helps.
That's my look at the matter.

RS

AdrianJ · Joined: 16 Jan 2006 Posts: 2483 Location: Queensland

You should consider also the turnoff time of the LED panel, and what sort of LEDs they are ( white phosphor, or direct output ). Probably much shorter than the ADC conversion time, but worth checking.

See https://electronics.stackexchange.com/questions/86717/what-is-the-latency-of-an-led

for some discussion.

Alternately, if your LED panel is only for human visual illumination, I doubt you would even detect an ON-OFF-ON blank time of less than 1 msec or so. Visual persistence is much longer than that.

JC · Joined: 15 Dec 2007 Posts: 586 Location: Cleveland, OH

The nitty-gritty details...

Although it is an interesting exercise to measure the time required to acquire the ADC reading, I'm not sure it is really necessary, particularly if one uses the data sheet to see how to trigger and read the ADC reading without using the Bascom instruction.

The ADC includes a Sample and Hold, to capture the input analog voltage and hold it stable while the ADC circuitry calculates its value.

The ADC triggers the S&H either 1.5 or 2 clock cycles after the trigger, depending upon the ADC mode being used.
I don't see that the data sheet specifically states the duration of the S&H function, but depending upon the HW design it is likely edge triggered, (and therefore "instantaneous"), or takes 1 clock cycle, or takes 2 clock cycles.

But the point is one can turn the LED ( s ) back on well before the actual ADC reading is completed, if one really wanted to minimize their Off time.
The sensor has already been sampled, and a change in its output won't effect the conversion value after the S&H has sampled the value.
To do that, however, one would need to manually trigger and read the ADC, and not use the High Level Bascom ADC command, as if one is using that one has to wait for it to finish before executing another instruction.

And, assuming that the OP just wants to Keep It Simple and use the Bascom ADC instruction, the timing is again in the uSec range, so the human eye won't even see the flicker. Remember that the human eye is a (very slow) opto-chemical sensor, so it can't respond to (i.e. can't see), a very brief flicker, (either on or off), of the LED.

One can see the Wiki on Persistence of Vision for a lot more information on the topic.

Good luck with your project!

JC

Edit: Opps. Sorry. On the device I was browsing with I missed Adrian's comments on the persistnece of vision, they were off the bottom of my screen.
Otherwise I wouldn't have re-menntioned it!

JC

EDC · Joined: 26 Mar 2014 Posts: 971

In the programm you dont need to wait for the conversion...
This can even be a Interrupt source but if not needed then maybe this will be sufficient.
Simplified version below...

jboavida · Joined: 12 Feb 2005 Posts: 94 Location: Portugal

Thanks all for the answers. The project is working as expected thanks to all your tips.
Help much appreciated.

Joaquim

enniom · Joined: 20 Oct 2009 Posts: 537

Hello jboavida

Don't you think it would be appropriate to post the final solution example after so many people spent their time to help you find a solution?

jboavida · Joined: 12 Feb 2005 Posts: 94 Location: Portugal

Hi, enniom

You are absolutely right. Ita was my fault.
There is no special code. Essentially I took the human eye persistent approach.