ADS1158 SPI datasheet confusion

[Bootalito]

I'm doing some preliminary design using the following 16bit ADC:
http://www.ti.com/lit/ds/symlink/ads1158.pdf

I'm unable to determine from the datasheet precisely how I need the configure the SPI for my application.  I'm going to be using the Auto-Scan feature and configure the ADS1115 to automatically scan 20 of the configurable mux configurations.  For my application I don't want to use the DRDY pin and interrupt and immediately.  I'd rather poll and read all 20 data points at one time, as I will be dedicating one of the uC cores to this task, and a back-of-the-envelope calculation shows that a continuous loop of reading all of the channel data should meet my throughout requirements with margin.

I believe I need to use "Channel Data Read Command" as described on page 29.  However its not clear as to WHICH channel I'll be getting.  Typically one would send an address, such as is described in bits 0-3 in the command word.  However, for "Channel Data Read Command", these are "don't care".  Also, note (1) on this page seems to suggest I can just issue another command and get the other channels (although this might be referring to when you are reading configuration registers).

I want to just send a command (such as 0011 000), then keep clocking 60 bytes to get each of the 20 configured mux configurations ( 3 bytes per channel (1 status, 2 data) X 20 channels).  Even if I need to clock in all 29 possible configurations, this fine, I just want a method to get all of the data at once, as opposed to getting one channel at a time.  Heck, I can't even figure out how to get one channels data at a time, except for using the "Channel Data Read Direct" method, which had a very good description.

A little assistance would be much appreciated.  Thanks

[bson]

I believe I need to use "Channel Data Read Command" as described on page 29.  However its not clear as to WHICH channel I'll be getting.  Typically one would send an address, such as is described in bits 0-3 in the command word.  However, for "Channel Data Read Command", these are "don't care".

You get 3 bytes on a channel data read (as opposed to a direct read), the first being a status byte that includes the channel ID and whether you've read this value before (the NEW bit).  See page 31, table 9.  I don't think direct reads are compatible with auto scan, in that you won't know what channel the value came from and tracking it is probably not reliable.

The "don't care" refers to there being nothing of interest on DOUT during the command phase and the device ignoring DIN while clocking out the 3 bytes on DOUT.  Only 2 bytes are shown in Figure 45 on p.29 - see footnote (2).

TI does have a knack for confusing documentation.  And overly complicated configuration.  I don't think anyone at TI understands software.

[Bootalito]

I believe I need to use "Channel Data Read Command" as described on page 29.  However its not clear as to WHICH channel I'll be getting.  Typically one would send an address, such as is described in bits 0-3 in the command word.  However, for "Channel Data Read Command", these are "don't care".

You get 3 bytes on a channel data read (as opposed to a direct read), the first being a status byte that includes the channel ID and whether you've read this value before (the NEW bit).  See page 31, table 9.  I don't think direct reads are compatible with auto scan, in that you won't know what channel the value came from and tracking it is probably not reliable.

The "don't care" refers to there being nothing of interest on DOUT during the command phase and the device ignoring DIN while clocking out the 3 bytes on DOUT.  Only 2 bytes are shown in Figure 45 on p.29 - see footnote (2).

TI does have a knack for confusing documentation.  And overly complicated configuration.  I don't think anyone at TI understands software.

Thanks.  As I read the "Direct Read" method, I think its pretty clear that one would wait for DRDY and interrupt and immediately read the data in Auto-Scan mode.  So I think Direct Read is compatible with Auto-Scan. So I think perhaps you meant to say "I don't think Channel Data Read are compatible with auto scan,".  Which perhaps is the case.

So if I just "Read the channel", and I have no idea what channel I'm getting, yes I get that I can extract that from the first status byte, but is seems inconceivable that they would just give you a random channel, oer perhaps just the last channel read more like it, and hope you can read fast enough.

Argh!  I just want to send a command and clock in ALL of the data.  Hell, I'd be happy if I had to send separate commands, then I can program it to simply cycle through all of the addresses I need with separate reads (i.e. cycling CS each time).  But I don't see a clear way of doing this.  Except for the Direct Read Method, where I need to interrupt on DRDY and quick take the reading as fast as I can before the next reading is available.  Perhaps I'll post something similar on an official TI forum and perhaps someone from TI can give me a direct answer.

[Bootalito]

google helped...
https://e2e.ti.com/support/data_converters/precision_data_converters/f/73/t/454009?ADS1158-Channel-read

Yeah so it turns out that the design of the chip is really crappy like you suspected.  In auto-scan mode you STILL need to read the data out before it finishes the next conversion.  Which means if you want all of the data as fast as possible without using interupts, you just continuously poll for a result...and you get what you get.
Why on God's green earth there isn't a another 48 byte register that can hold all of the 24 possible mux conversions is beyond me.  Then in Auto-scan the ADC can keep plotting away, and I'd just come in and read all of the data that its gotten in the last scan all at once. I think I'll just do interrupts on the DRDY and read the channel it gives me immediatly.  But according to that post "If you don't read data in time (before /DRDY goes low again) then you will lose the measurement result for that channel (at least until auto-scan has cycled back through to that channel again). "...which is just....stupid.  Put that data somewhere for the uC to access whenever it wants!