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]

Einar Thorsrud said:

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

I would argue that given the frequency of the RTC it shouldn't measure anything less than one period of its clock source. This nop implementation indicates that you should pick a time source for the app timer with more granularity if you anticipate that people will need it for that. 

"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."

 I don't want the pre-processor to help me this, and I am using the TIMER peripheral for one 5us time period with a 16 MHz source (pretty reasonable). The problem is if the RTC has a time period less than its actual period those nop instructions block the processor and the interrupt is missed, so the next interrupt isn't until the timer count has rolled over again ~4.5 minutes later. I don't see how this nop implementation is acceptable at all. Use a faster clock if you need more time granularity. Don't do this. 

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.

A better solution would be to use a fast clock source for your app timer, or to only use the app_timer for periods of time greater than or equal to the period of your RTC. I am NOT using the app_timer outside of what it has been designed for. The app_timer is used in almost every bluetooth example in the stack.

[Einar Thorsrud]

Hi,

I understand that this is a problem in your specific use case. But using a TIMER (which is the only other alternative) in the app_timer library is not an option and will not be a good design choice for this module.

If this is a blocker for you, then you would have to either modify the app timer (to use the TIMER to wait instead of busy waiting), or avoid using the app_timer altogether. Without knowing the details of your design I suspect the latter would make more sense.

[nothingmuchyou]

I guess I'm still surprised that this implementation is allowed but thanks for your response.