18F2553 to slow to use fast 16bit ADC AD977

Moderator: Benj

Post Reply
randomrichard
Posts: 41
Joined: Thu Oct 16, 2008 11:01 am
Has thanked: 21 times
Been thanked: 7 times
Contact:

18F2553 to slow to use fast 16bit ADC AD977

Post by randomrichard »

Hello
I was going to ask for SPI slave mode to be added to Flowcode5 to take advantage of the fast clock in the AD977. However, by using an oscilloscope and triggering the ADC via its R/barC pin with barCS tied low the fastest the PIC is able to send a trigger is about every 700microsec after cycling through the SPI code(picture 1, which shows the triggered outputs from the ADC). That is without including the USB code for sending the data onwards. The fastest sample rate for 16bit data with a PIC is therefore less than 1.5ksps.

It takes the AD977 about 7microsec to produce each 16bit data sample, a sample rate of about 100ksps, as per specification (picture 2). So most of the ADC's performance is wasted.

So it would not be worthwhile, for my application: collecting geophysical data, to add SPI slave to Flowcode for PIC
Attachments
Picture 2
Picture 2
AD977output_with_internal_clock.JPG (113.04 KiB) Viewed 7796 times
Picture 1
Picture 1
ADC output with PIC trigger.JPG (94.58 KiB) Viewed 7796 times

kersing
Valued Contributor
Valued Contributor
Posts: 2045
Joined: Wed Aug 27, 2008 10:31 pm
Location: Netherlands
Has thanked: 553 times
Been thanked: 1081 times
Contact:

Re: 18F2553 to slow to use fast 16bit ADC AD977

Post by kersing »

Hi,

I am confused. What is the issue you are trying to have addressed?

According to the data sheet the AD977 is a slave device when used in SPI mode:
"This interface assumes that the convert pulses will originate from the
microcontroller and that the AD977/AD977A will act as the
slave device."

So the PIC should be the SPI master.

If you want to read the data from the AD977 when it is providing clock (not SPI mode) you could look into using the clock as an interrupt source and sampling the data pin when the interrupt occurs.

Good luck,

Jac
“Integrity is doing the right thing, even when no one is watching.”

― C.S. Lewis

randomrichard
Posts: 41
Joined: Thu Oct 16, 2008 11:01 am
Has thanked: 21 times
Been thanked: 7 times
Contact:

Re: 18F2553 to slow to use fast 16bit ADC AD977

Post by randomrichard »

Jac
Thanks for the tip about using the ADC clock as interrupt trigger. That might well work. I wonder if I can do that using the PIC's spi registers on the SDI pin.

I see what you are saying. I have tried with both external (PIC as master) and internal clock modes (PIC essentially as slave). There is no flowcode for PIC as slave (It is on "to do list") but the PIC does need to be a slave because its SPI clock is so much slower that the ADC's. With the fastest settings I only get about 150KHz clock frequency from the SPI's SCK pin, which is more suited to temperature or mains frequency measurements than for uploading 500 16bit samples at 20,000sps. The spi clock is supposed to be Fosc/4 at its fastest, i.e. 5MHz with a 20MHz crystal. However, Fosc seems to be less than the crystal frequency by a wide margin. I have no idea why. The datasheet is obscure on this point.

Ben offered some C code on the forum in 2008 to make the spi a slave but I have no idea how to add it to my program or whether its would work.

I have got the USB serial going on the 2553 and I don't think that will be a bottleneck. It uploads data made very noisy by the overlap of the spi clock on the ADC clock, which it suppresses. If I turn the ADC clock off I get no data.

Richard

kersing
Valued Contributor
Valued Contributor
Posts: 2045
Joined: Wed Aug 27, 2008 10:31 pm
Location: Netherlands
Has thanked: 553 times
Been thanked: 1081 times
Contact:

Re: 18F2553 to slow to use fast 16bit ADC AD977

Post by kersing »

Richard,

According to the data sheet the AD977 is not an SPI master. So SPI slave code would not help.

I think a simple way to get a measurement is

Quote from the data sheet:
INTERNAL DATA CLOCK MODE
The AD977/AD977A is configured to generate and provide the
data clock when the EXT/INT pin is held low. Typically CS will
be tied low and R/C will be used to initiate a conversion “n.”
During the conversion the AD977/AD977A will output 16 bits of
data, MSB first, from conversion “n-1” on the DATA pin. This
data will be synchronized with 16 clock pulses provided on the
DATACLK pin. The output data will be valid on both the
rising and falling edge of the data clock as shown in Figure 3.
After the LSB has been presented, the DATA pin will assume
whatever state the TAG input was at during the start of conversion,
and the DATACLK pin will stay low until another
conversion is initiated.

So what I would do:
Connect dataclock to INT1 (pin 22) and data to RB0 (pin 21) Insert Interrupt component in flow chart. Set properties to interrupt on RB1/INT1, Interrupt edge select (properties button) to "falling edge of RB1/INT1". In the interrupt macro read RB0 (Input macro, signle bit 0 to .pval), and shift into UInt. Calculation: value = (value << 1) | (.pval &0x01) After 16 interrupts (so add an counter) you read the PREVIOUS sample.

Good luck,

