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

Using two GPIOTE config to a single pin

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?

Parents
  • 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.

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

Children
No Data
Related