Working devices #14

everslick · 2017-12-02T19:07:10Z

I want to confirm that I have the following devices working properly with your code:

DS3231 (RTC)
AT24C32 (EEPROM)
BME680 (TEMP/PRES/HUMI/GAS SENSOR)

Noteworthy is, that I have all I2C communication coded so I never have to use endTransmission(false);

stickbreaker · 2017-12-02T19:26:40Z

Sounds Good, @me-no-dev is critiquing / formatting / fixing for inclusion into the main branch.

Chuck.

stickbreaker · 2017-12-02T20:10:52Z

maybe if I leave this open others will add to it.

everslick · 2017-12-02T20:44:19Z

That was the plan.

…

On Sat, Dec 2, 2017 at 9:10 PM, chuck todd ***@***.***> wrote: maybe if I leave this open others will add to it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB0jL_YxAq3OUxQSv0rLCT4keGbxmEugks5s8a7MgaJpZM4QzbLT> .

stickbreaker · 2017-12-02T21:07:59Z

Yea, well, I was excited to have an issue that I could close. ♐️ (any Idea what this means?) I type sarcastic and got Sagittarius?

stickbreaker · 2017-12-03T01:45:41Z

Working I2C Slave Devices: MCP23008, 24LC512, 24LC64, 24LC32, DS1307, Arduino Uno as Slave,

beegee-tokyo · 2017-12-14T06:22:45Z

Working I2C slave TSL2561 Light sensor

chinswain · 2017-12-15T02:53:46Z

BMP280, MCP23017 and ADS1115 confirmed working and stable for several days (running 24\7).

AT24C32 not working for me but most likely the library I'm using ((https://github.com/sleemanj/DS3231_Simple) although I cannot see the issue...

stickbreaker · 2017-12-15T15:38:37Z

@chinswain looked through that library, Here is the necessary change.

uint8_t DS3231_Simple::readEEPROMByte(const uint16_t address)
{
  uint8_t b = 0;
  
  if(!i2cReady(EEPROM_ADDRESS)) return 0; // device did not answer
  
  Wire.beginTransmission(EEPROM_ADDRESS); // DUMMY WRITE
  Wire.write((uint8_t) ((address>>8) & 0xFF)); 
  Wire.write((uint8_t) ((address) & 0xFF)); 

#ifdef ARDUINO_ARCH_ESP32
  if(Wire.endTransmission(false)!=7) // don't fail on Bare Restart queued
#else
  if(Wire.endTransmission(false)) // Do not send STOP, just restart
#endif
  {
    return 0;
  }
  
  if(Wire.requestFrom(EEPROM_ADDRESS, (uint8_t) 1))
  {
    b = Wire.read();
  }
  
  Wire.endTransmission(); // Now send STOP
  
  return b;
}

Chuck.

chinswain · 2017-12-15T18:02:47Z

@stickbreaker I assume I need to add this also to the library?:

bool i2cReady(uint8_t adr){
uint32_t timeout=millis();
bool ready=false;
while((millis()-timeout<100)&&(!ready)){
	Wire.beginTransmission(adr);
	ready=(Wire.endTransmission()==0);
	}
return ready;
}

stickbreaker · 2017-12-15T18:34:11Z

@chinswain Na, cut the reference to i2cReady(). Didn't see I added that. I went through that library and adjusted it, but the more I looked the less I liked it. the library was kinda written 'general' purpose, but it's pagewrite(), EEPROM_BYTES does not handle >32k eeproms (24lc32..24lc256 only).
I don't have one of these boards, so none of the Alarm calls work.
I'd have to structurally change it to utilize the ESP's larger buffers. I'll never use it so I won't waste my time 'fixing' it.

The reason I use i2cRead() is a design philosophy. This library assume (ass u me) that the EEPROM is always ready when I wants to write/read to it. It then does it's work(read/write) then waits until it is done.
If it encounters and error, by definition it is never done, therefore It hangs.

uint8_t DS3231_Simple::writeBytePagewizeEnd()
{
  if(Wire.endTransmission() > 0)
  {
    // Failure
    return 0;
  }
  // Poll for write to complete
  while(!Wire.requestFrom(EEPROM_ADDRESS,(uint8_t) 1));  
  return 1;
}

This while{} can hang forever if the I2c bus has a problem.

my i2cReady() will hang for 100ms max.

I just pushed my modified into my fork at stickbreaker/DS3231_simple
I only fixed one example DataLogger.ino (had to change the EEPROM address to 0x50), Pin A1 does not exist on my ESP32.

Chuck.

chinswain · 2017-12-15T18:42:45Z

Thanks Chuck - I was only using it as it was part of the DS3231 code. Have you come across any Arduino libraries for the AT24C32 that work on the esp32 in an acceptable manner? I'm looking to store a small structure with a handful of dates long term (Load values on boot, update rarely).

chinswain · 2017-12-15T18:52:26Z

@stickbreaker Confirmed working!

stickbreaker · 2017-12-15T19:04:24Z

@chinswain This library extEEPROM looks like it would do what you want. Simple, direct, not flowery.

