4

I want to read the status of GPIO35 on a Raspberry Pi 2 Model B using the sysfs on Raspbian with a 4.0.8-v7+ kernel. I can access other GPIO pins using /sys/class/gpio but the two leds are already accessable by /sys/class/leds/led[0,1].

My assumption was that putting led1 (the red led) into trigger mode input the state of the led could be read using the brightness attribute. This value does not seem to change and is always on 0.

When using non-sysfs tools I can access the state of GPIO35 without a problem: raspi-gpio get 35 will change its level value from 1 to 0 when an under-voltage occurs. I hope to use one pattern to access all GPIO's by file monitoring using select or poll and not revert to a different solution for the leds.

The reason why I'm monitoring GPIO35 is to see if there are voltage issue and report those to the end user, advising to change the adapter and/or cable.

  • Would it be better to revert to a generic library?
  • Does led trigger input does what I think it should do?
  • Could I configure led1 not to be a led but a gpio in sysfs?
  • Could raspberrypi/linux github commit be relevant?
1

Updates in the Raspberry Linux kernel used in Raspbian by Phil Elwell make is possible to read-out the value using sysfs'es led class tree.

I will try to cover my own four questions:

Would it be better to revert to a generic library?

Only if you are not satisfied with the options given in sysfs. The raspi-gpio tools prove the data is available for reading. Usually user-land code does not keep itself busy with interrupt handling, so a clean interface is using sysfs and use poll/select. I could research which library uses what solution, but sysfs works fine for me at the momement.

Does led trigger input does what I think it should do?

It probably does. The change that was made in the kernel gives me a good indication this was a natural feature of this trigger type.

Could I configure led1 not to be a led but a gpio in sysfs?

Yes, by disabling or redirecting the led configuration in the device-tree files. I have done so by adding dtparam=pwr_led_gpio=XX, where XX is a unused GPIO pin. This way I could export GPIO 35 in /sys/class/gpio. I could probably construct my own device-tree overlay to completely disable the led interface for GPIO 35 instead of redirecting it.

Could specifig github commit be relevant?

It probably was not.

0

Would it be better to revert to a generic library?

I'm presuming you mean one of the pi-specific libs such as pigpio, libbcm2835, or wiringPi.

I haven't tried but those should all be able to give you access if raspi-gpio can. I believe this is the source for that, and it doesn't use any library or sysfs, but it uses the same mmap() methodology that the libraries do.

So in my opinion, if that's what you need to do that's probably how you should do it. The kernel sysfs interface tends to be more generic and does not possess all of the functionality of the userland libraries.

WRT poll()/select(), I notice the pigpio home page refers to callbacks for "when any of gpios 0-31 change state" but still seems to implement access to 35, I can't speculate on the reason (see joan's comment below). However, you could dig into the mmap() methodology yourself (the raspi-gpio source is only ~600 LOC) and see if there is a way to arrange this specifically.

  • 1
    pigpio samples gpios 0-31 (200,000 times a second by default). The Pi has 54 gpios. gpios 0-31 are read from one memory word, gpios 32-53 from another memory word. The earliest versions of pigpio did read both words so sampled all gpios. However it seemed wasteful as there was no useful information to be gained from gpios 32-53 and none of those gpios were brought off SoC so pigpio was changed just to sample gpios 0-31. pigpio does allow access to all the gpios, but only provides callbacks for gpios 0-31. I'm a bit surprised that select/poll doesn't work on gpio35. – joan Jul 15 '15 at 15:08
  • The reason to use poll/select is to minimize userland resources. Better wait for the data than high frequency polling. So a library that implemented that correctly is my minimum requirement and, of course, also the access to all GPIO's. Its not that select/poll would not work: the gpio is not exportable in the /sys/class/gpio interface. – Joffrey Jul 15 '15 at 15:36
  • I'd guess there's no way out of some kind of userland loop if you can't use a kernel interface (either you do it, or a library does it for you). However, in this particular case you could make the interval very infrequent, on the order of seconds, and still catch the power issue without using any significant amount of CPU time. – goldilocks Jul 15 '15 at 15:40
  • Hi goldilocks, thanks for taking the time to answer, but I put in some more effort and came up with some answers to my own questions. – Joffrey Jul 19 '15 at 20:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.