This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS1278 problem with DRDY going low during reads

Other Parts Discussed in Thread: ADS1278

I am working on a circuit to evaluate the ADS1278.  It is interfaced to a PIC MCU. I am bit-banging the SPI port, that is not using the hardware SPI port on the MCU.  The data I am reading does not seem correct.  My guess is that this is due to DRDY going low during the time I am reading the 8 channels, often during channel 2.  The timing signals in the datasheeet, for example Figure 75, show DRDY remaining high during the reading of all 8 channels.

Please see attached scope traces and schematic.  Do you see anything I am doing wrong?  I am using TDM Mode Fixed Position Data.  

There is a paragraph in the datasheet on page 41 that I do not understand--
"DRDY/FSYNC (SPI Format)
In the SPI format, this pin functions as the DRDY output.  It goes low when data are ready for retrieval and then returns high on the falling edge of the first subsequent SCLK.  If data are not retrieved (that is, SCLK is held low), DRDY pulses high just before the next conversion data are ready, as shown in Figure 73.  The new data are loaded within one CLK cycle before DRDY goes low.  All data must be shifted out before this time to avoid being overwritten."

I do not follow the last two sentences.  All data must be shifted out before what time? 

CLK = 1.25 MHz, from the MCU
SCLK = approx. 278 kHz 

Thanks
Ron 

T

  • Mr Evans -

    The DRDY signal will occur at the data rate of the ADC (based on mode and CLK).  When reading the data, you must read ALL channels of data of interest before the next DRDY pulse.  If you do not, then the DRDY pulse updates the data with new conversion results and therefore the data may appear incorrect.

    For this reason the SCLK is generally faster than the CLK and why using a bit-banged GPIO can be tricky.

  • Thank you for the answer Greg.  This is not very convenient.  I wish this had been made more clear in the datasheet.  I will verify I have the part running as slowly as possible.  I made the loop to read out the data as tight as possible using bit banging, and am only able to read about 3 channels.
    Ron