From 6411ac4e3c5c8e0ca360a2a5f959964e87e7b1db Mon Sep 17 00:00:00 2001 From: chuck todd Date: Mon, 2 Jul 2018 10:22:05 -0600 Subject: [PATCH] Remove confusing Debug output. (#1574) If Core Debug Level is at DEBUG, a confusing debug message will be emitted if the I2C transaction takes longer complete than the calculated minimum time. This original debug message was just to prove that this new i2c code could correctly handle SCL stretching or interrupt latency issues. This delay is not a problem, or an error. Usually it is caused by a higher priory interrupt starving the i2c ISR. Usually WiFi is the culprit. As long of this delay is within the configured timeout (by default 50ms, or can be set with Wire.setTimeOut(milliseconds);) no problem will occur and the transaction will successfully complete. Chuck. --- cores/esp32/esp32-hal-i2c.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/cores/esp32/esp32-hal-i2c.c b/cores/esp32/esp32-hal-i2c.c index 314f227c..e6b21815 100644 --- a/cores/esp32/esp32-hal-i2c.c +++ b/cores/esp32/esp32-hal-i2c.c @@ -990,15 +990,6 @@ i2c_err_t i2cProcQueue(i2c_t * i2c, uint32_t *readCount, uint16_t timeOutMillis) } if(eBits&EVENT_DONE) { // no gross timeout -#if ARDUHAL_LOG_LEVEL >= ARDUHAL_LOG_LEVEL_DEBUG - uint32_t expected =(totalBytes*10*1000)/i2cGetFrequency(i2c); - if((tAfter-tBefore)>(expected+1)) { //used some of the timeout Period - // expected can be zero due to small packets - log_e("TimeoutRecovery: expected=%ums, actual=%ums",expected,(tAfter-tBefore)); - i2cDumpI2c(i2c); - i2cDumpInts(i2c->num); - } -#endif switch(i2c->error) { case I2C_OK : reason = I2C_ERROR_OK;