This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Hi,

I'm porting code from Simblee/Arduino to Laird's BL651/Nordic SDK (nRF52810, SDK 15.3, S112). (Simblee discontinued.) For accurate timing of a GPIO pin, I use TIMER1, TIMER2, GPIOTE and PPI. GPIOTE watches an input pin for transition LOTOHI and HITOLO. PPI is used to start TIMER2 (timer mode) on input pin transition LOTOHI, then stop TIMER2 on transition HITOLO. PPI is also used to increment (COUNT) TIMER1 (counter mode) each time TIMER2 overflows. GPIOTE triggers interrupt call on input pin transition LOTOHI where code captures TIMER1 and TIMER2 values and calculates time between LOTOHI and HITOLO transitions of input pin and sends to BLE Central.

Here's the current code that works well on Simblee:

As you can see, I access all peripherals directly rather than using TIMER, GPIOTE and PPI drivers. I read somewhere that it's better to use the peripheral drivers rather than direct manipulation (this is understandable). So I did so in porting to Nordic SDK (15.3 with SoftDevice S112. However, I've discovered that you cannot use the GPIOTE driver (routines like nrfx_gpiote_init(), etc.) to watch for more than one event per pin. I cannot use it to watch for both LoToHi and HiToLo. I could use toggle (NRF_GPIOTE_POLARITY_TOGGLE polarity), but would need to check transition in the interrupt routine to know which transition triggered the interrupt.

My questions are:

1) Is it critical to use the peripheral drivers rather than accessing peripherals directly?

2) Given the above limitation in GPIOTE, is it okay to manipulate GPIOTE directly?

The code that is working (using nRF52 dev kit) is below, but manipulates GPIOTE directly:


Thanks for any help!

Tim

Parents
  • 1) Is it critical to use the peripheral drivers rather than accessing peripherals directly?

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

     

    2) Given the above limitation in GPIOTE, is it okay to manipulate GPIOTE directly?

     Yes, I believe that should be okay.

  • 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

Reply
  • 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

Children
  • Tim said:
    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.

    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.

  • 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