• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 46 subscribers
  • Views 959 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.

ADS1258 channel indexing problem in auto-scan mode

Phil B
Intellectual 540 points
Other Parts Discussed in Thread: ADS1258

I am using the ADS1258 in auto scan mode and channel data read command mode.

I can write to and read from registers successfully (MUL =0)

I do not use DRDY but I have START tied high to always convert and have CS tied to a GPIO pin controlled by sw.

I have set up:

CONFIG0 = 0x16 // MUXMOD = 0, external conditioning(BYPAS = 1), CHOP=1, STAT=1

CONFIG1 = 0x70 // max delay, also tried 0x0 for no delay

MUXDIF = 0

MUXSGO = 0x7 // convert continuously first 3 single ended channels

MUXSG1 = 0

SYSRED = 0

CS is brought low for a write/read cycle then brought hi afterwards between events.

For reads I use

C[2:0] = 0x1 // Channel Data Read Command

MUL = 1

A[3:0] = 0 // dont cares

So I thought if I read 4*3 + 1 bytes I think I should see all 3 channels of data (4 bytes per channel including status word and dummy first byte read)

But I only see one channel per Channel Data Read Command and it rotates thru channels (somewhat randomly) when I do the next read...

If I add a second Channel Data Read Command as the 5th written byte(4th is too soon) I see a copy of the original channel read with the New bit not set(since channel index doesnt seem to increment the new bit is responding correctly)

So how do I control the channels indexed in the Channel Data Read Command in auto-scan mode? What is the index mechanism?

Thanks,

-Phil B

  • 0
    TI__Guru** 113765 points

    Hi Phil,

    Unfortunately the device doesn't work this way.  After each channel is converted, DRDY transitions low signifying that the channel is ready to have the results read out.  The ADS1258 will internally advance to the next selected input channel, convert it, and then DRDY will transition low again.  If you miss reading a channel, you will lose it.  In other words you cannot read a block of channel data, but instead read each channel as it finishes the conversion.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Intellectual 540 points

    Obviously using DRDY assigned to an isr is the way to go, but assuming I dont have access to DRDY for low duty cycle applications of multiple channels it looks like I have 2 simple(non-isr, ie async) Channel Data Read Command choices:

    1. Auto-Scan mode - set the MUXSG0 and MUXSG1 for a single channel each time before a read and (eventually) the muxed channel will show up continuously until mux channels are changed.

    2. Fixed Channel - set MUXSCH each time before a read and (eventually) the muxed channel will show up until changed. This downside is it must be differential.

    Which of these cases would be quicker?

    I'm not concerned about missing old data, just the fastest way to read the current channel desired.

    Thanks,

    -Phil B

  • 0 in reply to Phil B
    TI__Guru** 113765 points

    Hi Phil,

    There are a couple of things that auto scan does for you besides giving you the full 16 single-ended channels.  One is that the mux channel change is done for you, and the second is you can use delay to automatically compensate for analog settling.  The fastest throughput will be to use ISR with DRDY.  When not using the ISR method, you have to consider additional overhead.  One is you have to manually change the mux, second you need to consider any analog settling.  Third, you need to throw out data until the digital filter has fully settled.  As the digital filter is SINC5, you will need to wait 5 conversion cycles before the data is valid.  This adds processor overhead and I doubt that this will be faster in the end.

    If you run auto scan, and poll DRDY for a low condition at lower data rates, you should be able to capture all the data.  You may be able to run at higher data rates depending on your processor loop.  Auto scan does a lot of work in the background that the processor would have to handle in fixed channel mode.

    One other option would be to control the START pin.  Running in auto scan and pulsing the START pin will allow you to cycle through the input channels based on when you want the channels to be read.  Using the ADS1258 in this way will allow the channels to be read in order.  Basically you would pulse the START pin for the next channel when you read the data from the previous conversion.  You will never miss a channel this way.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Intellectual 540 points

    Well any of these solutions require access to pins I dont currently have. Without adding a long busy wait looks like the right thing to do is use the DRDY to an ISR. I was looking for an acceptable software solution with my existing configuration. I thought that the SPI software commands alone could get me there but looks like I was mistaken.

    Thanks for the help.

    -Phil B

  • 0 in reply to Phil B
    TI__Guru** 113765 points

    Hi Phil,

    You could use the pulse convert command the same as pulsing the START pin in auto scan.  You can read the data results and determine if the results are new based on the status.  And if they are save the result, then send pulse start command and repeat.  This reaquires no pins, and you are not tied strictly to a delay loop.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Intellectual 540 points

    Good idea. I will try that!

  • 0 in reply to Bob Benjamin
    Intellectual 540 points

    Bob,

    Currently I pulse the CS in between ADC channel reads, would there be a problem with pulsing the CS and the Pulse Convert Command at the same time? Or should there be a delay between CS and Pulse Convert Command?

    Thanks,

    -Phil B

  • 0 in reply to Phil B
    TI__Mastermind 44720 points

    Hi Phil,

    To communicate with the device via SPI, /CS must be low (and timing requirements followed), otherwise commands are ignored. However, if you use the start pin to control conversions then the only timing requirement is with repeat to /DRDY as shown in figure 55.

    Regards,

    Chris

  • 0 in reply to Phil B
    TI__Guru** 113765 points

    Hi Phil,

    One other consideration with respect to what Chris has stated as you are using the pulsed command instead of the START pin.  There is a setup time required for CS going low and the first edge of SCLK.  This is shown on page 7 of the datasheet in the timing characteristics table noted as tsssc.

    When I have coded in the past there is usually enough time in changing the port pin to writing to the SPI transmit buffer that I have never had a problem meeting this requirement.

    Best regards,

    Bob B