Unfortunately it won't get it right 100% of the time especially with the odd interrupt conflict, and it looks like a bit got lost. Using cs in that way would help to always 're-frame' the data, and then you could use a CRC or similar to detect the rare transmit errors.
RE: console.log - this goes into an output buffer of ~256 bytes if I recall. As long as you don't fill that buffer it can be fast however when you do that (especially if connected via USB on the WiFi) it's likely to cause a few interrupts for USB as it attempts to send the data, and there is a possibility (without diving into the USB stack I couldn't say before) that they have equal or higher priority to the pin watch and could displace it.
... but most likely the buffer got full and caused the event queue to get full - but that should have flagged up an interpreter error.
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.
@maze1980 sounds spot on here.
Unfortunately it won't get it right 100% of the time especially with the odd interrupt conflict, and it looks like a bit got lost. Using cs in that way would help to always 're-frame' the data, and then you could use a CRC or similar to detect the rare transmit errors.
RE:
console.log
- this goes into an output buffer of ~256 bytes if I recall. As long as you don't fill that buffer it can be fast however when you do that (especially if connected via USB on the WiFi) it's likely to cause a few interrupts for USB as it attempts to send the data, and there is a possibility (without diving into the USB stack I couldn't say before) that they have equal or higher priority to the pin watch and could displace it.... but most likely the buffer got full and caused the event queue to get full - but that should have flagged up an interpreter error.