• State Verified Answer
  • Replies 1 reply
  • Subscribers 73 subscribers
  • Views 1726 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 200071
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Peripheral vs Libraries for power optimization

Hieu

Hello, I am working on optimizing the power consumption of our application.

I have got two design decisions that I would like to ask for some advises and opinions on.

1. PWM source:

Our application have a PWM-controlled RGB LED to display its various states (connected, advertising, etc.) by blinking or staying on/off.

From what I understand, using the PWM library and Low-power PWM actually use Timer peripheral interrupts to repeatedly control IO pins, and therefore should repeatedly wake the CPU up, reducing the effect of `sd_app_evt_wait()`.

Meanwhile, the nRF52832 has its own dedicated PWM peripheral. I think using this would save more power.

Is my understanding correct?

2. Time keeping source

I am using an application timer for time keeping and triggering periodic tasks, such as blinking above LEDs. I learned that the Timer library make use of RTC1 and SWI0 interrupts to operate.

I am wondering if switching to using a Timer peripheral with longer interrupt period would save more power than using Timer library.

I am working on nRF52832 using nRF5 SDK v14.1.0 and SoftDevice S132 v5.0.0.

Please advise.

Parents
  • +1

    First, a general rule of thumb when it comes to clocks. The high-frequency crystal uses ~250µA, while the low-frequency crystal uses ~0.25µA. Finding a way to ensure the high-frequency clock is not running when you are idling is the most important thing to do when you are trying to reduce the power consumption of an nRF5 based device.

    1. PWM source:

    The PWM hardware in the nRF52 is present to offer high-frequency (up to MHz range) PWM in a way that does not occupy the CPU constantly. It requires the HFCLK to be running and the peripheral itself also uses quite a bit of current. It is not the power efficient way to get a low-frequency signal like what you need for an LED.

    The nRF5 series include Programmable peripheral interconnect (PPI) which can be configured to enable peripherals to interact with each other without interrupting the CPU. For a power-optimized PWM you should use PPI to get the two repeating events from the RTC causing the GPIO pin to toggle between high and low.

    Note, that this is not what is done in the low power PWM example. The example is interrupt driven, which uses a bit more power than PPI would. The low power PWM example is much lower power than using the high-frequency clock and PWM peripheral, but using PPI you can get even better results. How much of a difference there is between PPI and interrupt depends on the frequency, and for lower frequencies, the difference can be very low.

    2. Time keeping source

    There are two peripherals that can be used to measure time. The TIMER is for the high-speed clock. The RTC is a much simpler peripheral with less configuration options, but it uses the low-frequency clock. As mentioned in the beginning of the post, avoiding the use of the high-frequency clock in sleep is the holy grail of power efficient firmware on the nRF5 series devices, so you should use the RTC.

    If your RTC expires often enough that the interrupts are using enough power to be noticeable, you should consider if the PPI could be used instead. Using PPI you can use the counter and COMPARE events to set up autonomous events to like GPIOTE and many other peripherals. You often want to use a COMPARE event from the RTC to CLEAR the RTC COUNTER. This gives you a recurring event.

    Best regards,
    Rune Holmgren

Reply
  • +1

    First, a general rule of thumb when it comes to clocks. The high-frequency crystal uses ~250µA, while the low-frequency crystal uses ~0.25µA. Finding a way to ensure the high-frequency clock is not running when you are idling is the most important thing to do when you are trying to reduce the power consumption of an nRF5 based device.

    1. PWM source:

    The PWM hardware in the nRF52 is present to offer high-frequency (up to MHz range) PWM in a way that does not occupy the CPU constantly. It requires the HFCLK to be running and the peripheral itself also uses quite a bit of current. It is not the power efficient way to get a low-frequency signal like what you need for an LED.

    The nRF5 series include Programmable peripheral interconnect (PPI) which can be configured to enable peripherals to interact with each other without interrupting the CPU. For a power-optimized PWM you should use PPI to get the two repeating events from the RTC causing the GPIO pin to toggle between high and low.

    Note, that this is not what is done in the low power PWM example. The example is interrupt driven, which uses a bit more power than PPI would. The low power PWM example is much lower power than using the high-frequency clock and PWM peripheral, but using PPI you can get even better results. How much of a difference there is between PPI and interrupt depends on the frequency, and for lower frequencies, the difference can be very low.

    2. Time keeping source

    There are two peripherals that can be used to measure time. The TIMER is for the high-speed clock. The RTC is a much simpler peripheral with less configuration options, but it uses the low-frequency clock. As mentioned in the beginning of the post, avoiding the use of the high-frequency clock in sleep is the holy grail of power efficient firmware on the nRF5 series devices, so you should use the RTC.

    If your RTC expires often enough that the interrupts are using enough power to be noticeable, you should consider if the PPI could be used instead. Using PPI you can use the counter and COMPARE events to set up autonomous events to like GPIOTE and many other peripherals. You often want to use a COMPARE event from the RTC to CLEAR the RTC COUNTER. This gives you a recurring event.

    Best regards,
    Rune Holmgren

Children
No Data
Related
Terms of service