Just FYI, I've been tinkering with RPi.GPIO for speed improvements - at least for output - and have managed about a 10x improvement on the standard setup by simply holding the files open for multiple writes, instead of opening/closing them for each write (you need to .flush() of course). There's another thread on this forum about GPIO speed where I've posted a link to a quick class that handles this. The RPi.GPIO author is also working on improvements by trying to directly control the registers instead of going through files, but that's longer term work.gadgetoid wrote:I'd often assumed /sys/class/gpio to be slow, which is why I haven't explored it in any depth. I get stupendous performance out of the shared-memory mode in C, but obviously using it in Ruby incurs a penalty.
So, whilst shared memory may be faster, it may not necessarily make a difference if the bottleneck is your interpreted language.
I'm not too bothered about running things as root, most of what I do will be inconsequential GPIO tinkering, but I understand why some are.
The ultimate goal is to have both methods available for the user to choose at their discretion depending on whether they favour speed or security.
If anyone wants to benchmark RPi.GPIO and wiringpi in Python, I'd be very interested to see the results.
That's a clever and logical approach. How particular is the speed improvement to your use-case?MadCow42 wrote: Just FYI, I've been tinkering with RPi.GPIO for speed improvements - at least for output - and have managed about a 10x improvement on the standard setup by simply holding the files open for multiple writes, instead of opening/closing them for each write (you need to .flush() of course).
As far as I understand it, the problem with direct control is that the system wont allow it until we get ( and I might be talking nonsense here!) a driver in the kernel which exposes these things to userspace somehow. Once that happens, it'd be pretty trivial to make use of it and gain what would, hopefully, be the best of both worlds.MadCow42 wrote: There's another thread on this forum about GPIO speed where I've posted a link to a quick class that handles this. The RPi.GPIO author is also working on improvements by trying to directly control the registers instead of going through files, but that's longer term work.
It's a pretty general improvement for any high-speed writes. My 10x figure was simply comparing 10000 sequential writes to the same pin (True, False...). I'm using the Pi to drive stepper motors through an 8-bit shift register (about 25 GPIO operations per step... but I'm also changing that approach to reduce it), so I needed faster speed than I was getting with the standard output method.gadgetoid wrote: That's a clever and logical approach. How particular is the speed improvement to your use-case?
I'm just driving LEDs for the moment - the rest of the IC's I need aren't arriving until later this week. But, I should be driving the steppers in real life by next week sometime. I don't need the 50kHz performance that your example achieved for my application, but it would allow me more precise/consistent timing of my stepping, as well as more room for overhead. I'd probably end up writing a wrapper so that I could use either method with the same calls. I'll let you know!gadgetoid wrote:If you ever get the chance to give WiringPython a try in your real-world use case, I'd love to know how it fares. For raw performance it appears better, but it's not a well constructed or particularly friendly class.
gadgetoid wrote:First and foremost, a million and one thanks to Gordon for doing all the hard work and producing WiringPi in the first place. You can learn more about it here: https://projects.drogon.net/raspberry-pi/wiringpi/
Not knowing if anyone had done it before, I decided to wrap up WiringPi for Python. Unfortunately I'm not a Python programmer, and thus am not best positioned for actually testing the result.
More Python literate folks, however, are free to grab WiringPython from GitHub: https://github.com/Gadgetoid/WiringPython
And let me know if anything goes awry!
Currently, as per WiringPi itself, you will need to run your Python script as root and be sure to call wiringpi.wiringPiSetup() before attempting to use the other functions.
You should probably "apt-get install python-dev"texy wrote:Finally got some time to play with wiringpi, but failed at the first hurdle - I cannot install it !
It cannot find Python.h
I have tried a 'find / -name Python.h' .....and it is nowhere to be found on my system
What am I doing wrong, or are the instructions somewhat incomplete (for a newbe) ?
This is not generally true, and WiringPython will ultimately not require root when the latest updates from Gordon are merged in.Hartspoon wrote:But on the eLinux wiki, it's written that any python script willing to control GPIO has to be run as root, and this includes the RPi.CPIO module.
Code: Select all
#!/usr/bin/python # -*- coding: utf-8 -*- import wiringpi import time def main(): wiringpi.wiringPiSetup() wiringpi.pinMode(17, 1) for i in range(5): wiringpi.digitalWrite(17, 0) time.sleep(1) wiringpi.digitalWrite(17, 1) time.sleep(1) if __name__ == "__main__": main()
Code: Select all
def SPI(c): # data = DIN # clock = SCLK # MSB first # value = c for i in xrange(8): wiringpi.digitalWrite(DIN,((c & (1 << (7-i))) > 0)) wiringpi.digitalWrite(SCLK, 1) wiringpi.digitalWrite(SCLK, 0)
Code: Select all
def SPI(c): # data = DIN # clock = SCLK # MSB first # value = c wiringpi.shiftOut(DIN, SCLK, 1, c)
Users browsing this forum: mattg31 and 14 guests