I finally got the ISR callback code up and running whereby a ‘C’ thread collects sensor data and periodically kicks the main Python thread to do the motion processing on it, the advantage being the ISR can run in the background regardless of whether the motion processing was also running.
I had a slight hope that this might run faster despite the multiple threads on a single CPU because the ‘sampling’ thread doesn’t use the Python GIL and so should not (b)lock the motion processing. But it seems the threading overhead outweighs this, and the code is marginally slower – 690 samples per second versus 788 samples per second for the single-threaded blocking wait_for_edge() code. I’ll hang onto the ISR code though to see what the four cores of an A2 makes of it when it’s released – hopefully earlier than the end-of-year as is currently the best guess.
Empirical evidence (or wishful thinking?) suggests that the ISR method is less prone to I2C errors so I took both Phoebe and Chloe out for a flight to see if this had any real-world effect. They both flew the same regardless of whether I was using the blocking hardware interrupts or the ISR callback. There is the advantage (as expected) that the standard RPi.GPIO library can be used. My customized version is only necessary for the blocking hardware interrupt support.
I’ll probably stick with the blocking hardware interrupt version for the moment, but if you’d like to try the ISR code then click here to download the zip file.