Blocking GPIO / RPIO rising / falling edge call?

[Hove]

Is there a blocking (rather than callback) GPIO / RPIO edge detection call?

I ask because it may be quicker than my current method: the MPU6050 provides a data ready register, and also a configurable interrupt pin to notify when there's new data available. Currently my code loops reading the data ready register, sleeping for a short while (0.5ms) between reads.

I want to see if I can discard this sleep by just blocking on the interrupt pin instead, but looking at the GPIO & RPIO docs, both only offer callbacks but not a blocking call; I could use the callback method to trigger a fresh sensor read and store it for when it's next needed, but it'd be much simpler and more efficient to simply block in the read sensor code pending the interrupt.

Advice appreciated.

Thanks,

Andy

[croston]

What you want is GPIO.wait_for_edge()

See documentation at:-

http://sourceforge.net/p/raspberry-gpio ... ki/Inputs/

[Hove]

Thanks - great to know GPIO has what I need, but a shame to find out RPIO hasn't - I need to use RPIO for it's hardware PWM (GPIO is software as I understand it). I might try using both as RPIO.PWM is a separate import to RPi.GPIO so may not conflict (he says with many fingers crossed).

Andy

[Hove]

Tried getting the best of both by doing

Code: Select all

import RPIO.PWM as PWM
import RPi.GPIO as RPIO

This meant minimal changes throughout the rest of the code.

I have 2 uses for GPIO - one as an output to trigger a beeper, the other as an input to read / detect rising edge on a GPIO pin connected to the MPU6050 interrupt pin which is configured to trigger when new data is ready.

The fact the beeper continues to work bodes well, but the GPIO.wait_for_edge blocked permanently. Hmm, need more investigation...

[Hove]

OK, some reconfiguration of what triggers and clears MPU6050 interrupts got the GPIO.wait_for_edge() working. Dissappointingly, this reduces the sample rate from > 200 per second (using a hard-polling loop on the data ready register) down to < 100 per second (using the data ready interrupt). Some more investigation for another day - the hardware interrupts only last 50us, so I wonder if GPIO.wait_for_edge() struggles to keep up - dunno, I have no experience at the low-level of coding of the GPIO API.

[Hove]

@croston: a question: I presume GPIO.watch_for_edge() uses epoll() under the covers? What sort of speed would you expect epoll() to detect a rising edge? The reason ask is reading the MPU6050 data ready register in a hard loop (0.5ms sleep per loop) seems to be significantly faster than GPIO.wait_for_edge() which was a big surprise to me.

Of course the other reason could be that the MPU6050 is slower to raise the interrupt pin than it is to fill the data ready register - it's certainly going to have to do it (raising the interrupt) post setting up the corresponding register, but the time difference I'm seeing is several milliseconds which seems very slow.