Does this library work properly with ESP8266?

[bertrik]

Is this library also supposed to work with ESP8266?

I tried using it but got a lot of weird problems like reboot-loops. This happened even with the Single.ino example. One suspicion is that the initialisation sequence (calls sensor.init(), setSignalRateLimit(), setMeasurementTimingBudget()) takes too long. I was able to "fix" this by splitting the initialisation sequence up, but I don't feel very confident about the library in combination with the ESP8266. Using the same sensor with an atmel avr does seem to work.

[RemcoMusic]

Is this library also supposed to work with ESP8266?

I tried using it but got a lot of weird problems like reboot-loops. This happened even with the Single.ino example. One suspicion is that the initialisation sequence (calls sensor.init(), setSignalRateLimit(), setMeasurementTimingBudget()) takes too long. I was able to "fix" this by splitting the initialisation sequence up, but I don't feel very confident about the library in combination with the ESP8266. Using the same sensor with an atmel avr does seem to work.

I've got the same problem. Could you show me how you fixed it?

[bertrik]

I split the initialisation in a few steps. The call to .init(); and .setTimeout(500); is done in setup(). The call to .setMeasurementTimingBudget(200000) is done in a separate invocation in loop() as is the call to .readRangeSingleMillimeters();

So I split up the calls to vl53l0x methods into calls that are done while exiting loop() in between, presumably giving the ESP8266 some time to do other stuff (outside of loop()) like feeding the watchdog. I'm not completely sure if this is this is the correct solution, but at least it seemed to work for me.

My code is at https://github.com/bertrik/crawlspace

[kevin-pololu]

I'm looking into this right now and finding that, even with LONG_RANGE and HIGH_ACCURACY defined in Single.ino, the entire setup() function finishes in about 150 ms. So I'm surprised that your sensor initialization is taking long enough for the watchdog timer to reset the ESP8266 (if that is actually what is happening), since my understanding is that the soft WDT reset happens after about 3 seconds of it not being serviced.

Were you running the Single.ino example unmodified? Do you have a measurement or estimate of how much time elapsed between the start of execution and the reset? What type of ESP8266 board were you using?

[Tech-TX]

I've just done a quick look-over of the library and example. Nope, no way this will run on an ESP as-is. It looks like it probably could with some judicious insertions of yield(); here and there, as well as removing things like the while (1) {} which will cause a WDT reset. The yields could be added in with an #ifdef so that Arduinos don't blow chunks, the other things I'll have to look at when I start using the library some month(s) from now.

BTW, thank you for not putting the Wire.begin() inside of your library. That makes it awkward if we don't use the default pins. Since the ESP8266 bit-bangs the I2C, you can pick any two pins that are convenient.

edit, 12/15/2019 using the 'continuous' example, what I'm seeing is that it's really easy to get the part stuck with the current ESP8266 Wire library; hitting it with an external RESET while it's running has a good chance of breaking the transmission mid-byte, and the part hangs the I2C bus with SDA stuck low. That's not Polulu's fault, and I suspect the AVR Wire library would have the same issue since it doesn't attempt bus recovery. I'm working on a bus recovery sequence for the ESP8266 that will hopefully correct that, but simply driving XSHUT from the ESP's RESET pin makes it restart reliably 100% of the time.

ESP users still need to change that while (1) {} in setup() to while (1) {yield();} or while (1) {delay(100);} so that the WDT gets fed. You can modify that to while (1) {delay(100);} in the two examples without having to do #ifdefs for the ESP parts; it'd work for other micros without errors. Any delay value will work for the ESPs, it doesn't need to be 100ms.

[hsaturn]

I'm looking into this right now and finding that, even with LONG_RANGE and HIGH_ACCURACY defined in Single.ino, the entire setup() function finishes in about 150 ms. So I'm surprised that your sensor initialization is taking long enough for the watchdog timer to reset the ESP8266 (if that is actually what is happening), since my understanding is that the soft WDT reset happens after about 3 seconds of it not being serviced.

Were you running the Single.ino example unmodified? Do you have a measurement or estimate of how much time elapsed between the start of execution and the reset? What type of ESP8266 board were you using?

Hello, I have I think the same problem. And I don't think this is a WDT related issue. Each time I have loops, this is because the chip is in a kind of bad state. If I power down an up, all is fixed and working well.

My guess is that there is a bug in your init sequence. The loop is VERY fast (many reboot / s).

I can't use your library with that bug, because the reboot loop is infinite (the chip never returns back to the normal, except but power it down/on).

One workaround should be to wire the 3V of the chip not to 3v, but to an output of the ESP and power this output during initialization. Thus, the chip will have the opportunity to return back to the normal.

I think I'm gonna try to search for the bug.

Regards