• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 582 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ADS1256: Data Retreival After Synchronization

AARON DIAMANT
Prodigy 50 points
Part Number: ADS1256
Other Parts Discussed in Thread: ADS1255

Reference: ADS1255/ ADS1256 Data Sheet (SBAS288K − JUNE 2003 − REVISED  SEPTEMBER 2013)

From figure 18. Data Retreival After Synchronization (pg. 21), there is no mention for the time it takes for /DRDY to rise after the falling edge of /SYNC/PDWN.
I have found that after changing the MUX to a channel different from the previously read channel and waiting for a1uS pulse in /SYNC/PDWN, sometimes /DRDY is still low and of course the conversion is not ready.

My specific question is: in the worst case, how long do I have to wait for /DRDY to rise after pulsing  /SYNC/PDWN in order to make sure that the conversion is triggered.

Many Thanks!

  • 0
    TI__Guru 54476 points

    Hi Aaron,

    Let me look into this and get back to you in next 1-2 days.

    -Bryan

  • 0 in reply to Bryan Lizon86
    Prodigy 50 points

    Sure thing Bryan, Thanks!

    -Aaron

  • 0 in reply to AARON DIAMANT
    TI__Guru 54476 points

    Hi Aaron,

    A couple of questions for you:

    1. Why do you want to know when DRDY goes high? As you can see from Figure 18, the conversion time t18 does not start until the SYNC pin returns high, so I am curious how you are using the DRDY transition in your system. Normally we would expect customers to be concerned about DRDY going low, since this indicates new data is ready.
    2. Is there a need to use the SYNC pin instead of the SYNC SPI command? There is a very tight timing requirement on the SYNC pin (see t16 and t16B) which, if not met, could cause uncertain device behavior. This is discussed in more detail here: https://e2e.ti.com/support/data-converters/f/73/t/218644

    For your specific question regarding the DRDY transition: our digital designer looked at this and determined that the time from SYNC falling edge to DRDY rising edge is bounded by 8 tCLK periods. Note that tCLK in this case is the period of the system clock, not the communication clock (SCLK)

    -Bryan

  • 0 in reply to Bryan Lizon86
    Prodigy 50 points

    Hi Bryan,

    Thanks a lot for your reply!

    Answering your questions:

    1. It is not really that I want to know when DRDY goes high. The problem I have is that under the conditions I described, after strobing the SYNC pin, SOMETIMES DRDY was still low "indicating" that the conversion was ready when the conversion didn't even began, therefore I was reading invalid data. After strobing the SYNC pin, my program checks if anything else can be done instead of waiting for the conversion, and then checks back or polls for DRDY to go low. When there is nothing else to do, it immediately polls DRDY and that is when SOMETIMES the problem arises.
    2. I thought about using the SYNC pin instead of the SYNC SPI command, first because I have the I/O pin available on my side, and second because it is a lot more efficient to strobe the SYNC pin for 1uS (that is 4 times the minimum of t16 in my case) than shifting in two 8 bit SPI commands (SYNC and WAKEUP)

    Anyway, in order to avoid trouble and to get rid of the extra hardware needed to meet the tight timing for the SYNC pin, I'll use the SYNC and WAKEUP commands.

    Thanks again!

    -Aaron

  • 0 in reply to AARON DIAMANT
    TI__Guru 54476 points

    Hi Aaron,

    Thanks for the explanation.

    If your system is immediately polling DRDY, then this might just be an issue of not waiting long enough. At 7.68 MHz, 8*tCLK periods is 1.04us, which seems to be approximately the time you were waiting. But maybe it was just not quite long enough and might have missed DRDY going high. Perhaps you could ensure that the delay is at least 1.2-1.3us before the system checks for DRDY?

    Or, if you are able to switch to using the SPI commands, this would likely be the best option. Let me know if you have any additional questions. Or, if you have a new topic you want to discuss regarding this system, please start a new thread. Thanks!

    -Bryan