4

I need fast (>10 Khz) userland access to the GPIO pins.

Are there any options available? /sys/class/gpio based GPIO is too slow (I've tested it), and having to have your application run as root is violently stupid. I've looked at pigpio, but that has at minimum a client running as root (and then you get all the latency of having a socket connection)

It seems like there should be a ioctl-like interface to the GPIO. Is anyone working on such a thing? (it'll almost certainly be a kernel module of some sort).

Fake Name
  • 141
  • 2

1 Answers1

2

You can easily get up to 22kHz (I can't remember the source) using the Broadcom C library, in the benchmark results I looked at it was easily the fastest.

Also, in my opinion applications which access GPIO are even more suited to needing root permissions than others, since GPIO can access physical devices rather then just data on a drive.

  • The entire extant linux driver system seems to disagree with your belief of needing root permissions. I agree root should be required to grant permission to access the GPIO, but that permission should be persistent from then on. This is how the SPI interface works. – Fake Name Sep 23 '13 at 01:29
  • I see your point, but I think the main difference is when you interface to a piece of commercial hardware, you know exactly what it is and the expected outcomes of performing certain actions, whereas you could connect almost anything to a GPIO interface. –  Sep 23 '13 at 07:18
  • With fine-grained ACLs (probably on a per-pin basis), setting the permissions for the GPIO should be a root-only privilege, but the actual use of the GPIO absolutely must be from a userspace process. Anything else is a terrible idea. – Fake Name Sep 23 '13 at 07:51
  • Also, I don't see why you seem to be assuming that it's not possible that commercial hardware could in fact be connected to the GPIO? – Fake Name Sep 23 '13 at 07:52
  • I suppose if a suitable ACL was implemented then this would be a much better solution. What I mean by commercial hardware was hardware which has it's own libraries/drivers. –  Sep 23 '13 at 22:24