You are reading a single comment by @DrAzzy and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@DrAzzy
I would really want a way to disable this if it were done. While my intervals shouldn't be spewing errors, I'd like a way to set it to keep soldiering on - partial functionality may be better than
There's a special case that is particularly troublesome here though, and which your solution doesn't fix - and that is the case of things like network requests and I2C failures that block. In this case, you end up with the queue filled with error events that each block for like 30 seconds until they time out - by which time several more such intervals have entered the queue, and I've often had a hard time breaking out of it with ctrl+c. This is really unpleasant, and it happens in response to just about every wiring error in I2C, plus malfunctioning devices (my BMP180's always do that as soon as I close the project box and try to use it, and I've tried them mounted like 3 different ways, 4 different units, on every I2C bus, and they always work on the bench and then almost immediately fail when I set them running... but I digress).
Actually, what do you think about adding a timeout option to I2C.setup()? With, like, almost all I2C devices, if it isn't responding within a few milliseconds, giving it another 30,000 ms isn't going to make a difference, and it would be nice even just for the sake of speed in debugging to not have to wait through an unnecessarily long timeout... Or maybe the current timeout should just be shortened? Should it ever take that long for an I2C device to respond?