Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better GPIO Performance #6

Open
dmcg opened this issue Jul 8, 2012 · 3 comments
Open

Better GPIO Performance #6

dmcg opened this issue Jul 8, 2012 · 3 comments

Comments

@dmcg
Copy link

dmcg commented Jul 8, 2012

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.

@gnarlie
Copy link
Contributor

gnarlie commented Aug 17, 2012

The latest library will keep the file handle open. I'm seeing a 4x-6x improvement in speed.

@gnarlie gnarlie closed this as completed Aug 17, 2012
@RandomDude4
Copy link

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
Copy link
Contributor

npryce commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants