nrf_delay uses NOP() but it's called in app_timer2.c and drv_rtc.c

[nothingmuchyou]

Hi, 

I've read in these forums and seen the machine instructions within the C code that nrf_delay_us (which BTW is used to do nrf_delay_ms) is implemented by executing a series of nop instructions. This is a problem for handling interrupts from other modules promptly, and frankly I'm not really sure why it's so integrated in the library. 

In our project we are using app_timer version 2 which uses drv_rtc.c and nrf_delay module for Bluetooth. We are also using a separate timer and seeing that interrupt get effected by this. While the interrupt is supposed to trigger every 1 us, it actually only triggers every 11 us, I think because of this NOP() delay. 

My question is: What's the best way to get rid of the nop nrf_delay_us implementation? Do I overrride it? 

Thanks for the help

[Einar Thorsrud]

Hi,

It is not possible to do anything sensible with interrupts every 1 us, and certainly not while doing much else. Can you explain in a bit more detail what you intend to do?

Regarding NOP, app_timer use RTC. nrf_delay use busy waiting with NOP. That is OK for simple delays that need to be at least long enough, for instance during startup or similar. But they are blocking, not reliable in the sense that it will take longer time if an interrupt happens in the mean time, and if called in an interrupt, you will block any same or higher priority interrupts. So in short you should as a general rule not use nrf_delay (or other forms of busy waiting) other than in test code and some specific cases where you see that does not cause problems. 

So for the specific problem:

My question is: What's the best way to get rid of the nop nrf_delay_us implementation? Do I overrride it? 

I do not see a reason for replacing thi sin nrf_delay. That is intended to be a simple busy wait function. If you want a different form of wait, you need to use a RTC (like app_timer) or timer, and wait for the interrupt.

[nothingmuchyou]

Einar Thorsrud said:

So in short you should as a general rule not use nrf_delay (or other forms of busy waiting) other than in test code and some specific cases where you see that does not cause problems. 

So if this is the guideline that Nordic is providing then my question is why is drv_rtc.c using nrf_delay? There's no way I can see to avoiding nrf_delay, even if you use the app_timer. 

I want a one-time 5 us delay, not continually using 1us for the entirety of the application, and this should be possible with this processor, but the nop() instructions block the handling of that interrupt because it's integrated into drv_rtc.c and drv_rtc is integrated into app timer. 

Einar Thorsrud said:

Regarding NOP, app_timer use RTC. nrf_delay use busy waiting with NOP. That is OK for simple delays that need to be at least long enough, for instance during startup or similar.

I agree, So why is drv_rtc.c using it in the middle of the application and how do I avoid that?