Closed 4levity closed 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.
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.
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.
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.
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.