You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for the quick patch. By the way, I don't claim to understand the patch or know why it fixes anything, I just pasted it from someone else on a forum after verifying it fixes my issues. Hopefully it made more sense to you than it did to me :)
Thanks, that fixed a problem I had. My SSD1306 OLED showed often after some minutes but always after some hours strange things (scrambled content, ...)
It's frustrating that this is evidently the only way to fix this with the current devices (I understand this compensates for a hardware flaw, right?)
So far this code is working better for me: in my limited tests tonight - with an SSD1306-based 128x32 monochrome OLED as well as an MS5637 baro sensor - it only glitched once... impressive considering it was glitching readily and regularly before.
Per my followup on the forum, I2C on the ESP32 still seems particularly sensitive to interference (noise, RC loads, etc.) but it's definitely much less sensitive when using these slower-but-dependable registers. However, I've got more testing to do to see if this makes the I2C comms truly reliable now.
@MartyMacGyver I agree, but it still makes me sad to have to slow things down for them to work. Hopefully later silicons will have this issue addressed.
@me-no-dev At that point some of the more costly workarounds will need to be revisited (particularly these register ones, since they aren't just a one-time cost but a run-time cost). I imagine there's quite a lot of r0 silicon out there already... not sure what devices being sold have r1 silicon at this point.
A good way to handle this would be with compile-time defines that are mediated by the hardware selections in Arduino.
Update: I ran this for several hours with the OLED as well as another sensor in circuit. It didn't glitch and lock up again. Haven't tested it more thoroughly but it's definitely improved.
Update: connected are: SSD1306 OLED, BMP180, BME280, LM75, MCP23008
Running since 56 hours without problems.
That's a completely new feeling when it works several days :-)
9 commit comments
marcmerlin commentedon Mar 25, 2017
Thanks for the quick patch. By the way, I don't claim to understand the patch or know why it fixes anything, I just pasted it from someone else on a forum after verifying it fixes my issues. Hopefully it made more sense to you than it did to me :)
hcs-svn commentedon Mar 27, 2017
Thanks, that fixed a problem I had. My SSD1306 OLED showed often after some minutes but always after some hours strange things (scrambled content, ...)
With this version the problem is gone.
Jorgen-VikingGod commentedon Mar 28, 2017
I can also report, the fix is working great on my sources too.
me-no-dev commentedon Mar 28, 2017
those are good and bad news at the same time :D the "new" registers are slower than the old ones ;)
MartyMacGyver commentedon Mar 28, 2017
Better slower than unusable!
It's frustrating that this is evidently the only way to fix this with the current devices (I understand this compensates for a hardware flaw, right?)
So far this code is working better for me: in my limited tests tonight - with an SSD1306-based 128x32 monochrome OLED as well as an MS5637 baro sensor - it only glitched once... impressive considering it was glitching readily and regularly before.
Per my followup on the forum, I2C on the ESP32 still seems particularly sensitive to interference (noise, RC loads, etc.) but it's definitely much less sensitive when using these slower-but-dependable registers. However, I've got more testing to do to see if this makes the I2C comms truly reliable now.
me-no-dev commentedon Mar 28, 2017
@MartyMacGyver I agree, but it still makes me sad to have to slow things down for them to work. Hopefully later silicons will have this issue addressed.
MartyMacGyver commentedon Mar 28, 2017
@me-no-dev At that point some of the more costly workarounds will need to be revisited (particularly these register ones, since they aren't just a one-time cost but a run-time cost). I imagine there's quite a lot of r0 silicon out there already... not sure what devices being sold have r1 silicon at this point.
A good way to handle this would be with compile-time defines that are mediated by the hardware selections in Arduino.
MartyMacGyver commentedon Mar 29, 2017
Update: I ran this for several hours with the OLED as well as another sensor in circuit. It didn't glitch and lock up again. Haven't tested it more thoroughly but it's definitely improved.
hcs-svn commentedon Mar 29, 2017
Update: connected are: SSD1306 OLED, BMP180, BME280, LM75, MCP23008
Running since 56 hours without problems.
That's a completely new feeling when it works several days :-)