Using two GPIOTE config to a single pin

[osenjw]

In another thread entitled:

Change in GPIO to start/stop timer and fire interrupt

The following code is used:

  NRF_GPIOTE->CONFIG[0] = (GPIOTE_CONFIG_POLARITY_HiToLo << GPIOTE_CONFIG_POLARITY_Pos)
        | (myPin << GPIOTE_CONFIG_PSEL_Pos) // using GPIO 5 as input
        | (GPIOTE_CONFIG_MODE_Event << GPIOTE_CONFIG_MODE_Pos);

    //// Configure GPIOTE channel 1 as event that occurs when pin 5 changes from digital
    //// low to hi.
    NRF_GPIOTE->CONFIG[1] = (GPIOTE_CONFIG_POLARITY_LoToHi << GPIOTE_CONFIG_POLARITY_Pos)
        | (myPin<< GPIOTE_CONFIG_PSEL_Pos) // using GPIO 5 as input
        | (GPIOTE_CONFIG_MODE_Event << GPIOTE_CONFIG_MODE_Pos);

In the nRF51 RM, there is a statement: Each GPIOTE channel is associated with one physical GPIO pin through the CONFIG.PSEL field...

Is the above code breaking this rule? Are two configurations being mapped to a single pin?

Would the correct code be to look for a change, then check the PIN state in the ISR to determine whether it was HiToLo or LoToHi?

If so, what would be the recommended debounce approach?

[RK]

The above code does break the one-pin-one-GPIOTE rule, however I've done this for events (and only events not tasks) very often and I've never had an issue with it.

The absolute right way to do it would be to map the one input to two different pins and use one gpiote on one pin for the Lo to Hi, and the other Hi to Lo on the other pin.

[Susheel Nuguru]

+1 for RK, It does break the rule, could be some side effects if myPin is toggling close to system clock frequency. But at lower frequencies on myPin (<4MhZ) this would work (not recommended though)

[osenjw]

I am confused by terminology. I have a physical connection to what I call a pin. I want an interrupt on both rising and falling events. I do not have the option of connecting two physical pins to a single signal line. I am also new to the M0 architecture. Is an input a logical concept inside the M0? What is the difference between an input and a pin? I think of pin and input as synonyms. If you could point me to the correct section of the RM, I would appreciate it.

[RK]

None of this is Cortex-M0-specific. By 'input' I meant the signal you are trying to measure transitions on, the actual signal line. Pin means the logical number of input/output connection on the chip, eg P0.23, which of course then confusingly maps to a physical pin on the device.

The spec-compliant way to do it is to have the input signal route to two separate pins and have the GPIOTE monitor one pin for up transitions and one for down transitions. GPIOTE has two modes, in TASK mode it controls a pin output, it's pretty clear you can't have two GPIOTEs driving a pin, in EVENT mode it monitors a pin, it seems reasonable that two GPIOTEs could monitor events on the same pin and empirically that works, but does violate the letter of the documentation. So your options are to find a way to send the same signal to separate pins, to use the fact EVENT mode seems to work,

[RK]

but technically violates the one-pin-one-GPIOTE rule which does not, in the documentation, have an exception for EVENTs vs TASKS or you can use one GPIOTE and keep flipping it from up to down transitions, although you're almost bound to run into issues where you don't get through the interrupt handler in time to flip it and miss a transition, worse if some of your signals tend to bounce at the edge as some of mine do.