PDA

View Full Version : ADC sampling time



flotulopex
- 22nd March 2008, 14:07
Hello,

I was wondering why the time I measure(1) for one ADC sampling channel is that much greater than the one stated on the datasheet?

The oscillo sais around 113µs.
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2433&stc=1&d=1206192368">

My PIC has a 4MHz XTal and Fosc is set to 16. Shouldn't I get something like 4µs (green zone)?
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2434&stc=1&d=1206191664">

(1): my oscillo triggers a port that is being set before and cleared after the ADC process. Is it not a valid measurement?

Acetronics2
- 22nd March 2008, 14:25
Hi, Lazy Roger

Go on your datasheet reading to $ 9.1.5 ...

Hé, oui ... faut TOUT lire ...

Alain

dhouston
- 22nd March 2008, 15:41
From datasheet 9.1.4...

"The time to complete one bit conversion is defined as
TAD. One full 10-bit conversion requires 11 TAD periods
as shown in Figure 9-2."

flotulopex
- 22nd March 2008, 17:33
Not always lazy: most of the time, I'm hungry... of knowledge ;)

Okay, looking at tables "17-18" and "17-16" and if my (too) modestly developped brain understands what seems to be so obvious, I would calculate the aquisition time like this:

- aquisition time (param. 132) is 11,5µs;
- converstion time (param. 131) is 11Tad (param. 130) @ 3µs each(full range), makes 33µs.

All in all the total calculated time gives 11,5µs + 33µs = 44,5µs.

I'm still missing something, or at least 113µs - 44,5µs = 68,5µs.

Is my PIC getting as rest???

skimask
- 22nd March 2008, 18:24
Is my PIC getting as rest???
Your code is probably setting a few bank select registers, doing some gosub'ing and return'ing during all of this. But that would still only account for a handful of the 'missing' cycles.
Post the code that's running this. Maybe those missing cycles are laying around in there...

flotulopex
- 22nd March 2008, 19:00
Here it is:

' PIC 16F690 Fuses
@ DEVICE FCMEN_OFF
@ DEVICE IESO_OFF
@ DEVICE BOD_ON
@ DEVICE CPD_OFF
@ DEVICE PROTECT_OFF
@ DEVICE MCLR_OFF
@ DEVICE PWRT_OFF
@ DEVICE WDT_OFF
@ DEVICE HS_OSC

'-------------------------------------------------------------------------------
' Registers 76543210
OPTION_REG = %10000101 'PORT A&B Pull-Ups disabled (look WPUA & WPUB)
ANSEL = %00000001 'Select analog inputs Channels 0 to 7
ANSELH = %00000000 'Select analog inputs Channels 8 to 11
ADCON0 = %10000010 'A/D Module is ON (Bit5:2 select channels 0:11)
ADCON1 = %00010000 'A/D control register
CM1CON0 = %00000000 'Comparator1 Module is OFF
CM2CON0 = %00000000 'Comparator2 Module is OFF
INTCON = %00000000 'INTerrupts CONtrol (TMR0 ON)
TRISA = %00000001 'Set Input/Output (0 to 5)
PORTA = %00000000 'Ports High/Low (0 to 5)
TRISB = %00000000 'Set Input/Output (4 to 7)
PORTB = %00000000 'Ports High/Low (4 to 7)
TRISC = %00000000 'Set Input/Output (0 to 7)
PORTC = %00000000 'Ports High/Low (0 to 7)

'-------------------------------------------------------------------------------
' Defines
DEFINE ADC_BITS 10 'Number of bits in ADCIN result

'-------------------------------------------------------------------------------
' Variables
Volt var word
Check var PORTB.6 'I use this one to measure the ADC start/end

'-------------------------------------------------------------------------------
' Program
MAIN:
check = 1
adcin 0, volt
check = 0
goto MAIN
end

NB: is there a way to make the code appear with the same text formatting as I have in MCS?

Acetronics2
- 22nd March 2008, 19:06
Hi, Roger

just open PbPic14.lib and look at ALL ADCIN does ... plus the DEFINE ADC SAMPLEUS @ 50µs ...

Don't cry, Roger ... we love you !!!

Alain

flotulopex
- 22nd March 2008, 19:26
I love myself too!

I knew the fish was somewhere...

Cool and thanks again.

Alain, I hope you'll still have a good sleep after my annoying questions.... ;)

tenaja
- 22nd March 2008, 22:16
Read the help file on ADCIN. There is a define that sets the acquisition time (not conversion time), and the default is very long.

If you want fast code, do it all manually so you do not have to delay (doing nothing) during acquisition, but instead, perform math or some other task while that cap charges.

skimask
- 22nd March 2008, 22:33
Try this and see how fast it runs:

' PIC 16F690 Fuses
@ DEVICE FCMEN_OFF
@ DEVICE IESO_OFF
@ DEVICE BOD_ON
@ DEVICE CPD_OFF
@ DEVICE PROTECT_OFF
@ DEVICE MCLR_OFF
@ DEVICE PWRT_OFF
@ DEVICE WDT_OFF
@ DEVICE HS_OSC
option_reg = $85 : ansel = 1 : anselh = 0 : adcon0 = $82 : adcon1 = $10
cm1con0 = 0 : cm2con0 = 0 : intcon = 0 : trisa = 1 : porta = 0 : trisb = 0
portb = 0 : trisc = 0 : portc = 0 : volt var word : check var portb.6
adtrigger var adcon0.1
MAIN: check=1 : adtrigger = 1 'start the ADC conversion
waitforit: if adtrigger = 1 then waitforit 'not done converting yet
volt.highbyte = adresh : volt.lowbyte = adresl : check = 0 : goto MAIN
end

Charles Linquis
- 23rd March 2008, 04:26
If you need to do continuous A/D conversions, you can set up a program loop counter that counts to 3. On the first pass, you change the ADC channel. On the second pass, you start the conversion. On the third pass, you read the result...

Doing things this way makes the A/D conversion take essentially zero program time. Just make sure that you program loop time is longer than the A/D needs between the steps. If not, you might have to choose different "trigger" values for the loop counter. For example: you might have to set-up the channel on loop #1, start the conversion on loop #6, and read the result on loop #12.

This technique doesn't work in all situations, but works very well most of the time.