You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • 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!

About

Avatar for Gordon @Gordon started