ADS1115 interrupt only called when I read the value from loop

[kirk_berkley]

So, I am using the AS1115 ADC with the library from: GitHub - RobTillaart/ADS1X15: Arduino library for ADS1015 = I2C 12 bit ADC and ADS1115 = I2C 16 bit ADC

I am trying to use the ALRT pin to trigger an interrupt, so that I don't have to poll the value in my main loop. However, the interrupt only occurs when I poll the value. Am I doing something wrong?

Here is my sketch:

#include <ADS1X15.h>

#define ADC_INTERRUPT_PIN 35

volatile int16_t _status = 0;

ADS1115 ADS(0x48);

void IRAM_ATTR adsInterrupt() {
  //_status = ADS.readADC(0);
  _status = (_status + 1);
}

void setupADC() {
  Wire.begin();
  ADS.begin();

  ADS.setGain(1);
  ADS.setDataRate(7);
  ADS.setMode(1);

  ADS.readADC(0); // Forces settings to be applied.

  // set the thresholds to Trigger RDY pin
  ADS.setComparatorThresholdLow(16000);
  ADS.setComparatorThresholdHigh(24000);
  ADS.setComparatorQueConvert(0); // 0 = trigger alert after 1 conversion
  ADS.setComparatorLatch(0); // 0 = NON LATCH
}

void setup(void)
{
  Serial.begin(115200);

  setupADC();

  pinMode(ADC_INTERRUPT_PIN, INPUT);
  attachInterrupt(digitalPinToInterrupt(ADC_INTERRUPT_PIN), adsInterrupt, RISING);
}

void loop(void)
{
  int16_t adc0 = 0;
  //adc0 = ADS.readADC(0);

  Serial.print("raw: ");
  Serial.print(adc0);
  Serial.print(" | volts: ");
  Serial.print(ADS.toVoltage(adc0));
  Serial.print(" | status: ");
  Serial.println(_status);
  
  delay(2000);
}

_status will not increment unless I uncomment the second line of the main loop to read the value of ADC pin 0. When it is uncommented, status only increments once every 2 seconds when the value is read.

Is this how it is supposed to work? I could setup a second thread to poll the value, but at that point, I don't feel like I would need the interrupt. Am I missing something?

Oh, I should probably mention I am using an ESP32-WROOM (the 38 pin version).

[sonofcy]

Try using the correct syntax for the attachinterrupt shown below

attachInterrupt(digitalPinToInterrupt(pin), ISR, mode) (recommended)
also add volatile to the status as in

volatile int16_t _status = 0;

[kirk_berkley]

Thanks for the suggestions. I've updated my post to include them. Unfortunately, they didn't change the functionality of the code.

[blh64]

@kirk_berkley

pinMode(ADC_INTERRUPT_PIN, INPUT);

Do you have an external pull-up resistor on your interrupt pin? You will need one. The ALRT/RDY pin pulls LOW to assert. You can also make the pin INPUT_PULLUP to skip the external resistor.

[kirk_berkley]

That's interesting, I am glad you said something. So, yes I did have a pull-DOWN resistor, because the readme for the library says the signal goes high when triggered. I didn't fully appreciate the section of the readme that discusses the configuration options for it. There is a config register on the ADC with a "COMP_POL" option to set whether or not it goes high or goes low when triggered.

So, I hooked the ALRT pin directly to my scope and I can confirm that the default (for this library) has it configured so the alert pin goes high when triggered.

I also reconfigured it to work with a pull-up instead, just in case, but the results are the same.

Since I have it hooked to the scope, I can eliminate the ESP interrupt as a potential failure. The ADC simply does not change state unless I explicitly request a value using "ADS.readADC()" or "ADS.getValue()".

[theboot]

My guess is the adc is not correctly set in a continuoes output mode.

Its only outputting when you query for a read. Then when you query as it does a read the interrupt is also triggering.

[GolamMostafa]

Please, edit the Title to reflect: AS1115 ===> ADS1115.

[GolamMostafa]

Thank you.

Please, study the followih schematic (Fig-1) of the ADS1115's Breakout Board (Fig-2) to see how the pins of the ADC are terminated.

Figure-1:

Fig-2:

[kirk_berkley]

@theboot

My guess is the adc is not correctly set in a continuoes output mode.

Its only outputting when you query for a read. Then when you query as it does a read the interrupt is also triggering.

