I was going to say - 222kHz is too fast to run JS for, but 222Hz should be fine :)
However, it could be that there's an issue because of the falling edge triggering. What's the 'normal' state of the signal line? High, with 8us 'low' pulses? If so maybe try edge:rising?
Why? Espruino actually triggers on both edges (in case you need debounce) but the hardware provides no way to know which edge it was, so the IRQ handler checks the value as soon as it runs. But because it's an 8uS pulse, it's possible that if the IRQ gets delayed by a few uS because of Bluetooth activity, and then by the time it runs the signal is back to the default state.
But if you're checking for the edge when the signal returns back to the default state then you should be ok.
Potentially you could set it up to trigger on both edges and then poke the underlying hardware to make it only actually trigger on rising or falling though...
Another option is to use setWatch with some compiled C code and irq:true so it runs as soon as the IRQ occurs, or even you could use the nRF52 PPI functionality to trigger SPI sends directly from the IRQ without even getting the processor involved (https://www.espruino.com/NRF52LL) however that's definitely a bit tricker!
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.
I was going to say - 222kHz is too fast to run JS for, but 222Hz should be fine :)
However, it could be that there's an issue because of the
falling
edge triggering. What's the 'normal' state of the signal line? High, with 8us 'low' pulses? If so maybe tryedge:rising
?Why? Espruino actually triggers on both edges (in case you need debounce) but the hardware provides no way to know which edge it was, so the IRQ handler checks the value as soon as it runs. But because it's an 8uS pulse, it's possible that if the IRQ gets delayed by a few uS because of Bluetooth activity, and then by the time it runs the signal is back to the default state.
But if you're checking for the edge when the signal returns back to the default state then you should be ok.
Potentially you could set it up to trigger on both edges and then poke the underlying hardware to make it only actually trigger on rising or falling though...
Another option is to use
setWatch
with some compiled C code andirq:true
so it runs as soon as the IRQ occurs, or even you could use the nRF52 PPI functionality to trigger SPI sends directly from the IRQ without even getting the processor involved (https://www.espruino.com/NRF52LL) however that's definitely a bit tricker!