nrfx_rtc_init vs drv_rtc_init?

[charles]

nRF52840, SDK16.0.0, S140v7.0.1

We use SoftDevice (RTC0) and app_timer (RTC1). I'm trying to configure RTC2 and TIMER0 to do PPI-driven crystal timing as described in https://devzone.nordicsemi.com/f/nordic-q-a/64834/softdevice-and-timer3.

Since we use app_timer, I was curious how much RTC initialization I'm required to perform additionally to get RTC2 up and running via "nrfx_rtc.h". I'm looking at this file and seeing functions like nrfx_rtc_init, which lives in "nrfx_rtc.c" and looks like what I want. Then I look in the app_timer2.c file and see that it's calling something totally different: drv_rtc_init() which lives in "drv_rtc.c"

Two separate modules whose names both indicate that they want to control the RTC blocks. Which one should I use for manual RTC2 capture/compare PPI work? If they both ended up calling the same .c file I wouldn't really care but drv_rtc_init and nrfx_rtc_init look similar but have nontrivial differences. Which should I use and why? The docs I see seem to steer me towards nrfx whenever possible, but then I see that app_timer2 does something different?

[snoopy20]

Perhaps the answer is neither? Why not configure them directly using the documentation? (I'm against much of the unnecessary abstraction).

[haakonsh]

The NRFX module vs legacy drivers concept is a bit confusing. Often the NRFX module is just a wrapper around the legacy drivers, but in more and more cases the NRFX module's drivers are full driver replacements with improved features. 
The goal of NRFX is to be a low-level HW interface for any RTOS. It has a lot of safety features that are useful for an RTOS, that you might find excessive in small projects. I recommend that you always use the NRFX API unless you really need to optimize the code-size. 

The TIMER peripheral is very easy to use through the HAL, so is SPI, PPI, RTC, EGU, I2S, LPCOMP, QDEC, and GPIOTE.
Other peripherals have a drivers that interface with their respective peripheral in the correct way, one that is often hard to interpret from the prod spec alone. Some peripheral has quirks that lead to a higher current consumption if used incorrectly, the drivers ensure that they will be used correctly.

[charles]

Thanks for the response. I don't think it directly answers my question, though, could I ask for some clarification?

Specifically, I want to use PPI to get RTC2 compare events to trigger start and capture tasks on TIMER0. We're already using app_timer2 for application-level firmware timers.

What drivers should I use to accomplish this work?

[haakonsh]

Use the PPI allocator, Timer driver, and RTC driver. 

The PPI or TIMER peripheral examples should clarify how you connect an Event to a Task. Note that you can fork any PPI channel to trigger one more Task. 

[charles]

Thanks for the clarity. I'll use the nrfx drivers you posted above and assume no interactions between those and whatever code lives in "drv_rtc.c" (used by app_timer2).

[haakonsh]

As long as you use a separate RTC instance (app_timer defaults to RTC1 I think) the app_timer2 will have no interaction with your drivers(unique IRQs and control blocks for each instance).