Reliability of counting via interrupts on nrf52

[BarneyH]

Hello All,

Hoping to hear your opinion as I have little experience on how reliably the following would work.

The device should count pulses or edges from a reed switch in a reliable way and provide those values via BLE. Now apart from the obvious hardware debouncing challenge, I read about lost counts under some circumstance from people using the interrupts and wonder if this just a matter of implementation or simply hardware limits.

If concurrent counting and BLE communication is an issue, do you think a separate serial to parallel shift register, which the nrf could read out at regular intervals would work?

Thank you for your opinion on this

Kind regards

Barney

[Daniel Chisholm]

Presumably you will first debounce this in hardware?

Once that is done, what is the shortest possible time between legitimate debounced edges that you will need to count? Once you have that number you can compare it to worst-case interrupt latency you will get when running BLE (you didn't mention if you are using the softdevice on the nrf5 sdk, or if you are using ncs, etc). If interrupt latency is less than your shortest possible interval between signals, then interrupts should count every edge and miss none, without any additional hardware beyond the hardware debouncing.

If interrupt latency is too slow then you need hardware help.  If you have an available TIMER peripheral, you can have it operate in counter mode, and therefore have a correct count with no missed edges.  Or, you can build off chip hardware (counter chip, or shift register, etc) to accomplish the same task (count edges for the interrupt service routine even when it's latency is such that it is being called after more than one edge has fired)