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

[nothingmuchyou]

I'd like to clarify my answer so you can see my problem:

nrf_delay is used in the function drv_rtc.c::drv_rtc_windowed_compare_set. The function drv_rtc.c::drv_rtc_windowed_compare_set is used in app_timer2.c's rtc_schedule which is indirectly called from the interrupt handler! This makes nrf_delay transitively a major part of the application because it's being called every time the RTC is interrupted.

Does that illustrate my issue with the driver? Everytime the RTC interrupts a bunch of nop instructions block any other potential interrupts (and the app timer relies on this interrupt)

[Einar Thorsrud]

Hi,

nothingmuchyou said:

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 should have clarified that. The app_timer (wjhich drv_rtc.c is part of is based on the RTC using the 32.768 kHz clock). Given the low frequency of the clock you cannot wait very short times using it (not less than a RTC tick). So the app_timer implementation has a special case for handling when the timeout is 1 tick from now. There is no sensible way to implement this differently in the SDK. You could change this to use a TIMER instead, but that would requier a bit of changes. (And it is not acceptable in the SDK context, as the app_timer should not depend on other peripherals then the RTC, but you are of course free to do it if you want.)

nothingmuchyou said:

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. 

I don't understand how the preprocessor can help you with this. You need some way of keeping track of time. If you don't use CPU cycles (like nrf_delay), then you need to use either the RTC or TIMER.

nothingmuchyou said:

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

There is no other sensible alternative in this case, as the app_timer is intended to be a RTC based low-power low frequency timer implementation.

nothingmuchyou said:

Does that illustrate my issue with the driver? Everytime the RTC interrupts a bunch of nop instructions block any other potential interrupts (and the app timer relies on this interrupt)

I see your point. But I do not see a better general solution. In your specific use case it might be better to sip the app_timer altogether, and use a TIMER (which is 16 MHz) to keep track of time. Then you get the granularity you want and can avoid this. In short, you are using the app_timer outside of what it has been designed for.