Chuck.

mjs513 · 2017-12-25T13:44:45Z

You can add the MPU9250 to the list of working devices. This did not work with the current git pull of the core.

stickbreaker · 2017-12-25T16:35:25Z

@mjs513 will do!

lbernstone · 2018-02-03T04:27:54Z

PCA9685 seems to work well using Adafruit's library

gdombiak · 2018-02-18T21:16:17Z

Another successful story. Thanks Chuck for your i2c fixes.

SSD1306 + CCS811 + BME680 = It works now.

I applied your fix to latest ESP32 from master (commit a153f6a on Thu Feb 8 15:56:13 2018 +0200). I'm using Adafruit libraries for those 3 i2c sensors/display on a HUZZAH32 – ESP32. I did not have to change my sketch due to API changes :) . The sketch updates display with sensed data every second and sends data via HTTP to a server every 20 seconds. I'm not playing with threads directly.

Once in a while I get this in the Serial port but everything keeps working after that. Before this fix it used to crash and not be able to recover from Bus busy/timeout.

[E][esp32-hal-i2c.c:1113] i2cProcQueue(): TimeoutRecovery: expected=0ms, actual=2ms
[E][esp32-hal-i2c.c:609] i2cDumpI2c(): i2c=0x3ffc135c
[E][esp32-hal-i2c.c:610] i2cDumpI2c(): dev=0x60013000 date=0x16042000
[E][esp32-hal-i2c.c:611] i2cDumpI2c(): lock=0x3ffcc3e8
[E][esp32-hal-i2c.c:612] i2cDumpI2c(): num=0
[E][esp32-hal-i2c.c:613] i2cDumpI2c(): mode=1
[E][esp32-hal-i2c.c:614] i2cDumpI2c(): stage=3
[E][esp32-hal-i2c.c:615] i2cDumpI2c(): error=1
[E][esp32-hal-i2c.c:616] i2cDumpI2c(): event=0x3ffcc46c bits=10
[E][esp32-hal-i2c.c:617] i2cDumpI2c(): intr_handle=0x3ffcc49c
[E][esp32-hal-i2c.c:618] i2cDumpI2c(): dq=0x3ffcc620
[E][esp32-hal-i2c.c:619] i2cDumpI2c(): queueCount=1
[E][esp32-hal-i2c.c:620] i2cDumpI2c(): queuePos=0
[E][esp32-hal-i2c.c:621] i2cDumpI2c(): byteCnt=9
[E][esp32-hal-i2c.c:582] i2cDumpDqData(): [0] b5 R STOP buf@=0x3ffc3748, len=8, pos=8, eventH=0x0 bits=0
[E][esp32-hal-i2c.c:598] i2cDumpDqData(): 0x0000: ...&...a                         02 8a 00 26 90 00 19 61 
[E][esp32-hal-i2c.c:942] i2cDumpInts(): row  count   INTR    TX     RX
[E][esp32-hal-i2c.c:945] i2cDumpInts(): [01] 0x0001 0x0002 0x0001 0x0000 0x048cc108
[E][esp32-hal-i2c.c:945] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x048cc108
[E][esp32-hal-i2c.c:945] i2cDumpInts(): [03] 0x0009 0x0040 0x0000 0x0000 0x048cc10a
[E][esp32-hal-i2c.c:945] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0008 0x048cc10a

Thanks again for this amazing fix. I can finally use the ESP32!!!

Gaston

stickbreaker · 2018-02-19T01:53:39Z

@gdombiak I'm pleased it works for you.

This error message is not actually an error. It is just a message that the total transaction took longer than the calculated time. The calculate transfer time, usings the current bitrate rounded to zero milliseconds, but it actually took two milliseconds, so this device at 0x5A did some clock stretching.
i2cDumpInts() message decode:

That it loaded one byte into the tx Fifo [01] at tick 0x048cc108.
It then received a Start Transaction interrupt [02] at tick 108.
then nine bytes were moved through the hardware, one byte out and eight bytes in (9), the last byte move at tick 10C
then the STOP signal was processed at tick 10C, (all done!)

I did not expect this code to still exist in it's current state, it is more of a proof of concept. So, it is way more verbose than it needs to be.

Are you using the current release? The current release has a default timeout of 50ms. Earlier version did not have this default. If you are using the current release Wire.setTimeOut(milliseconds) can be used to adjust from the default of 50ms I would recommend not setting it to zero. The timeout does not impede the performance this library, but as you have experienced, a detected timeout results in a big block of text out Serial, which does slow down program execution.

Chuck.

gdombiak · 2018-02-19T04:11:51Z

Hey @stickbreaker, thanks for the prompt response and detailed explanation.

I installed the released version arduino-esp32-master-V0.1.2.zip and applied it to master latest of ESP32. Looking into Wire.cpp I see that the TwoWire constructor uses a timeout of 50 (line 49). I have not configured a timeout explicitly on my code. I can check if Adafruit libraries are changing the Wire.timeout. Let me know if you want me to look or test something locally.

Another good news: ESP32 (nodeMCU-32S) + SSD 1306 (128x64) + SHT31-D = success!

