GPIOTE IN[n] register description

[Phil]

What exactly are the GPIOTE IN[n] registers?

Is the IN[n] register a function pointer of a function to call when the the input condition occurs on the associated pin?  If so, does this function interrupt the current program execution?

Is it the interrupt handler when a GPIOTE interrupt occurs?

The nRF51 Reference Manual Ch15 GPIOTE Tasks and Events makes no mention exactly what IN[n] is.  It is a 32-bit register, with no register description.  The GPIOTE general description says an event is generated when a rising edge, falling edge or change occurs on a pin associated with a GPIOTE channel.  What exactly is an event?

[Håkon Alseth]

Hi,

 

What exactly are the GPIOTE IN[n] registers?

This is an event, which can be read with NRF_GPIOTE->EVENTS_IN[n]. I would recommend looking at chapter 10.1.4 in the nRF51 Ref. Manual for generic information about events and tasks. 

Is the IN[n] register a function pointer of a function to call when the the input condition occurs on the associated pin?  If so, does this function interrupt the current program execution?

 The value of the register would be either 0 or 1. The interrupt vector for the GPIOTE should then check all GPIOTE events that can occur, clear and run the code accordingly. 

Is it the interrupt handler when a GPIOTE interrupt occurs?

If INTENSET is enabled for the given event, and you have enabled the GPIOTE_IRQHandler in NVIC, yes. If you're using any helper-libraries or drivers for gpiote, then they handle this for you.

 

The GPIOTE general description says an event is generated when a rising edge, falling edge or change occurs on a pin associated with a GPIOTE channel.  What exactly is an event?

The IN channel can be configured as per the CONFIG register, and when that condition occurs, an event is signaled from the hardware peripheral to the CPU core, and if the IRQ is enabled; the CPU fires up that interrupt vector and executes it.

 

Kind regards,

Håkon

[Phil]

Thanks Hakon for your excellent reply.  This makes a lot of sense.    

I had managed to get an event to occur and print something out the UART when a pin changed, but was mystified how it does it.  I used the nrf_drv_gpiote driver functions in the SDK.  I'm trying to start from an SDK example and modify it for our application.  So understanding how things actually work is very useful.

In the meantime I had traced through the code for the nrf gpiote driver and saw that the event handler function pointer ends up in an array of function pointers in a gpiote_control_block_t structure, not in the IN[n] register.  So there was a clue!

I found the level of abstraction in the GPIOTE driver documentation so high that I couldn't understand at all what it was doing.  Therefore I had a look at the nRF51 hardware reference manual and came up against a brick wall.  Your answer has clarified everything.

I would suggest a couple of things in the nRF51 Reference Manual:

1. In CH15 CPIO Task and Events there should be register descriptions for the IN[n] and OUT[n] registers

2. CH15 should include a reference to CH10 and in particular to 10.1.3, and 10.1.4.

Thanks for your help.  Now I won't be posting my other question: "What exactly are the GPIOTE OUT[n] registers?"

[Håkon Alseth]

Hi,

 

Thanks for the feedback, I'll make sure that this is reported back to our technical writers.

The nRF5-series in general share similar peripherals, such as GPIOTE, so it could be beneficial to look at nRF52-series docs for it as well:

https://infocenter.nordicsemi.com/topic/ps_nrf52840/gpiote.html?cp=4_0_0_5_9

Kind regards,

Håkon

[Phil]

Thanks Hakon,

I'm also looking at nRF52 docs as we have replaced the nRF51822 with nRF52832 in one of our products.

What you said also helped me understand tasks and event in the UART.  It's really quite straightforward.  In the UART tasks are equivalent to configuration register bits in other microprocessors, and events are equivalent to status register flags. I come from a background in PIC24 and STM32, so these task and events threw me initially.

It would have been great if Nordic had implemented peripherals the same as STMicro in the STM32 Cortex M3/M4.  I guess it's a bit late for that!

Thanks for your help

[CheMax]

I do not think that the ST approach to the periphery is more correct. Nordic gives you more options. Tasks and Events provide more flexibility since there are no restrictions on their internal switching. Plus they provide significantly lower consumption, since the core can sleep at the same time.

IMHO, this decision is the future.