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

need more control over power management

Hi,

for my application, I want the processor to wake up once every 8 hours, do a 1 second analog measurement, broadcast the results and shut down. When activated by a switch, it should do the same, but then start advertising and be connectable to read and update certain settings.

I think I need a lot more control over the power management then just putting "nrf_pwr_mgmt_run() " in an endless loop, as happens in most examples. Can anyone please point me in the right direction for this, like code snippets or documentation?

thx, Henk

Parents
  • Both of these are interrupt driven events.

    You just set an app_timer for your 8 hour process and the code you want to run is in the handler.

    On the button, you just set up gpiote for sense on your button and then your code goes into its handler.

    Otherwise if the device isn't doing anything it is just calling sd_app_evt_wait(); in main in case it wakes up for other ISR or event activity.

  • Hi,

    thanks for your quick reply. The interrupts I understand, but how do I control the BLE functions? I would like to have a method to start and stop broadcasting, and to start and stop the BLE connectable peripheral functions.

    thx Henk

  • Just extending on Richard's explanation.

    What he means to say is that main loop calling nrf_pwr_mgmt_run will ensure that when system is idling then the loop makes sure that it goes into low power. Any other control should either be interrupt driven (or if SEVONPEND bit is set in ARM registers) then any event in the device peripheral will wake the chip. I am not sure what you mean by "controlling BLE functions" . BLE activities are started (like scanning/advertising and connections) and you do not need to monitor them continuosly. Any BLE activity that needs application processing will wake the chip up and give control to the application through BLE events (which in itself is a interrupt handler)

Reply
  • Just extending on Richard's explanation.

    What he means to say is that main loop calling nrf_pwr_mgmt_run will ensure that when system is idling then the loop makes sure that it goes into low power. Any other control should either be interrupt driven (or if SEVONPEND bit is set in ARM registers) then any event in the device peripheral will wake the chip. I am not sure what you mean by "controlling BLE functions" . BLE activities are started (like scanning/advertising and connections) and you do not need to monitor them continuosly. Any BLE activity that needs application processing will wake the chip up and give control to the application through BLE events (which in itself is a interrupt handler)

Children
Related