alternative implementation of nrf_delay

[Allen]

Hello,

Would it be possible to use nrf_pwr_mgmt_run() to implement a polled wait function? The nrf_delay functions execute a busy wait which is only feasible for very short periods. Is there an issue calling this as a general function?

Example delay for condition;

do { nrf_pwr_mgmt_run(); } while (! condition_met);

The documentation says that this should be called from main(). I don't see why it couldn't be used in a more general manor.

Thanks

[ovrebekk]

Hi

This function is not reentrant, which is why you should only call it in the main loop. 

You might end up with one such delay loop being interrupted by another, and then your delay times will probably be incorrect. 

I would suggest you look into the app_timer module instead if you need more power efficient delays. Then you can schedule a function to be called some time in the future, and go to sleep in the mean time. 

You can schedule multiple app_timer instances in parallel, so it gives you a lot more flexibility. 

Best regards
Torbjørn

[Allen]

The intention is to wait for a condition, not implement an accurate delay. We use app_timer extensively in our application. The issue is that this needs to be a blocking call implementation which still allows the rest of the system to run.

[ovrebekk]

Hi

Sorry for the slow response, I have been out of office for a while. 

Wouldn't it be better to use a state machine for this, rather than a blocking call?

A common design pattern in embedded applications is to check for any event/condition in the main loop, and then call the sleep function once after all the events/conditions have been tested:

while(1)
{
  if(condition_met)
  {
    ...
  }

  if(other_condition_met)
  {
    ...
  }

  nrf_pwr_mgmt_run();
}

The only difference would be that you have to add the code after the blocking call into the if(condition_met){..} clause. If you have multiple blocking calls in sequence you would need multiple states, rather than a single bool flag. 

Or you could use an RTOS I guess, which would allow you to run blocking calls in a thread without blocking the other threads. 

Best regards
Torbjørn

 

[Allen]

Yes, everything would be easier if we were using an RTOS and the solution didn't need to fit into an existing design/code base.

Do you think protothreads could provide a solution which would not require major modifications?

[ovrebekk]

Hi 

The Protothreads library sounds good on paper, but we haven't integrated it with our SDK, and I don't know much work it would be for you to port it over. 

If they already have examples that run on the Cortex M4 then you have a place to start, but I would expect it to be more work to make it work reliably on the nRF52 than to change the structure of your blocking code to use a state machine instead. 

Best regards
Torbjørn