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

[BarneyH]

Dear Daniel and Edvin,

Thank you very much for your hints.
I am expecting signals slower than 1 Hz and a minimum 100 ms ON-time. For debouncing I am thinking of a combined debounce/esd-protection chip, MAX16054 was the first hit that might work.
For the interrupt latency I found less than 4 microseconds with SoftDevice (which I will use) on another thread, I guess this is worst-case.

The app_button library seems fine for that use case, energy-wise this is probably the more efficient than PPI+timer?

Kind regards,
Barney

[Edvin]

Hello Barney,

If you are looking at signals that are that slow, I would definitely go with the app_button module, as it has a SW debounce that you can set as long (or short) as you like. The drawback is that it requires the LFXTAL to run, but it will probably be running either way if you intend to do BLE stuff in your application. I forgot to ask if you are using the nRF5 SDK or NCS. The app_button is from the nRF5 SDK, but there are similar things in NCS.

if you want to use the PPI approach, you will need external HW for debouncing.

As for priorities and collisions. If the minimum ON-time is 100ms, that is plenty of time in case it would collide with the Softdevice. It will simply trigger the interrupt when the softdevice is done. This would only be an issue if you would receive two interrupts within one softdevice operation, in which case you would only receive one callback.

Best regards,

Edvin