GPIO Access through /sys/class/gpio

[frederik]

Hi

I'm trying to use the Linux /sys/class/gpio interface described in the Red Pitaya Github repository. I can successfully export GPIO 907, 908, 909 and so on. Changing the direction works as well (e.g., "echo out > /sys/class/gpio/gpio908/direction"). Changing the value, however, does not work. When I write

Code: Select all

echo 1 > /sys/class/gpio/gpio908/value

and then

Code: Select all

cat /sys/class/gpio/gpio908/value

it returns 0 as if nothing has happened. What gives?

I know of the hacky way of accessing the GPIOs via the redpitaya C library which works. However, I'd like to use the standard Linux interface for GPIO access since it makes my code more portable. Ideally, I'd also like to access the GPIOs in a Linux kernel module via gpio_request, gpio_direction_output, etc. How can that be achieved? Currently, I'm writing directly to a memory address (found in housekeeping.h) but that is not portable at all.

Thanks in advance!

~Frederik

[Nils Roos]

[...] What gives?

The only external IOs that are connected to the GPIO controller are MIO[0]=gpio906=LED8, MIO[7]=gpio913=LED9 and MIO[49]=gpio955=??? .
All of the other dedicated IO pins are assigned to on-chip peripherals, for example MIO[1..6]=gpio907..912 are the QSPI flash interface. When an IO is assigned to a peripheral, it is disconnected from the GPIO controller. You can tell the controller to do something with the pin, like you did, but it won't be able to comply.

I know of the hacky way of accessing the GPIOs via the redpitaya C library which works. However, I'd like to use the standard Linux interface for GPIO access [...] How can that be achieved? Currently, I'm writing directly to a memory address (found in housekeeping.h) but that is not portable at all.

The GPIOs on the expansion connector are not connected to any resource known to the kernel, and neither are LED0..7. There are basically two ways you can work around that:

A
Write a kernel driver which exports the gpio_... interface and uses the housekeeping registers internally. Then register this driver in the device tree in addition to the driver for the standard GPIO controller.

B
Activate "GPIO EMIO" in the ZYNQ IP configuration, then route the new GPIO bus to the red_pitaya_top module and connect it to the IOBUFs driving the expansion GPIO pins. Assuming you use the bus signals GPIO[0..15] for the pins, you would then be able to address the pins as gpio960..975 in /sys/class/gpio/ .

Cheers
Nils

[frederik]

Thanks for the quick and informative response, Nils!

The only external IOs that are connected to the GPIO controller are MIO[0]=gpio906=LED8, MIO[7]=gpio913=LED9 and MIO[49]=gpio955=??? .
All of the other dedicated IO pins are assigned to on-chip peripherals, for example MIO[1..6]=gpio907..912 are the QSPI flash interface. When an IO is assigned to a peripheral, it is disconnected from the GPIO controller. You can tell the controller to do something with the pin, like you did, but it won't be able to comply.

Ah, that makes sense. I just assumed that the pins found in the expansion connectors were connected to a resource known by the kernel. I was mistaken.

I will use solution A for now since I already have most of the code in place for something like that.

Cheers!

~Frederik