Open dsvensson opened 6 years ago
I think that output is actually from WiringPi: https://raspberrypi.stackexchange.com/questions/66873/how-to-read-output-of-gpio-readall and not anything generated by this crate or gpio-utils (which uses this).
@posborne correct, but as the subject says, it gives me little help to interpret the documentation:
https://docs.rs/sysfs_gpio/0.5.3/sysfs_gpio/struct.Pin.html#method.new
So lets say I have CS connected to physical pin 24 on my Raspberry Pi pin header, I expect the relevant part of the above gpio readall
output is:
24 | 1 | OUT | CE0 | 10 | 8 |
...but should I use 24
, 10
or 8
as an argument to Pin::new()
?
So I was hoping the documentation could be clarified a bit to avoid questions like this.
Ah, I see, unfortunately the answer is a bit tricky and this is part of the reason for the sysfs interface to GPIOs and global numbering that goes along with it being deprecated moving forward. I explain the situation a bit more in the documentation for an as-of-yet unreleased crate that will use the character device interface: https://github.com/posborne/rust-gpio-cdev/blob/first-pass/README.md#getting-access-to-a-gpio
For the case of the raspberry pi and most SOCs (and it will vary based on model a bit) we are looking the magic number will be calculated as something like the following:
magic_pinno = (gpio_bank_no - 1) * bank_size + pin_number_within_bank
On the IMX6, for instance, the BGA pin muxed as GPIO2_5 would be GPIO 37 (as each bank has 32 pins that could be muxed in.
For the raspberry pi (which uses a BCM chip), the builtin GPIO controller has a single bank and the pin number is what the output refers to as the "BCM" number (8). This matches with the example toml configuration file for another tool I wrote called gpio-utils: https://github.com/rust-embedded/gpio-utils/blob/master/examples/raspberrypi.toml#L73
The other thing to watch out for is the SPI driver in the kernel being setup to use the chip-select line directly; in this case I think the pin should fail to export but it depends on how things are implemented in the kernel (whether it is muxing it as a chip select for the peripheral or muxing as a GPIO and allowing the driver to claim the GPIO in the kernel for use as a chip select by the driver).
Not really blaming this crate, but elaborating on pin numbering might be useful to the documentation reader.
I connected physical pin 24 on my Raspberry Pi 3, and now in hindsight, I think that pin really should be accessed via Pin 8, still not sure as SPI CS doesn't work as expected.
Output of
gpio readall
:So a clarification on what the Pin number refers to would be nice.