Thanks,
Gaston

stickbreaker · 2018-02-19T04:22:17Z

@gdombiak The problem was mine, it is debug code that should not trigger at the ERROR level of debugging. See my comment on issue #21. I have incorporated the change in the main repo, but I haven't yet made a new release.

You can follow the instructions to apply the change yourself, it will be a while before I make a new release. I am working on SLAVE MODE.

Chuck.

gdombiak · 2018-02-19T04:54:37Z

@stickbreaker thanks again! Should I apply your master or just apply your individual/last commit to my local files?

Thanks,
Gaston

stickbreaker · 2018-02-19T04:58:30Z

@gdombiak Yea, that will work if you have a fork. Most people just download the zip or manually merge the files into the current espressif/arduino-esp32. My fork is not up to date with the espressif/arduino-esp32. It is a couple of months old.

Chuck.

valki2 · 2018-03-25T07:26:55Z

Tested sucessfully: DOIT Devkit V1 and Devkit and AZDelivery ESP32 DevKitC with following i2c devices:

SSD1306 oled
Sensirion SHT31 (4 devices)
MCP23017-E/SP 16 I/O Expander
WINGONEER TCA9548A I2C IIC Multiplexer

rrobinet · 2018-03-25T09:53:26Z

Just to confirm that I have NO problems anymore with:
DS3231 RTC
BME280E Barometric sensor
Robert

larissa-n · 2018-03-28T21:52:00Z

MMA8452
HTU21D

Great fixes. Thanks!

chinswain · 2018-03-28T22:34:29Z

PCF8575 not working although I suspect it's an incompatibility with the library (https://github.com/skywodd/pcf8574_arduino_library/tree/master/PCF8575)

chinswain · 2018-05-24T17:54:56Z

LM75A confirmed working.

I'm not sure if this of any help to anyone? I have an LM75A and a DS3231 being polled for data every 10ms.

Tested a range of pull ups:

Clock is 400K ( Wire.setClock(400000L) ), default timeout.

stickbreaker closed this as completed Dec 2, 2017

stickbreaker reopened this Dec 2, 2017

stickbreaker closed this as completed Oct 6, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Working devices #14

Working devices #14

everslick commented Dec 2, 2017

stickbreaker commented Dec 2, 2017

stickbreaker commented Dec 2, 2017

everslick commented Dec 2, 2017 via email

stickbreaker commented Dec 2, 2017

stickbreaker commented Dec 3, 2017

beegee-tokyo commented Dec 14, 2017

chinswain commented Dec 15, 2017

stickbreaker commented Dec 15, 2017 •

edited

Loading

chinswain commented Dec 15, 2017 •

edited

Loading

stickbreaker commented Dec 15, 2017

chinswain commented Dec 15, 2017

chinswain commented Dec 15, 2017

stickbreaker commented Dec 15, 2017

mjs513 commented Dec 25, 2017

stickbreaker commented Dec 25, 2017

lbernstone commented Feb 3, 2018

gdombiak commented Feb 18, 2018 •

edited

Loading

stickbreaker commented Feb 19, 2018

gdombiak commented Feb 19, 2018

stickbreaker commented Feb 19, 2018

gdombiak commented Feb 19, 2018 •

edited

Loading

stickbreaker commented Feb 19, 2018

valki2 commented Mar 25, 2018

rrobinet commented Mar 25, 2018

larissa-n commented Mar 28, 2018

chinswain commented Mar 28, 2018

chinswain commented May 24, 2018

Working devices #14

Working devices #14

Comments

everslick commented Dec 2, 2017

stickbreaker commented Dec 2, 2017

stickbreaker commented Dec 2, 2017

everslick commented Dec 2, 2017 via email

stickbreaker commented Dec 2, 2017

stickbreaker commented Dec 3, 2017

beegee-tokyo commented Dec 14, 2017

chinswain commented Dec 15, 2017

stickbreaker commented Dec 15, 2017 • edited Loading

chinswain commented Dec 15, 2017 • edited Loading

stickbreaker commented Dec 15, 2017

chinswain commented Dec 15, 2017

chinswain commented Dec 15, 2017

stickbreaker commented Dec 15, 2017

mjs513 commented Dec 25, 2017

stickbreaker commented Dec 25, 2017

lbernstone commented Feb 3, 2018

gdombiak commented Feb 18, 2018 • edited Loading

stickbreaker commented Feb 19, 2018

gdombiak commented Feb 19, 2018

stickbreaker commented Feb 19, 2018

gdombiak commented Feb 19, 2018 • edited Loading

stickbreaker commented Feb 19, 2018

valki2 commented Mar 25, 2018

rrobinet commented Mar 25, 2018

larissa-n commented Mar 28, 2018

chinswain commented Mar 28, 2018

chinswain commented May 24, 2018

stickbreaker commented Dec 15, 2017 •

edited

Loading

chinswain commented Dec 15, 2017 •

edited

Loading

gdombiak commented Feb 18, 2018 •

edited

Loading

gdombiak commented Feb 19, 2018 •

edited

Loading