I2C: Missing delay in twi_write_start

[vlast3k]

Basic Infos

Hardware

Hardware: ESP-12F (80Mhz)
Core Version: 2.3.0

Description

In the last weeks i had extreme trouble in establishing connection with a CO2 Sensor (CDM7160) over I2C. Tried various kinds of pullup resistors, finally settled on 2k. And with lot's of error recovery code i was able to read from the sensor most of the time. Then i connected a Dust Sensor over I2C (PM2005), and then the whole thing became very unstable. The most time Wire.endTransmission() was throwing 4 the first time, and then it was fine, but in some cases it wasn't able to start communication at all.
Strangely enough Wire.status() was returning I2C_OK right before this call.
Finally i saw that 4 is returned when:
if(!twi_write_start()) return 4;//line busy

And what i did was to add an additional delay in twi_write_start

static bool twi_write_start(void) {
  SCL_HIGH();
  SDA_HIGH();
---->>>>  twi_delay(twi_dcount);
  if (SDA_READ() == 0) return false;
  twi_delay(twi_dcount);
  SDA_LOW();
  twi_delay(twi_dcount);
  return true;
}

after i added this, now it works w/o any trouble. So i was wondering Is it correct to expect that the rise time for SDA will be just a cycle ? Especially if i had called before Wire.status, which ends with calling if(!twi_write_start()) , which puts SDA LOW at the end. But perhaps for consistency it is good to wait a bit after both lines are put high, to make a reading if the line rose.

I am by far not too knowledgeable in I2C, and maybe my hw design (with both sensors connected to 10 cm wires) is not good enough, but with this fix,the results are quite stable right now

[themindfactory]

I would say this is specific to you, from my experience with I2C devices,
if they are either designed with pure logic they are fast to reply to state
changes, if they are badly designed or controlled via a software I2C like a
slave device in a microcontroller, depending on design they can be slow and
require delays.

RichardS

On Mon, Sep 26, 2016 at 7:57 AM, Vladimir Savchenko <
notifications@github.com> wrote:

Basic Infos Hardware

Hardware: ESP-12F (80Mhz)
Core Version: 2.3.0
Description

In the last weeks i had extreme trouble in establishing connection with a
CO2 Sensor (CDM7160) over I2C. Tried various kinds of pullup resistors,
finally settled on 2k. And with lot's of error recovery code i was able to
read from the sensor most of the time. Then i connected a Dust Sensor over
I2C (PM2005), and then the whole thing became very unstable. The most time
Wire.endTransmission() was throwing 4 the first time, and then it was fine,
but in some cases it wasn't able to start communication at all.
Strangely enough Wire.status() was returning I2C_OK right before this call.
Finally i saw that 4 is returned when:
if(!twi_write_start()) return 4;//line busy

And what i did was to add an additional delay in twi_write_start

static bool twi_write_start(void) {
SCL_HIGH();
SDA_HIGH();
---->>>> twi_delay(twi_dcount);
if (SDA_READ() == 0) return false;
twi_delay(twi_dcount);
SDA_LOW();
twi_delay(twi_dcount);
return true;
}

after i added this, now it works w/o any trouble. So i was wondering Is it
correct to expect that the rise time for SDA will be just a cycle ?
Especially if i had called before Wire.status, which ends with calling
if(!twi_write_start()) , which puts SDA LOW at the end. But perhaps for
consistency it is good to wait a bit after both lines are put high, to make
a reading if the line rose.

I am by far not too knowledgeable in I2C, and maybe my hw design (with
both sensors connected to 10 cm wires) is not good enough, but with this
fix,the results are quite stable right now

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2551, or mute the thread
https://github.com/notifications/unsubscribe-auth/AINdaSrhajRgIiMsgWweWz3mwmq2c4kfks5qt7MPgaJpZM4KGb_j
.

[vlast3k]

i understand, indeed this one seems to be particularly bad designed and
picky :(

On Mon, Sep 26, 2016 at 6:58 PM, themindfactory notifications@github.com
wrote:

I would say this is specific to you, from my experience with I2C devices,
if they are either designed with pure logic they are fast to reply to state
changes, if they are badly designed or controlled via a software I2C like a
slave device in a microcontroller, depending on design they can be slow and
require delays.

RichardS

On Mon, Sep 26, 2016 at 7:57 AM, Vladimir Savchenko <
notifications@github.com> wrote:

Basic Infos Hardware

Hardware: ESP-12F (80Mhz)
Core Version: 2.3.0
Description

In the last weeks i had extreme trouble in establishing connection with a
CO2 Sensor (CDM7160) over I2C. Tried various kinds of pullup resistors,
finally settled on 2k. And with lot's of error recovery code i was able
to
read from the sensor most of the time. Then i connected a Dust Sensor
over
I2C (PM2005), and then the whole thing became very unstable. The most
time
Wire.endTransmission() was throwing 4 the first time, and then it was
fine,
but in some cases it wasn't able to start communication at all.
Strangely enough Wire.status() was returning I2C_OK right before this
call.
Finally i saw that 4 is returned when:
if(!twi_write_start()) return 4;//line busy

And what i did was to add an additional delay in twi_write_start

static bool twi_write_start(void) {
SCL_HIGH();
SDA_HIGH();
---->>>> twi_delay(twi_dcount);
if (SDA_READ() == 0) return false;
twi_delay(twi_dcount);
SDA_LOW();
twi_delay(twi_dcount);
return true;
}

after i added this, now it works w/o any trouble. So i was wondering Is
it
correct to expect that the rise time for SDA will be just a cycle ?
Especially if i had called before Wire.status, which ends with calling
if(!twi_write_start()) , which puts SDA LOW at the end. But perhaps for
consistency it is good to wait a bit after both lines are put high, to
make
a reading if the line rose.

I am by far not too knowledgeable in I2C, and maybe my hw design (with
both sensors connected to 10 cm wires) is not good enough, but with this
fix,the results are quite stable right now

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2551, or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AINdaSrhajRgIiMsgWweWz3mwmq2c4kfks5qt7MPgaJpZM4KGb_j>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2551 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAeDp8GOhtPSPcbOVcjarkhUO9Iiaj_Nks5qt-uIgaJpZM4KGb_j
.