app_gpiote.c doesn't include NRF_GPIOTE->EVENTS_IN's

RE: app_gpiote.c doesn't include NRF_GPIOTE->EVENTS_IN's

RK — Thu, 11 Jun 2015 01:07:05 GMT

I would say that 'proper way', if you're using the gpiote module for one thing, is to use it for your other code too, I see an app_gpiote_input_event_handler_register() function which may do what you want.

I see now the uart module uses the gpiote for low power mode. That's frustrating.

RE: app_gpiote.c doesn't include NRF_GPIOTE->EVENTS_IN's

Paul — Thu, 11 Jun 2015 00:43:10 GMT

Yes, this is what I have done. rename and rewrite some code. I was looking for a "proper" way to avoid breaking away from SDK's updates. The reason for the gpiote used for UART is for CTS RTS signal.

RE: app_gpiote.c doesn't include NRF_GPIOTE->EVENTS_IN's

RK — Thu, 11 Jun 2015 00:35:56 GMT

Not trivially. There's one handler for each IRQ, that's it, it's in the interrupt vector table.

So if you want to send some types of interrupt one way and some types another way then you need to

rename the SDK's GPIOTE handler to something different, say SDK_GPIOTE_IRQHandler and make it public so you can call it
rename your GPIOTE handler to something different and make that public as well
Write one new GPIOTE_IRQHandler which checks the events which are set and calls one or the other or both of the handlers

You could just do 1) above and write the code to send events into your current handler, same effect, but breaking it out makes it clearer and more maintainable.

However one question is .. why does adding a UART module need the app_gpiote.c to be added at all? I didn't think they were related and see nothing in the Nordic uart code which uses it.

One other option is not to use the GPIOTE directly in your code but rewrite your use of NRG_GPIOTE->EVENTS_IN[] to use the gpiote module if you have to include that anyway for other reasons.