Using two GPIOTE config to a single pin

RE: Using two GPIOTE config to a single pin

RK — Fri, 05 Feb 2016 04:27:59 GMT

your problems will start when you are using the softdevice and interrupts get delayed and you miss a flip. This is why I use the same pin in GPIOTE events and hold my nose, it works ok. You can try doing it with a GPIOTE pin toggle event and lots of PPIs, but you soon run out of PPIs, and sanity. You end up with PPIs triggering tasks and other PPIs disabling and re-enabling the first PPIs.

I just changed my board so that the next version will send the same signal to two different pins so I can follow the manual, just to be sure.

And no you don't have to clear the interrupt, the Cortex does that for you, you have to clear the EVENT else that will continue to assert the interrupt which will re-set as soon as the Cortext clears it and put you back there again. GPIOTE->EVENTS_IN[0]=0 before you leave the handler.

RE: Using two GPIOTE config to a single pin

RK — Fri, 05 Feb 2016 04:19:16 GMT

The event is whatever is configured in CONFIG[0]'s bitmask, which includes whether the GPIOTE is set for TASK or EVENT, you want EVENT, what the pin is, what the transition is (that's a bitmask) and OUTINIT which you don't care about, because that's for TASKS.

When the given transition occurs on the given pin, that EVENT triggers. At that point the model is the same for any other EVENT in the system, eg CLOCK has an HFCLKSTARTED event, in this case you have an array of IN events. So GPIOTE->EVENTS_IN[0] == 1 and if you have the interrupt set to fire, it will fire. You have to clear that EVENTS_IN[0] back to 0 before you exit the interrupt handler, or it will fire again.

RE: Using two GPIOTE config to a single pin

osenjw — Fri, 05 Feb 2016 04:17:48 GMT

I was going to try to flip in the interrupt. If I have a clean signal no problem. But I have the same concern as you, what happens with noise or a true interrupt that is missed? And thanks for clearing my issues with pin vs signal.

I have another question on interrupts. I am used to interrupts that when you end up in the ISR, you need to clear the interrupt flag - or else a subsequent interrupt is not going to happen. Often this is done by just reading the interrupt status register. But with the M0 you actually have to write to the clear interrupt register. Am I reading the RM correctly?

RE: Using two GPIOTE config to a single pin

osenjw — Fri, 05 Feb 2016 04:11:55 GMT

Thanks for nudging me towards understanding. I am reading the RM on GPIOTE. The RM is defining the IN[] registers as' IN[0] 0x100 Event generated from pin specified in CONFIG[0].PSEL'.

What is the 'event'? Is it an enumerated value such as LowToHigh or HighToLow? When I end up in the interrupt what should be in the IN[] location?

RE: Using two GPIOTE config to a single pin

RK — Thu, 04 Feb 2016 23:59:21 GMT

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.

RE: Using two GPIOTE config to a single pin

RK — Thu, 04 Feb 2016 23:54:27 GMT

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,

RE: Using two GPIOTE config to a single pin

osenjw — Thu, 04 Feb 2016 18:21:59 GMT

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.

RE: Using two GPIOTE config to a single pin

Susheel Nuguru — Thu, 04 Feb 2016 08:26:03 GMT

+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)

RE: Using two GPIOTE config to a single pin

RK — Thu, 04 Feb 2016 06:59:50 GMT

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.