conversionComplete() blocks the stream

[konstantin10return]

Hello.
I used ads1115 and esp32 for my project. I have a need for clocking stepper motors even with i2c issues. For these purposes, I have written the following code.

#include <Adafruit_ADS1X15.h>


Adafruit_ADS1115 ads;
uint16_t geom_ads_ch0_val = 0;
uint16_t geom_ads_ch1_val = 0;
uint8_t ch_in_reading = 0;
uint64_t lst_geom_update_time = 0;


// ----------------------!

#define TASK_FILAMENT_SENSOR_TIMEOUT 10


void geom_ads_request(){
  ads.startADCReading(MUX_BY_CHANNEL[ch_in_reading], /*continuous=*/false);
}


// This function is called in setup() 
void geom_setup(){
  if (!ads.begin(0x49)){ 
    Serial.println("ADS1115 NOT INITED"); 
  }

  Wire.setTimeout(1); 
  Wire1.setTimeout(1); 
   
  geom_ads_request();
}


// This function is called in loop() with a period of TASK_FILAMENT_SENSOR_TIMEOUT of milliseconds
void task_filament_sensor_handler(){
  // static uint8_t ch_in_reading = 0;
  if(ads.conversionComplete()){
    if(ch_in_reading == 0){
      geom_ads_ch0_val = ads.getLastConversionResults();
    } else if(ch_in_reading == 1){
      geom_ads_ch1_val = ads.getLastConversionResults();
    }
    ch_in_reading++;
    if(ch_in_reading > 1){
      ch_in_reading = 0;
    }
    lst_geom_update_time = millis();
    geom_ads_request();
  }
}

But there is a problem: the conversionComplete() function, before giving up, tries to communicate for a whole second, blocking the flow.

[caternuson]

Probably related to the timeout being set. There is no explicit delay in the function(s) being called.

But there is a problem: the conversionComplete() function, before giving up

What do you mean by "giving up"?

[konstantin10return]

What do you mean by "giving up"?

As far as I understand, conversionComplete() is trying to read data; if it succeeds, it returns 1. If all attempts (during some hidden set timeout of 1000 milliseconds) were unsuccessful, then conversionComplete() "gives up" and returns 0.

[caternuson]

conversionComplete() simply reads a register and checks the conversion complete status bit:

Adafruit_ADS1X15/Adafruit_ADS1X15.cpp

Lines 383 to 385 in 498adc7

	bool Adafruit_ADS1X15::conversionComplete() {
	return (readRegister(ADS1X15_REG_POINTER_CONFIG) & 0x8000) != 0;
	}

There are no repeated attempts or timeouts.

Also, readRegister() has no additional delays or timeouts:

Adafruit_ADS1X15/Adafruit_ADS1X15.cpp

Lines 411 to 415 in 498adc7

	uint16_t Adafruit_ADS1X15::readRegister(uint8_t reg) {
	buffer[0] = reg;
	m_i2c_dev->write(buffer, 1);
	m_i2c_dev->read(buffer, 2);
	return ((buffer[0] << 8) | buffer[1]);

Why are you calling Wire.setTimeout(1); ?

[konstantin10return]

I did a little experiment.

uint16_t Adafruit_ADS1X15::readRegister(uint8_t reg) {
  buffer[0] = reg;
  uint64_t t = millis();
  m_i2c_dev->write(buffer, 1);
  Serial.println("t_W: " + String(millis() - t));
  t = millis();
  m_i2c_dev->read(buffer, 2);
  Serial.println("t_R: " + String(millis() - t));
  return ((buffer[0] << 8) | buffer[1]);
}

During normal operation, the output:

t_W: 0
t_R: 0
t_W: 0
t_R: 1
t_W: 0
t_R: 0
t_W: 0
t_R: 1
t_W: 0
t_R: 0
t_W: 0
t_R: 1

But when i2c fails:

t_R: 1000
t_W: 0
t_R: 1000
t_W: 0
t_R: 1000
t_W: 0
t_R: 1000
t_W: 0
t_R: 1000
t_W: 0
t_R: 1000
t_W: 0
t_R: 1000
t_W: 0
t_R: 1000
t_W: 0
t_R: 1000
t_W: 0
t_R: 1000

We can conclude that the Adafruit_I2CDevice.read() function allows itself to block the stream.

[konstantin10return]

Why are you calling Wire.setTimeout(1); ?

The library uses Wire internally. Before writing issue, I found information that a large Wire timeout can have a similar effect. Unfortunately, simply setting a timeout using Wire.setTimeout() was not enough to solve the problem.

[caternuson]

What's causing I2C to fail? What's "normal operation" vs "i2c fails"?

[konstantin10return]

What's causing I2C to fail? What's "normal operation" vs "i2c fails"?

"i2c fails" is when the ADS1X15 chip does not respond to requests for some reason.

[caternuson]

That would be more of a hardware issue than a software issue. And there is generally no easy way to handle that at the software level. It is assumed the I2C bus is valid and good.

[konstantin10return]

I would really like to add survivability to the device.
You must admit that it is quite unpleasant if the device functions unrelated to it stop working when the chip is dropped.

With all due respect, the world is not perfect. Various problems can happen, and during development it would be good to provide ways to survive the loss of parts.