Repository navigation
Better GPIO Performance #6
Description
Opening /sys/devices/... for every GPIO read and write may be safe, but it's taking about 2ms to change the pin state on my Pi.
http://www.raspberrypi.org/phpBB3/viewtopic.php?t=9977&p=113677 suggests that we can get a 10x improvement (so that would be 200us) by keeping the file open between writes.
Activity
gnarlie commentedon Aug 17, 2012
The latest library will keep the file handle open. I'm seeing a 4x-6x improvement in speed.
RandomDude4 commentedon Dec 22, 2012
I'm using the latest version (today is 2012-12-21) and the GPIO is still very slow, (around 0.5 ms for each pin change) while the "python-rpi.gpio" module found on apt-get does the same operation in around 0.01 ms (more than 10x faster).
npryce commentedon Dec 27, 2012
An explanation of the performance difference between RPi.GPIO and quick2wire.gpio:
RPi.GPIO maps the GPIO device registers into the memory space of the process, which can only be done as root. This increases the attack surface you're driving GPIO from a network service exposed on the Internet. It's also a hassle during development because programming errors can crash the machine or trash your filesystem.
We're designing our API for convenience and security before raw performance. Our API goes through the user-space GPIO API, writing to files in the /sys filesystem. The kernel transition and driver layer takes a lot of time compared to direct writes to the device registers. However, our API can then be used by unprivileged processes that cannot bring down the entire machine.
It's a trade-off. If you're ok about running as root and need raw speed, say in a robotics project or if bit-banging a binary protocol, then RPi.GPIO is a better choice. If you're connecting sensors to the Internet and raw speed is not critical then our API would be a better choice (in my opinion).
We're working on closing the performance gap, safely mapping the device registers into user space without having to run as root. But that's work in progress.