nrf52833 + PPI + PWM Pulse Counter

[embeddedER]

Hi Team,

We are developing an application where we have PWM like pulses coming from our sensor. Max frequency of this would be around ~8k. We want to poll the number of pulses we have received in X amount of time (let's say this X amount of time is triggered by timer).

Currently we have configured an interrupt on the PWM HI->LO and have counter in the ISR. This counter is just a global variable and we reset after reading it from timer handler, so we can know how may pulses are received since we last read the counter.

This approach works however because of ISR, we have context switch every time there is an interrupt. We would like to do other stuff like BLE data transfer when this is happening in parallel. So, basically we would like to avoid CPU interruption every time there is an event. We are thinking of having HW counter and polling it every time we want.

However, I was reading through the PPI on nrf52833 and I was wondering:

1. Is it possible to do such counting, without interrupt and CPU cycles?
2. Since ours is a battery operated device, does using PPI affect sleep current? Currently we have measured sleep current as 2.7uA with our custom HW.

Environment: nrf52833 and ncs v1.8.0

TIA!

[Sigurd]

Hi,

embeddedER said:

Is it possible to do such counting, without interrupt and CPU cycles?

Yes, I have some sample code that showcases this here: https://github.com/sigurdnev/ncs-playground/blob/master/samples/pulse_detector/src/main.c

embeddedER said:

Since ours is a battery operated device, does using PPI affect sleep current? Currently we have measured sleep current as 2.7uA with our custom HW.

Yes, when the TIMER Counter increases because of the PWM pulse the current will go a bit up.

[embeddedER]

Thanks Sigurd for the prompt response.

We will look into the example you shared.

One follow up question: To save the power if we disable the PPI channel, it should stop counting and consuming that extra power, right? Basically, we would like to enable/disable this PPI at runtime. To make sure that we have it only when we need it.

[hmolesworth]

What's "a bit"? One might assume that the HFCLK isn't doing much on the Timer as "In counter mode, the TIMER's internal Counter register is incremented by one each time the COUNT task is triggered, meaning the timer frequency and the prescaler are not utilized in counter mode". I don't see figures for PPI, which presumably also requires HFCLK ..

[Sigurd]

embeddedER said:

One follow up question: To save the power if we disable the PPI channel, it should stop counting and consuming that extra power, right? Basically, we would like to enable/disable this PPI at runtime. To make sure that we have it only when we need it.

Correct.

[Sigurd]

hmolesworth said:

What's "a bit"? One might assume that the HFCLK isn't doing much on the Timer as "In counter mode, the TIMER's internal Counter register is incremented by one each time the COUNT task is triggered, meaning the timer frequency and the prescaler are not utilized in counter mode". I don't see figures for PPI, which presumably also requires HFCLK ..

GPIOTE -> PPI -> TIMER draws power, I would have to double check to be sure, but if I recall correctly it's a 1.1uC charge when its "wakes" up to increment the counter register.