That is how it behaves, and digging through the code in the library, I don't believe the continuous register bit is being set correctly. It looks to me like that bit is 1 by default, but the library is trying to clear it using a binary or with a value of 0, which won't work.

I'm going to fork the library and poke at it.

[theboot]

Hope so let us know if it works

[RayLivingston]

FWIW - When I've used the ADS115, I found it convenient to poeriodically kick off a conversion, and on a subsequent pass of loop(), read the result, based on a millis() timer. No interrupt needed, and very low overhead.

[kirk_berkley]

@kirk_berkley

That is how it behaves, and digging through the code in the library, I don't believe the continuous register bit is being set correctly. It looks to me like that bit is 1 by default, but the library is trying to clear it using a binary or with a value of 0, which won't work.

Yeah, so I was wrong. I'm going to chalk it up to it being late (early? 2am). The binary "or" ("|") works fine because all of the settings are being "ored" together and then the entire registry is written to at once. So, the bit never actually needs cleared, it is simply either set or not set.

@kirk_berkley

So, I hooked the ALRT pin directly to my scope and I can confirm that the default (for this library) has it configured so the alert pin goes high when triggered.

This is not quite right either. There was indeed a bug in the library that was inverting the polarity (this should be fixed in v0.5.0). So, when I was setting the polarity to 1, it would actually be set to 0 and vice versa.

However, after further testing, regardless of the value for the polarity bit ("COMP_POL") you absolutely want to use a pull-up resistor on the ALRT pin. If you leave it floating, you'll get ghosts, and if you pull it down, you will cut your peak-to-peak voltage in half and cause signal drifting. I only tested this with a 10k resistor, different values might have a more profound effect.

With the library fixed and the polarity bit correctly set to 1, the pulses will go high. With the polarity bit set to 0, the pulses will go low. According to Figure 29 of the data sheet (https://www.ti.com/lit/ds/symlink/ads1115.pdf), the conversion is only ready at the trailing edge of the pulse. Which means in order to guarantee the conversion is ready, you need to adjust which edge your interrupt is looking for to match your polarity. With the polarity bit set to 1, you'll want to watch for the falling edge, but with the polarity bit set to 0, you will want to watch for the rising edge.

Also, if that wasn't confusing enough, the polarity in continuous mode vs single mode are opposites. With the polarity bit set set to 1, the pulses go low in single mode, but go high in continuous mode. Likewise, with the polarity bit set to 0, the pulses go high in single mode, but go low in continuous mode.

[kirk_berkley]

@RayLivingston

FWIW - When I've used the ADS115, I found it convenient to poeriodically kick off a conversion, and on a subsequent pass of loop(), read the result, based on a millis() timer. No interrupt needed, and very low overhead.

Which is a great way to do it, however, I'm using this to trigger an event as soon as the single dips below or above a certain threshold. The ADS115 is capable of doing a conversion once every ~1.2ms. Simply reading the value once every loop in single mode limits me to ~2.7ms. But that was tested with a near empty loop with no delay, which means my reaction time, in the best case scenario is about double (not accounting for the time it take the interrupt to be triggered).

Even without an interrupt though, continuous mode should still be faster because when you call read in single mode, you have to wait for the ADC to take a sample and do the conversion. In continuous mode, you can simply grab the last value directly from the register without waiting. I don't know if there are interlocks on the chip that would prevent you from reading a partially written to register though...

[oldcurmudgeon]

@kirk_berkley

I don't know if there are interlocks on the chip that would prevent you from reading a partially written to register though...

From the data sheet

The rate of continuous conversion is equal to the programmed
data rate. Data can be read at any time and always reflect the most recent completed conversion.

So I suspect the conversion result is buffered.

[oldcurmudgeon]

You may want to look at this discussion from years ago.

ADS1115 high speed data rate

Change to a different library that doesn't do that. For example ADS1115_WE by Wollenwald. Single shot mode will not get to the maximum data rate - from the data sheet... The ADS111x have two available conversion modes: single-shot and continuous-conversion. In single-shot mode, the ADC performs one conversion of the input signal upon request, stores the conversion value to an internal conversion register, and then enters a power-down state. This mode is intended to provide significant power…

The next post has sample code for an esp8266 to get the maximum data rate using interrupts.

[kirk_berkley]

Thanks this helped. I'm marking this as the solution and moving on to the next thing.

Thanks everyone for your help on this.