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 Code Example

Other Parts Discussed in Thread: ADS1241

The main TI web site seems to be down. So pursuing anything there is futile.

I am working through a design using the ADS1241 and was wondering if there are any examples of its setup and use. Although code would be most helpful, a flow diagram would be a big help in getting evrything in the right order. (I have a feeling that an example for any of the multi-input ADS124x devices would be similar.)

Thanks

  • David,

    Here is some example code for the IAR compiler to operate with the ADS1241MEVM and a specific motherboard that is no longer being manufactured (HPA449.)  You should be able to follow the flow and see what is needed to communicate with the device.

    Best regards,

    Bob B

    ads1241_iar.zip
  • I'll go through it. It'll certainly help me get started.

    Thanks

     

  • The code looks good and it's easy to follow. However, while working through it, I realized that there are some delays and then waits for !DRDY to go low. Comparing this to the data sheet, I came up with a couple of questions:

    In the section on SELFCAL(page 12), it says that "the first data after calibration should be discarded". It doesn't look like the example does this. Is this something I should do?

    A general comment on the descriptions of the !DRDY signal is that there's not enough detail. For example, how soon after the SELFCAL command is sent will the !DRDY signal go high?

    Is it correct to assume that !DRDY being high is an indication that a conversion is in progrss? If so, how soon after issuing a MUX change command will the !DRDY signal go high?

    What I envision is a loop similar to:

       - issue a MUX change

       - wait for !DRDY

       - read the data and store in an array

       - loop back

    Is there anything wrong with this approach?

    Thanks

     

  • David,

    I can't speak for the code specifically myself.  Those that worked most closely with that specific code are no longer with TI.  There may be some internal delays related to calibration or some other specific changes that may cause a reading to be invalid.  You mentioned the calibration case, and yes you should discard that first reading after a calibration.

    The DRDY signal returns high when a read operation of the data register is complete, or just prior to the results register being updated.  There is very little information on the timing.  It is not clear from the characterization data how many samples are actually used in the calibration procedure, so it is difficult to say how long that process takes, but it will be proportional to the modulator frequency and data rate. 

    If you don't read the results from the output register following a completed conversion, DRDY stays low up until the time when the following conversion is complete and the results are updated in the output register.  So when DRDY goes high, that means the conversion is complete and is updating the results which will then be valid when DRDY returns low.

    So, if you look at Figure 2 of the datasheet you will see in the timing diagram that when DRDY goes low the next conversion starts.  So you want to read out the results of the previous conversion and write the mux change within the tDelay allowed time so that settling errors are not introduced.

    I have not actually tried this, but based on our other parts you should be able to read the data (if in RDATAC) and at the same time write the mux change.  So in the code loop you provided, you would be reading the previous data (DOUT) the same time as you write the mux change (DIN) for the next result.

    Best regards,

    Bob B

  • That seems pretty clear to me. At least to the point where I can try it and be close.

    I was reviewing the data sheet and I think the problem (maybe just for me) is that the author tried to do too much with as few words (or pictures) that he could. Your description sounds pretty much like I expected.

    One point for clarification: Let's presume that I issued the SELFCAL command and read the data out immediately just to be sure that DRDY was high. Will DRDY remain high until the SELFCAL process is complete?

    I guess what I'm looking for is a way to have the part provide the necessary timing rather than having to twiddle my thumbs and then guess at it. (Yes, I like being lazy!)

    Thanks

     

  • David,

    I was looking again at the datasheet and the SELFOCAL and  SELFGCAL each take 2 tData periods, so I that makes the SELFCAL take 4 tData periods.  The SELFCAL requires the PGA at 1.  The offset cal is down first, then the gain cal.  If you use a different PGA setting in your application, you should run the SELFOCAL after changing the PGA to the desired setting to remove any offset due to the PGA.

    To answer your specific question, if you issue the SELFCAL in the third byte transfer on your data read the SELFCAL will start and the DRDY will assert high after the transfer.  When the calibration is complete, DRDY will go low.

    Best regards,

    Bob B

     

  • For the situation I'm in, the PGA will always be set to 1, so that is no problem. From your description of the timing for the SELFCAL command, I'm getting a clearer idea about how the inner state machine works for the ADS1241. I think I have enough now to start testing. (It's a pitty I won't have the hardware available for a couple of weeks, but I'll be ready!)

    Thanks for your help!