This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ble_app_hrs_freertos vs ble_app_hrs power consumption

Hi there,

I was comparing the power consumption of ble_app_hrs_freertos and ble_app_hrs examples on nRF52840 DK. The average VDD current is 7.4 mA for the example running FreeRTOS and less than 200 uA for the one without.

Is there a solution for reducing the current consumption when using FreeRTOS? I know that the scheduler is more complex, but still this is very huge difference. Are you considering adding and example with FreeRTOS and NUS, as this looks like quite popular thing that people are doing - for me such an example would be essential.

I know that I could use Zephyr, but as it's written in your documentation, nRF5 SDK is mature and production ready, and the nRF Connect SDK is still developed rapidly and is not ready for production.

Thank you!

Parents
  • current is 7.4 mA for the example running FreeRTOS and less than 200 uA for the one without

    Sounds like the FreeRTOS version is keeping the processor awake all the time - not allowing it to sleep ?

    EDIT

    Presumably, this is the example you're referring to (always good to give a link - so there's no room for doubt):

    https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.0/ble_sdk_app_hrs_freertos.html

    There is a Note about FreeRTOS support, linking to:

    https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.0/freertos.html

    This tells you

    "The port supports tickless idle mode"

    Googling that finds:

    https://www.freertos.org/low-power-tickless-rtos.html

    which says

    "The power saving that can be achieved by this simple method is limited by the necessity to periodically exit and then re-enter the low power state to process tick interrupts. Further, if the frequency of the tick interrupt is too high, the energy and time consumed entering and then exiting a low power state for every tick will outweigh any potential power saving gains for all but the lightest power saving modes"

    So perhaps this is an inherent limitation?

  • Yes, this is the example. I tried the peripheral_uart example from nRF Connect SDK 1.3.0 and the power consumption is 0.7 mA, which I believe is also running Zephyr RTOS. I hope FreeRTOS can be further optimized, but this still has to be investigated.

    EDIT:

    I found 2 solutions for the too high power consumption:

    Solution 1: change #define configUSE_IDLE_HOOK 1 to 0 (in FreeRTOSConfig.h) - average power consumption below 400 uA (the DC measurement of the multimeter varies a lot).

    Solution 2: Add sd_app_evt_wait(); in void vApplicationIdleHook( void ) (in main.c) - average power consumption below 200 uA (the DC measurement of the multimeter varies a lot).

    Is it possible that a Nordic Semi engineer confirms if one of both are legitimize solutions and if yes, which one is better? Thank you!

Reply
  • Yes, this is the example. I tried the peripheral_uart example from nRF Connect SDK 1.3.0 and the power consumption is 0.7 mA, which I believe is also running Zephyr RTOS. I hope FreeRTOS can be further optimized, but this still has to be investigated.

    EDIT:

    I found 2 solutions for the too high power consumption:

    Solution 1: change #define configUSE_IDLE_HOOK 1 to 0 (in FreeRTOSConfig.h) - average power consumption below 400 uA (the DC measurement of the multimeter varies a lot).

    Solution 2: Add sd_app_evt_wait(); in void vApplicationIdleHook( void ) (in main.c) - average power consumption below 200 uA (the DC measurement of the multimeter varies a lot).

    Is it possible that a Nordic Semi engineer confirms if one of both are legitimize solutions and if yes, which one is better? Thank you!

Children
No Data
Related