Working devices

[everslick]

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]

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

Chuck.

[stickbreaker]

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

[everslick]

That was the plan.

On Sat, Dec 2, 2017 at 9:10 PM, chuck todd notifications@github.com 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 https://github.com/stickbreaker/arduino-esp32/issues/14#issuecomment-348716754, or mute the thread https://github.com/notifications/unsubscribe-auth/AB0jL_YxAq3OUxQSv0rLCT4keGbxmEugks5s8a7MgaJpZM4QzbLT .

[stickbreaker]

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]

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

[beegee-tokyo]

Working I2C slave TSL2561 Light sensor

[chinswain]

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]

@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]

@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]

@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]

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]

@stickbreaker Confirmed working!

[stickbreaker]

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

Chuck.

[mjs513]

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

[stickbreaker]

@mjs513 will do!

[lbernstone]

PCA9685 seems to work well using Adafruit's library

[gdombiak]

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 a153f6ad280e5932be9c80341556348ff505d586 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]

@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]

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]

@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]

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

Thanks, Gaston

[stickbreaker]

@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]

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]

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

[larissa-n]

MMA8452 HTU21D

Great fixes. Thanks!

[chinswain]

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

[chinswain]

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.