Current consumption rtc-> ppi ->gpiote on nrf52

RE: Current consumption rtc-> ppi ->gpiote on nrf52

haakonsh — Wed, 27 Jan 2021 12:22:13 GMT

I honestly don't remember :/

RE: Current consumption rtc-> ppi ->gpiote on nrf52

gilbertjuly — Sat, 23 Jan 2021 07:29:17 GMT

Hi Håkon, you presented the "rtc_ppi_gpiote.zip", I wonder which version of the SDK you were using. I'd like to have it a try. Thank you.

Gilbert

RE: Current consumption rtc-> ppi ->gpiote on nrf52

butch — Tue, 08 May 2018 13:33:08 GMT

Thanks. That seems to confirm that whatever errata/PAN existed in the NRF51, with respect to the PPI and the HFRC, has been fixed in the NRF52. In other words, the PPI draws negligible current while cpu is sleeping.

RE: Current consumption rtc-> ppi ->gpiote on nrf52

haakonsh — Fri, 04 May 2018 10:48:11 GMT

Hey butch,

I've taken new measurements at an interval of 10s.

Interrupt:

PPI:

As you can see there's not much difference between the average current consumption, but the peak is halved with PPI. You should definitely use PPI + GPIOTE as it is entirely independent of the CPU activity (SoftDevice has the highest exectution priority).

The base current is somewhat higher with the DK than just our reference design, so you should expect a slightly lower current consumption in your product.

Cheers,

Håkon.

RE: Current consumption rtc-> ppi ->gpiote on nrf52

haakonsh — Thu, 05 Apr 2018 13:43:53 GMT

Hey Butch,

I get your point, and I will make some measurements soon, but I'm swamped at the moment dude to backlog from the Easter Holidays. I'll try to get it done by next week.

The PPI system is really cool, you can make entire logical state machines without a CPU^^. Just throw in TIMERs, COUNTERs, ADCs, GPIOTEs, etc.

Cheers,

Håkon.

RE: Current consumption rtc-> ppi ->gpiote on nrf52

butch — Fri, 23 Mar 2018 15:40:24 GMT

Thank you very much. (I would test it myself if I had a scope.)

However, your graphs do not show the minimum. The minimum would show the current during sleep. It might be that the minimum for PPI case is more than the minimum for interrupt case. (The resolution of the graphs does not let me compare the exact minimums.)

In other words, you are triggering the timer every 10ms, whereas I am interested in triggering the timer every ten seconds or so. In my case, the long tail of the curve at a lower minimum might mean that the average was much less (despite the high max current for the peak.)

My actual application is an "I'm alive" LED, that flashes very briefly (the minimum that the human eye can see) every ten seconds or so. I want to use the PPI to toggle the LED off. While the LED on, the current of the PPI is insignificant, since the current of the LED is much more. While the LED is off, the current of the PPI+GPIOTE might be significant (relative to say they 4 (?) uSec sleeping current of the CPU + LFXO + RTC.) The question is not only what is the current of PPI+GPIOTE but is it really the current of the PPI+GPIOTE+HFRC (emphasis on HFRC, as it seems to have been in early revisions of the nrf51?)

Whereas your illustrated use case is more of "PWM" or "signal", i.e. with much higher frequency. In that case, yes there are clear advantages to using the PPI and GPIOTE.

And maybe my question is moot, if my implementation disables the PPI and GPIOTE when the LED is turned off. But that implementation might require an interrupt anyway? Maybe the implementation can configure the PPI so that the rtc event not only triggers the gpiote task to toggle the LED but also triggers a fork task that disables one of the PPI's own channel groups via the task NRF_PPI->TASK_CHG[0].DIS. One needs to know the specification for current of the enabled PPI and GPIOTE to know whether such a design is beneficial for a given frequency of operation.

I very much admire the design of the PPI and GPIOTE as a hw implementation of the sw concept of signals (in the Qt terminology, signals and slots.)

RE: Current consumption rtc-> ppi ->gpiote on nrf52

haakonsh — Fri, 23 Mar 2018 13:24:20 GMT

Hey butch,

I've made a small application demonstrating PPI vs CPU interrupts. devzone.nordicsemi.com/.../rtc_5F00_ppi_5F00_gpiote.zip

You have to compile the application with the definition USE_PPI to use PPI+GPIOTE.

I've also compared the current consumption between the two:
With PPI:

With CPU interrupt:

As you can see the difference is dramatic. The RTC interrupt will also be at the mercy of it's execution/preemption priority, whereas the PPI system is completely independent from the CPU state.

Cheers,

Håkon.