• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 45 subscribers
  • Views 6606 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

ADS1241 Sequencing

David Pfaltzgraff
Expert 2425 points
Other Parts Discussed in Thread: ADS1241

Working from the data sheet I gather that I can read the data at the same time that I'm writing a new MUX command to the ADS1241. Am I interpreting this right?

What I'm doing is:

  • send the RDATA command
  • wait a minimum of 50 Tosc periods
  • send WREG (for the MUX register) and read the first byte
  • send a count of 0 and read the second byte
  • send a value for the desired input(s) and read the last byte

Then, I wait for DRDY and repeat.

What's happening is that it appears that the MUX doesn't change. Even with a grounded input, all results are the same.

  • 0
    TI__Guru** 113765 points

    David,

    The device does work in full-duplex mode, but I believe the state machine will not allow you to issue another command until the first command is complete (data is shifted out.)  Unfortunately I don't have an easy way of checking this out at this time, but the state machine from similar devices show this to be the case.  This differs from the RDATAC mode where the result is automatically placed in the output register.  In this case you can send the write register command as you are reading the data because there is no command that is blocking.  This is the method shown in Figure 2 of the datasheet.  In this case you have settling error based on how quickly you change the mux (complete the WREG command.)

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Expert 2425 points

    OK. That makes sense.

    Basically, I was trying to "optimize" time and was following the figure. However, I was not aware that it applied to the 'continuous' mode. Since time is not critical, I'll go back to the simpler mode.

    There are a couple of questions that I couldn't see a clear answer in the data sheet:

    1. Is the conversion started on issuing the MUX change?
    2. How soon affter issuing the MUX command will the DRDY* signal go low?

    Thanks

  • 0 in reply to David Pfaltzgraff
    TI__Guru** 113765 points

    David,

    Basically the conversions never stop even if you use STOPC.  STOPC stops updating the output register with the conversion result.  Unlike some of our newer parts, the digital filter is not reset when the MUX change happens so you can get an error depending on when you change the mux in relation to the timing of the conversion.  Obviously it would be best to change the mux early in the beginning stages of the conversion.

    So for question 1, no the mux change does not initiate the conversion as it runs continously.  And for question 2, it will depend on when DRDY went low the time previous.  It is possible to reset the digital filter and restart the conversion by issuing the DSYNC command ( or pulsing the DSYNC pin) right after the mux command is written.  In this way you will know the precise timing based on the last falling edge of SCLK for the DSYNC command.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Expert 2425 points

    Hi Bob,

    This one has me puzzled. I tried using the DSYNC to know when a conversion was kicked off but got inconsistent results. So, I've played with several things. This seems to work, but I feel like there's a better way.

    My loop is as follows:

    • set the MUX
    • delay a minimum of 3 DRDY periods (This timing didn't seem critical)
    • read and discard 3 or 4 readings
    • save this reading
    • increase the channel number and loop back

    Is there a simpler solution? For example, after I change the MUX, how long would I need to wait before the output register contains valid data? For example, it would be easy to set the MUX and then just do something else until 'X' conversion periods have passed. The thing is that I've played with the number of DRDY periods (step) and that didn't seem to affect the result.

    Something isn't quite making sense to me.

    Thanks.

  • 0 in reply to David Pfaltzgraff
    TI__Guru** 113765 points

    David,

    You really don't need to wait/discard that many readings.  The very first reading after the mux change will be valid data, but there will be some settling error associated with the result, so I would discard the first result.  After that you should have good data.  There may be other good reasons for discarding data, but only the first reading after the mux change will have settling error due to the previous input.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Expert 2425 points

    Hi Bob,

    Sometimes software is the problem! I had defined the first several values on the stack. This meant that the debugger (Microchip's MPLAB) didn't have access to the correct data. Once I made them static, the values started making sense.

    Thanks for your help - at least the listening!