Trying to define 2 interrupt handlers for the same pin, one for up one for down

[ziv123]

Hi

I am working with nrf52832 NORDIC soc with Segger with nrf52 sdk 16

 

I have looked at the "pin_change_int_pca_10040" example and tried to play with it a little bit

1. If I change the "GPIOTE_CONFIG_IN_SENSE_TOGGLE(bool)" from 'true' to 'false' I see no difference in performance so what is the value of that bool ?

 

2. I want to configure a pin interrupt that calls for one ISR when its change to up and call for another ISR (interrupt service routine) when it changes back down (or to previous original state), off course the calls should occur only on pin change. I have tried to define another 'nrf_drv_gpiote_in_config_t in_config' and define the first for 'high to low' and the other for 'low to high' and then call 'nrf_drv_gpiote_in_init()' again with a different handler but it does not compile because of redefinition of 'out_config' so I guess there is another way to do that

 

3. I am still new to Nordic terminology, I have read a little bit of the data sheet on GPIOTE and GPIO and if I can create a hardware interrupt both on GPIO, I am not sure what is the main difference between the GPIO and GPIOTE and what the Task and Event refers to .. is it a ppi configured handlers (ISR) or .. what does it mean ? why or when to use GPIO and when to use GPIOTE ?

[ziv123]

well i have found that i can use "nrf_gpio_pin_read()" on the pin in the pin in handler, but i wonder if that is the only or the best way to achive that 

i have tried to change the action parameter of the handler and it seems it will not change after init so it is not clear why it is passed to the handler function in the example

[Dmitry]

Hi,

1) There are two modes how GPIOTE can work: using PIN or PORT events. PIN events can be set individually for up to 8 pins to monitor rising/falling/both edges, the response is very fast, but it has a disadvantage - relatively high power consumption because it requires high-frequency clock to remain active.
PORT event is set for the whole port and can be configured only to monitor high or low pin state (though logic similar to PIN event is emulated in gpiote library), the response is slower, but power consumption is very low, and it can be used to wake up device from power-down mode.
The bool value you've asked about chooses mode - true for PIN event, false for PORT event.

2) You cannot set two interrupt handlers for pin change event, but gpiote driver passes pin state to your handler - there's no need to have two different handlers.

3) GPIO works like in any other microcontroller - you can read and control pin state, direction, pullup/pulldown by software. GPIOTE is mainly intended to interact with other peripheral modules through events and tasks - a very powerful mechanism. You can read about tasks, events and PPI here, here and here.

[mtsunstrum]

I am not so sure nrfx_gpiote is doing exactly what we think it should be doing ...

I am working thru some issues now ... so not 100% sure on all of this.

But here is my findings: SDK 16.0.0

For @ziv123 question, possibly one might expect you can code it as follows:

---

// Set up to use more accurate PIN events, not PORT events ...
//     Detect both rising/falling edges ...
nrfx_gpiote_in_config_t signal_intr_config = NRFX_GPIOTE_CONFIG_IN_SENSE_TOGGLE(true);

// Set up Pin 22 as a GPIOTE input, with interrupt handler ...
//   ... understand we cannot have separate isr for rising / falling edge ... OK
err_code = nrfx_gpiote_in_init(22, &signal_intr_config, isr_my_input_signal_handler);
APP_ERROR_CHECK(err_code);

// Set Pin 22 to generate event when it goes from Lo to Hi level
nrf_gpiote_event_configure(0, 22, NRF_GPIOTE_POLARITY_LOTOHI);

// Set Pin 22 to generate event when it goes from Hi to Lo level
nrf_gpiote_event_configure(1, 22, NRF_GPIOTE_POLARITY_HITOLO);

// Enable GPIOTE Pin 22 to generate event(s), enable interrupts.
nrfx_gpiote_in_event_enable(22, true);

---

Answering his question, we cannot have seperate ISRs ... but other issues seem unexpected:

With above code, I appear to see following concerns:

• GPIOTE seems to be configured in PORT events, not PIN events (high accuracy)
• Event 1 for NRF_GPIOTE_POLARITY_HITOLO is not enabled ... ie. not set into Event mode
• Seems we cannot have 2 events configured for same pin time
• Appears to be a limitation of code implemented in nrfx_gpiote_in_event_enable()
• On call into isr_my_input_signal_handler(), 'action' parameter appears to only return 'action' value of toggle
• ... does NOT appear to return the actual hi/lo or lo/hi transition.
• Would not want to read the GPIO pin, because pin state could be lost by that time.

---

Trying to work around these issues right now ... not sure if others are seeing the same.