ADC Conversion Rate

[jecottrell]

Hello All,

I've been doing some reading and have tried to decide what the maximum rate I'll be able to acquire an analog signal on a 18F2525 part running at 20mHz would be.

I see that the acquisition time is about 2.5uS, which shouldn't be a factor for my desired rate.

My initial plan is to sample and store a number of readings in FRAM for later use. So I have concluded that the limiting factor is going to be the transfer of the data from the PIC to the FRAM. Is there anyone with any experience willing to spoon feed me the time that is going to take? I plan on using the ADC in the 10bit mode and transfering 2 bytes for each reading.

Also, I would assume for a signal acquisition scheme the ADC acquisition timing would be best handled by an interrupt/timer to ensure accuracy of the timing of the acquisition?

Thanks in advance for any advice,

John

[Ttelmah]

The first 'acquisition time', is dependant on the impedance of your source. It is the time taken for the internal capacitor to charge to within half a bit of the incoming voltage. It falls to 2.4uSec, assuming that your enviroment meets the laid down guidelines. However you then have the time needed to actually take the reading (also called the acquisition time in some parts of the data sheet, just to confuse you...). This is 11*Tad. Tad, should not normally be less than 0.69uSec, and depending on your clock rate, and available multipliers, may well be higher. So the total time for a sample, is the charge time, plus this sample time, giving a 'fastest possible' for the PIC, of 10uSec/sample.
You will then need to read this value, and send it to FRAM. Conveniently, if you don't use the automatic acquire delay, the input will be recharging while this transfer takes place, allowing a slight saving on the total. Depending on your FRAM, with one of the 25MHz SPI versions, the byte transfer, can be as quick as 1.6uSec/byte.
So If you read the byte, send it to the output register, wait 2.5uSec, read the next byte, send this, and as soon as this is done, trigger another ADC reading, waiting for this to end, the second byte will be sending, while you wait for the ADC, while the ADC will be charging, while the first byte transfers. The ADC reading will take 8.8uSec (with your 20MHz clock, the fastest Tad value available, will be clock/16, giving Tad=0.8uSec), by which time the byte will have sent.
Now you will have to add typically four instruction times to 'poll' the ADC, and a couple of instruction times for the readings, plus a couple more for the overall loop, so it should be possible to do the total cycle in about:
2.5+8.8+4uSec
Say 16uSec.
Now this is assuming that you are able to just let the memory automatically increment through a memory block. If you start having to set an address, timings will shoot up. Fortunately, with FRAM, you can just keep writing till the memory is full,there is not a 'block size' like on EEPROM. There is also the problem of noise. Since in this fastest mode, you will actually be clocking a byte out of the chip, while the reading being made, there will be a tendency to pickup some of this signal as noise in the ADC reading.
You will probably actually have to run an int16 counter, to stop the program when the memory is full, and this would add perhaps another couple of uSec to the total. I'd say that 20uSec, should 'comfortably' be achievable.

Best Wishes

[jecottrell]

RJ,

Thanks for the help. I had reached some of the conclusions you had provided after posting but couldn't really quantify them. It became obvious about 10uS after hitting the submit button that I could essentially multitask by acquiring and writing simultaneously. I found some material somewhere mentioning the "code noise" problem with the on-board adc.

If my aging math skills serve me correctly, 1/20uS gives me a sample rate of 50,000SpS. Luckily this is well above what I think I'll need. I think I'll probably only need about a tenth of that.

But... I think now I have concluded after using FilterLab to check a couple of things the 10bit ADC won't be able to resolve the signal that I'm looking for with the expected SNR. So... I may have to go to an external ADC. But I think with the info that you have provided I should be able to figure out what's going on.

Thanks,

John