Direct manipulation of peripherals (TIMER, GPIOTE, PPI)?

RE: Direct manipulation of peripherals (TIMER, GPIOTE, PPI)?

Tim — Wed, 16 Oct 2019 23:55:10 GMT

Thank you Hakon. Have run in to some issues integrating this code into a ble_peripheral example. Pulled away at the moment. Will be back to it soon ... Thx. -Tim

RE: Direct manipulation of peripherals (TIMER, GPIOTE, PPI)?

Hakon — Tue, 15 Oct 2019 09:16:27 GMT

[quote user="Tim123"]A related question (being new to Nordic SDK). My understanding is there are legacy drivers with prefix "nrf_dvr_.." and current(?) drivers with prefix "nrfx_...". I presume I should be using the current "nrfx_..." drivers.[/quote]

In the current SDK nrf_drv_ is just a glue layer for nrfx_, so you can use both, but nrfx_ is what you're supposed to use and not nrf_drv.

RE: Direct manipulation of peripherals (TIMER, GPIOTE, PPI)?

Tim — Mon, 14 Oct 2019 20:32:33 GMT

Thank you Hakon. This post recommends using API calls rather than direct access to peripheral registers (at least for PPI).

With SoftDevice (S112) enabled, I presume care is necessary to not use PPI channels reserved for the SD. I see equivalent calls for all nrfx driver PPI API calls in the SD API (e.g. "sd_ppi_channel_assign" for "nrfx_ppi_channel_assign") except for nrfx_ppi_channel_alloc, which I presume is the important SD routine for obtaining an available PPI channel.

The only peripheral I need to access directly, it seems, is GPIOTE. I will do so in order to have two events for a single input pin.

A related question (being new to Nordic SDK). My understanding is there are legacy drivers with prefix "nrf_dvr_.." and current(?) drivers with prefix "nrfx_...". I presume I should be using the current "nrfx_..." drivers.

Many thanks!

-Tim

RE: Direct manipulation of peripherals (TIMER, GPIOTE, PPI)?

Hakon — Mon, 14 Oct 2019 12:52:48 GMT

[quote user=""]1) Is it critical to use the peripheral drivers rather than accessing peripherals directly?[/quote]

No, you can access the registers directly, that should be fine.

[quote user=""]2) Given the above limitation in GPIOTE, is it okay to manipulate GPIOTE directly?[/quote]

Yes, I believe that should be okay.