CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
ADC clock period TAD for the PIC18F26K22

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Tom-H-PIC



Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE

View user's profile Send private message

ADC clock period TAD for the PIC18F26K22
PostPosted: Wed Feb 22, 2012 7:05 am     Reply with quote
Ok this ADC clock and TAD thing with the PIC controllers has always confused me.
Ok I have search the forum and read all I can find on ADC TAD.
I just want to make sure that I understand TAD correctly and need some conformation of that is all.

I'm using the PIC18F26K22
Internal oscillator of 8Mhz and PLL fuse set for a FOSC of 32Mhz.

In looking at the data sheet table 17-1 it looks like the minimum TAD for full conversion is 1.0us?
So from the table and my FOSC of 32 I would use an ADC clock of FOSC/32?
This would give me a TAD time of 1us?
So ADC requires 11 TAD cycles for a 10 bit conversion so that equals 11us for one full 10 bit ADC reading?
Now add the TAQT time of 4us and the discharge time of 2us that give use a total ADC tome of 17us?

If the above is correct.
The max ADC speed of 58.8Khz ignoring code overhead.

So if I code a loop to read the ADC 50 time the program would delay at that location for 50x17us=850us ignoring code overhead?

Thanks for all you input in advance!
Tom
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

Re: ADC clock period TAD for the PIUC18F26K22
PostPosted: Wed Feb 22, 2012 7:44 am     Reply with quote
Tom-H-PIC wrote:

I'm using the PIC18F26K22
Internal oscillator of 8Mhz and PLL fuse set for a FOSC of 32Mhz.

In looking at the data sheet table 17-1 it looks like the minimum TAD for full conversion is 1.0us?


Yes. Most 16 and 18 series PICs work at this speed. Some a little faster, some a little slower, but we could say the standard 8/10 bit ADC block used by Microchip is clocked at 1MHz.

Quote:

So from the table and my FOSC of 32 I would use an ADC clock of FOSC/32?

Yes.
Quote:

This would give me a TAD time of 1us?

Yes.
Quote:

So ADC requires 11 TAD cycles for a 10 bit conversion so that equals 11us for one full 10 bit ADC reading?

Yes.
Quote:

Now add the TAQT time of 4us and the discharge time of 2us that give use a total ADC tome of 17us?

Hmm, the worked example in the data sheet (41412E) suggests that we should allow something like 7.5us for Tacq. I'm not sure what you mean by "discharge time". I'd suggest waiting 8us, preferably by setting ACTQ to 8, or TAD_8_MUL in CCS speak. This makes the hardware wait 8 TAD periods before sampling, allowing you to select a channel and then immediately follow it with the start of a conversion. I make the total 19us, but call it 17us if you fell that's OK.
Quote:

If the above is correct.
The max ADC speed of 58.8Khz ignoring code overhead.

Yes... but code overhead is very significant and hard to ignore in practise.
Quote:

So if I code a loop to read the ADC 50 time the program would delay at that location for 50x17us=850us ignoring code overhead?

Yes for short bursts. That's assuming you are not doing anything with the data and there are no interrupts. You can do something with the result if you start the conversion, continue with processing while the ADC is converting, and then read the data and then triggering the next conversion. Also your conversion rate is not fully fixed. Interrupts can, and will lengthen some loops. Any processing may introduce timing changes: jitter. In short using such a software controlled ADC conversion loop has many problems. If you want to convert at a known and fixed, reliable interval, and MOST useful applications require it, then you're going to have to use special event triggering at a somewhat slower rate and poll or use interrupt on ADC DONE to recover the data. You can sensibly convert bursts of data at fixed rates the software only way by turning off interrupts and carefully coding to make sure all code between conversions is guaranteed to be the same length; which pretty much means no ifs.

RF Developer
Tom-H-PIC



Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE

View user's profile Send private message

PostPosted: Thu Feb 23, 2012 7:49 am     Reply with quote
Thanks
RF_Developer for clarifying all this for me.
Tom
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group