ADS131M03-Q1: could I switch off master clock but still being capable of getting result via SPI?

Hi Mykhaylo Lodygin,

Can you describe the procedure you want to achieve here? I am not really following why you want to turn off the ADC clock, and then still expect the ADC to give you data "later" (what does "later" mean in terms of actual time? Are you going to sample continuously and shut off the clock in between samples? Just randomly take a reading and then turn off the clock? We need to know more specific information about what you are trying to accomplish and why)

-Bryan

Hello Bryan, thank you for the reply.
what I'm going to achieve is twofold - first to reduce consumption in both ADC and MCU (mcu will clock the adc) by clocking the ADC only when data is needed (pretty not frequently - 1ms or so is the most frequent and then 100s of ms downtime), second - reduce the need for "data ready" signaling (physical net or logical SPI interaction) since deterministic adc will provide a result after the exact number of clocks and I'm in control of them. so the modus operandi is the following - at some calculated moment in time the system needs data - it turns on the clock - data is collected by the ADC and latched in it's buffer. Clock disables. Then different process collects captured data over SPI in it's own schedule without turning on the clock

Hi Mykhaylo Lodygin,

I will look into this tomorrow and get back to you then

I was able to confirm that reading and writing registers is possible without a clock, but I have some doubts about reading data

Also, why not just read the data immediately before turning off the clock / putting the ADC to sleep? It doesn't make much sense to me why you would need to read the data at a later time.

I agree that if you just care about a single conversion at a time, you can use the SYNC pin to start the conversion at a known instant and then wait for time tSETTLE (+ margin) to retrieve data. In this way you will not need to monitor the DRDY pin

-Bryan

Hi Bryan, thanks.

Concerning the immediate reading after acquisition conclusion - well.... technically you are right and it is quite straight forward to read immediately, but a) it'll consume current while continue clocking (keeping in mind that reading the result is much slower process than acquiring) b) i must add the code that read a result into realtime process of data acquisition, contrary to two separate processes, which will increase complexity, reduce portability and drive costs for both development and maintenance.