You are reading a single comment by @Gordon 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.
@Gordon
I think I've come across this before. OneWire is a bit unreliable on the nRF52 because the softdevice has a habit of just jumping in and doing stuff during reasonably timing critical sections.
While I believe interrupts are disabled during OneWire, I can't disable them fully without hitting instability, so the high priority low level Bluetooth ones still get serviced.
What you're seeing is a particularly bad case because you've got an active connection that's probably in high-speed mode, so the Bluetooth stack is pretty active.
I've got a few things using DS18B20 on nRF52 and they work pretty reliably - once disconnected I'm finding the failure rate is 1 in 50 or something and it's trivial to just try again if there's an error (which is good practice anyway I guess).
While I could use IRQs for the timing I believe that will also break, since the BLE stack always has higher priority than I can have I think. I'm pretty sure I did see someone setting up a timer peripheral to produce the relevant pulses, so that could be a possibility.