Jac
“Integrity is doing the right thing, even when no one is watching.”

― C.S. Lewis

randomrichard
Posts: 41
Joined: Thu Oct 16, 2008 11:01 am
Has thanked: 21 times
Been thanked: 7 times
Contact:

Re: 18F2553 too slow to use fast 16bit ADC AD977

Post by randomrichard »

Jac
I'm beginning to hope the miserable weather here will last all next week so I can give what you have suggested a good try. I have attached a typical .fcf file from which the USB has been removed in a search for a faster repetition of the R/barC pulse on RC7. I had been fiddling with the timing when I saved this so it may not actually work. I can't get the chip working at a faster than divide by 4 CPU clock with a 20MHz xtal. Also, the 2553 prefers it if one compiles to hex and only then compiles to chip, usually two or three times before it sticks. I'll upload some code with your suggestions incorporated if I can get it going.
many thanks
Richard
Attachments
AD977to18F2553.fcf
(13 KiB) Downloaded 372 times

randomrichard
Posts: 41
Joined: Thu Oct 16, 2008 11:01 am
Has thanked: 21 times
Been thanked: 7 times
Contact:

Re: 18F2553 to slow to use fast 16bit ADC AD977

Post by randomrichard »

Jac
I have modified the flowcode as you suggested, and have included USB this time. The USB shows a stream of zeroes/cr at the correct rate of about 1ksps. The oscilloscope shows that the ADC's timing is OK and that a good if noisy 16bit number is output. I don't understand what .pval is and although I understand the binary operators I don't seem to be picking up the ADC data with your suggested formula. I am using interrupts on the rising clock edge because it gives more time for the bits to be read. The compiler warns that the second interrupt macro may be inaccessible but I don't see why. Your advice on the attached would be greatly appreciated.
Richard
Attachments
ADCtoUSBviaPICarchive1.fcf
(16.08 KiB) Downloaded 356 times

kersing
Valued Contributor
Valued Contributor
Posts: 2045
Joined: Wed Aug 27, 2008 10:31 pm
Location: Netherlands
Has thanked: 553 times
Been thanked: 1081 times
Contact:

Re: 18F2553 to slow to use fast 16bit ADC AD977

Post by kersing »

The compiler warned because you are trying to replace the interrupt handler macro with another in the Incoming_data macro. This can not be done.

Attached is a rewritten version of the code.
Attachments
ADCtoUSBviaPICupdated.fcf
(12.63 KiB) Downloaded 369 times
“Integrity is doing the right thing, even when no one is watching.”

― C.S. Lewis

randomrichard
Posts: 41
Joined: Thu Oct 16, 2008 11:01 am
Has thanked: 21 times
Been thanked: 7 times
Contact:

Re: 18F2553 to slow to use fast 16bit ADC AD977

Post by randomrichard »

Jac
Thanks for the interrupt code which, however, I was unable to get working. I don't really understand how the interrupt affects program flow but it seems to disable the Pulse output from the PIC to R/barC to start the ADC. Nothing seems to be output from the ADC as a consequence.

I have been able to get the circuit working with the attached code and this produces valid USB output of zero bits near zero volts input to around 25000bit around 4V input on Vin. See photo. I suppose it is set for a 0-10V scale. I set the ADC to external clock which the PIC supplies in a ragged manner. The timing is: Fosc/4 = 130kHz, Fosc/16 = 50kHz, Fosc/64 = 12.5kHz. Triggered off the R/barC pulse there are 16 clock cycles before, and 24 cycles (apparently!) after the rising edge. However, the clock is extremely noisy and is intermittent or even inactive when the USB is also inactive (unplugged) - which I just don't understand.

I'm not impressed with the 18F2553 and have just purchased a RaspberryPi to do some real programming - if I can find a Fortran77 compiler!
Richard
Attachments
ADCspiUSB.fcf
(15 KiB) Downloaded 348 times
ADCspiUSB outputsmall.jpg
(145.66 KiB) Downloaded 1701 times

kersing
Valued Contributor
Valued Contributor
Posts: 2045
Joined: Wed Aug 27, 2008 10:31 pm
Location: Netherlands
Has thanked: 553 times
Been thanked: 1081 times
Contact:

Re: 18F2553 to slow to use fast 16bit ADC AD977

Post by kersing »

Richard,

An interrupt basically interrupts (hence the name :-) ) the program flow and executes the interrupt macro. In the code I posted the ADC should get triggered by the output icons, then the ADC starts conversion of a new sample and simultaneously outputs the previous sample. It should provide dataclock out as interrupt to PIC and when the interrupt occurs the PIC reads one of the 16 data bits. In the main code the PIC waits for all 16 bits to be read before proceeding to send the data via USB.

Things to keep in mind when using interrupts:
- Most PICs can only handle one interrupt at a time. While the macro handling that interrupt is running all other interrupts will be lost. (So keep interrupt code short and return from the routine as soon as possible)
- USB uses interrupts as well. This may cause interference (lost interrupts) in other parts of the code.

Good luck with the Raspberry Pi. BTW Real programmers are allowed to use assembly as well ;-)

Jac
“Integrity is doing the right thing, even when no one is watching.”

― C.S. Lewis

Post Reply