Reliability of counting via interrupts on nrf52

RE: Reliability of counting via interrupts on nrf52

Edvin — Thu, 20 Oct 2022 12:36:16 GMT

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

RE: Reliability of counting via interrupts on nrf52

BarneyH — Thu, 20 Oct 2022 10:18:15 GMT

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

RE: Reliability of counting via interrupts on nrf52

Edvin — Thu, 20 Oct 2022 09:00:09 GMT

Hello Barney,

At first, I thought about using PPI + a timer in counter mode for this. If you search for "PPI timer counter" here on DevZone you should see a bunch of tickets discussing the implementation of this.

However, it depends on the frequency of what you are trying to measure. If you need a debounce, the PPI approach will not work that good. Perhaps you want to look into the app_button library if you need a software debounce. If you have time for a debounce, then I think the app_button is probably sufficient.

So what is the frequency of the signal you are trying to measure? Are we talking 10Hz or 1MHz?

Best regards,

Edvin

RE: Reliability of counting via interrupts on nrf52

Daniel Chisholm — Wed, 19 Oct 2022 13:26:10 GMT

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)