search

roscopetracula / hindenburgFights

11 stars 1 forks source link

Use interrupt to detect trigger pin #26

Closed 4levity closed 9 years ago

4levity commented 9 years ago

We are able to poll the trigger pin rapidly. However, it's possible that a trigger signal of extremely short duration or a short, "bouncy" activation, would be missed. i.e. interrupt approach might mitigate flaky switch.

roscopetracula commented 9 years ago

It's possible that this was happening when we were testing the other day On Jul 22, 2015 6:03 PM, "C. Ivan Cooper" notifications@github.com wrote:

We are able to poll the trigger pin rapidly. However, it's possible that a trigger signal of extremely short duration or a short, "bouncy" activation, would be missed. i.e. interrupt approach might mitigate flaky switch.

— Reply to this email directly or view it on GitHub https://github.com/roscopetracula/hindenburgFights/issues/26.

jef-pearlman commented 9 years ago

I think you can asynchronously receive transmissions during the main loop, as well, so to avoid race conditions we are currently only setting a few variables in the interrupt stuff and handling the actual device state updates int he main loop. I'm not wedded to this setup, but if you do something similar for the trigger, just make sure transient triggers are not lost by two interrupts (on/off) in rapid succession before the loop runs.

jef-pearlman commented 9 years ago

I just did a test for curiosity's sake. It seems that the loop is currently running ~370 times per second (or ~2.7 ms per loop). I'd be surprised if you saw that fast a cycle on a physical switch on a blimp bounce (barring the switch being busted, a possibility that Ivan mentioned). That said, the interrupt is still a strictly better solution, so I'm all for it.

jef-pearlman commented 9 years ago

Initial implementation in 6d24dc5468f34032ee2d894e6f3cfc4e6e4ea2bc. Note that I used pinWake() rather than attachInterrupt() because 1) rfduino-specific; 2) will double as an actual wake if we start using low power mode; 3) appears to otherwise act the same.

However, I don't have documentation showing #3 so I'm slightly concerned that it might not get triggered sometime. If anyone knows, would love to hear; should be trivial to transition to a different interrupt attachment method.