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.

ADS1282-SP: DRDY timing parameters?

Part Number: ADS1282-SP

The datasheet does not specify timing parameters for DRDY relative to either SCLK or CLK. Is DRDY synchronous to either clock? What is the min/max propagation delay for DRDY relative to (which) clock?

I'm wondering how to safely capture DRDY in to my ADC interface under all conditions. Should I register DRDY on CLK or SCLK? Or should I consider it asynchronous and double-register it?

  • Hi Aviva,

    Welcome to the TI E2E Forums!

    The /DRDY signal is derived from the CLK signal; however, unfortunately I don't have any information about the min/max propagation delay. Assuming that this delay is less than 1 CLK period, I would expect the /DRDY falling edge to occur at the following rates:

    ADS1282-DRDY-Timing.xlsx

     

    Are you counting the number of clocks between /DRDY falling edges, is that why you're trying to get an accurate timing of when /DRDY goes low?

    The main purpose of /DRDY is to serve as an interrupt to the processor so that it know when to fetch data. As long as data is read prior to the next /DRDY falling edge (i.e. before the next conversion result is available) then the exact timing of when a conversion completes and data is read is usually not very strict.

     

    Best regards,
    Chris 

  • Hi Chris, thank you for your response. No I'm not trying to count the clocks to DRDY. (I've never been successful at calculating that anyway, as I'm running in sinc mode with a nonstandard fCLK = 3.571 MHz). Rather, I have the ADC interfacing to an FPGA, and I'm trying to ensure that I do not violate setup or hold time at my capturing flip flop for DRDY. For space applications, of course, we analyze the heck out of every interface under all conditions.

    My application is currently working in the lab with no special handling. But after looking at this, and with TI unable to provide timing parameters for this output, I think my best course of action is to treat DRDY as asynchronous and double-register it in to my FPGA. I have plenty of time for reading the data so any extra couple of clock cycles delay doesn't matter to me. It's a very conservative approach but guaranteed not to fail!