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.
Let me try to explain
my problem by describing what I am doing.
I have configured the
ADS1115 to 860SPS (~1.2ms samples) and single shot mode.
Then I have done the
- Write config to
- wait 2ms
- Read AIN 0 data
- Write config to
- Read AIN1 data
- Write config to
- wait 2 ms
- Read AIN0 data
So I am expecting
that when I read AIN0, the data for AIN 0 should appear. However, I notice that
sometimes the data for AIN 0 shows the data for AIN 1 but sometimes it is
correct (shows AIN0). (randomly)
I found that if I
extended the delay (wait 2 ms) to more than 8ms the device starts behaving
My concern is what is
causing this delay when switching mux inputs. If I don't switch mux inputs the
data can be read at ~1.2ms with no problem.
What is the delay
time after writing to the config register before a conversion begins?
Note: by examining
the rdy pin, the rdy is active sporadically when the wait is set to 2ms, I
would expect the rdy pin to be consistent.
Maybe it was a typo, but you need to wait between writing config to select AIN1 data and reading of the data. If you read directly after the config write you may have read the results from the previous conversion. So you have to wait the total length of the communication plus the conversion period. So you need to be careful that you do not read the last conversion, but the next completed conversion after the mux change.
I have kept better track of timing using the one shot mode where I change the mux channel and then start the conversion. I always will have the correct data in this case.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Bob Benjamin:
In reply to Fernando Marengo Rodriguez:
Welcome to the forum! The ADS1115 will complete the conversion based on the conversion time selected in the ADS1115 configuration register. If you have selected 860sps, the conversion should complete in about 1.2ms following the completion of the configuration write to start conversion in single-shot mode. If you continually poll the configuration for completion, you communication clock time may be affecting when you seeing that the conversion has completed. In other words it is taking you longer to read the status of the device than it takes to complete the conversion.
You could try a couple of different approaches. One is to use a timer that you start after starting the conversion. Let's say you set the timer for 1.5ms. After the timer has completed the count, you read the conversion result from the ADS1115. This does assume that your timer is accurate and you have included the proper additional time for the ADS1115 oscillator startup and any oscillator variation as specified in the datasheet as +/-10%. I believe 1.5ms should be an appropriate delay for 860sps.
Another approach is to use the ALERT function as an end of conversion monitor. The ALERT pin can be configured in such a way as to change state when the conversion has completed. You can monitor this pin with your micro GPIO set up as an input interrupt pin. When this pin changes state, you can have the micro generate an interrupt to read the conversion data. This is discussed in section 9.6.4 of the datasheet.
Thank you very much for your suggestion. The previous delay I told you (conversion ready, about 8 ms) corresponds to 128 sps. I've recently tested with 860 sps, and that delay is between 1 and 5 ms. This delay was measured via millis(); and the state of the ADS1115 was continually polled. According to your suggestion, I've used 1.5 ms and my system works. Thank you!
One important thing I'd like to consider is the following. Since the A/D conversion is performed periodically, it is inside an ISR. Since such ISR must transfer data to and from the ADS1115, I2C communications must me enabled, and such communications also produces an interrupt. My code worked by enabling interrupts INSIDE the above mentioned ISR. Care should be taken, since the main ISR should be called each T1=10 ms, and I2C communications inside such ISR should be sufficiently fast in order to avoid any problems. Do you suggest any alternative in order to avoid nested interrupts?
Thank you, best regards,
When it comes to interrupts it is best to keep the routine as small as possible. For example, I may have a main processing loop with sequential operations. If an interrupt comes for reading data I do not run the communication to the ADC inside that interrupt. What I do is set a flag to true and that is the only operation within that interrupt routine. In my main processing loop I check the status of the flag, and if it is true I read the data from the ADC and then switch the flag to false when the read is complete. The same thing can be done with timer interrupts. In this way I avoid nesting interrupts.
Another thing you can do to avoid interrupt conflicts is to disable an interrupt so that it is only called once until the process completes. After the routine completes you can enable the interrupt again. Hope that makes sense.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.