Re: ESP-WROOM-32 / GPIO16/17
Posted: Mon Mar 19, 2018 8:08 pm
It might be too early, but your hint was definitely needed here.
I fought three problems so far:
.) Added 2k2 pullups -> no scrambled LCD since then.
.) I was using breadboard-cables, but they are a biiiit too small for female pinstripe connectors, so I soldered male pinstripe-connectors with shielded cables for the I2C devices, which eliminated the other half of randomly occuring problems on the bus.
.) Running web pages is tricky. Once it works for a PC with Firefox, a page refresh on an android with chrome browser may lock up the cpu. Does it? No... it just stays in the 'while client.connected()' loop forever, making your I2C devices look like the bus is frozen (and everything else... no reaction to serial bytes). Finally I'm watching millis() within the loop, 'break'-ing out of it when stuck longer than 4 seconds. So that was a third thing which made me believe Wifi disturbs the I2C bus.
Surprisingly, the client doesn't seem to be connected when the loop comes to that question again. Good for me, so my solution works.
The only thing I sometimes see:
I'm also displaying the time in the lower right corner of the 20x4 LCD (updated every second), and usually write "SD card OK" on the top left. Every now and then it says "5D card ok". I saw "8D card ok" rarely. I believe it's not a code error, but comes from 65535 minutes (where the last 5 is displayed on the top left).
As I haven't seen anything worse since yesterday, I'd just live with these two additional pixels if they like to show. I haven't shielded the I2C connectors from the antenna yet (only the cables), and since pushing the RTClock deeper into its connector eliminated a getTime problem I could still solder it to the board.
I fought three problems so far:
.) Added 2k2 pullups -> no scrambled LCD since then.
.) I was using breadboard-cables, but they are a biiiit too small for female pinstripe connectors, so I soldered male pinstripe-connectors with shielded cables for the I2C devices, which eliminated the other half of randomly occuring problems on the bus.
.) Running web pages is tricky. Once it works for a PC with Firefox, a page refresh on an android with chrome browser may lock up the cpu. Does it? No... it just stays in the 'while client.connected()' loop forever, making your I2C devices look like the bus is frozen (and everything else... no reaction to serial bytes). Finally I'm watching millis() within the loop, 'break'-ing out of it when stuck longer than 4 seconds. So that was a third thing which made me believe Wifi disturbs the I2C bus.
Surprisingly, the client doesn't seem to be connected when the loop comes to that question again. Good for me, so my solution works.
The only thing I sometimes see:
I'm also displaying the time in the lower right corner of the 20x4 LCD (updated every second), and usually write "SD card OK" on the top left. Every now and then it says "5D card ok". I saw "8D card ok" rarely. I believe it's not a code error, but comes from 65535 minutes (where the last 5 is displayed on the top left).
As I haven't seen anything worse since yesterday, I'd just live with these two additional pixels if they like to show. I haven't shielded the I2C connectors from the antenna yet (only the cables), and since pushing the RTClock deeper into its connector eliminated a getTime problem I could still solder it to the board.