Gpio acitve low and button protocol

[pmelange]

Description

• Adds a new protocol ButtonProtocol and the drivers ManualButtonDriver, ExternalButtonDriver, and DigitalOutputButtonDriver to simulate pushing a button (via GPIO lines). This is needed for the tests I will be doing with the logic behind it.
• Adds a new field to the existing SysfsGPIO / NetworkSysfsGPIO / MatchedSysfsGPIO resource classes to support the active_low option of a GPIO line, used to invert the logical value of an IO line.
• Adds support to GPIODigitalOutputDriver to support ResetProtocol, PowerProtocol, the new ButtonProtocol and implements the new "invert" command for the DigitalOutputProtocol.
• Updates the GPIOSysFSExport to support the active_low attribute
• Adds support the labgrid-client to support the Button actions and the "invert" action for IO.
• Updates corresponding documentation
• Updates the examples for sysfsgpio

As far as new features go...

ButtonProtocol is to be used in my test environment to control pressing the reset button of DUTs. For many of the DUTs, pressing the reset button when powering on provides (via uboot) a TFTP client or server or simply access to a web socket to be able to upload a new firmware image. A logical button is better for the test environment I am creating since it encapsulates the high/low logic levels of IO ports into something logical.

Extending the GPIO based drivers to the Reset, Power, and Button protocols was very straight forward and I did wonder why the Reset and Power protocols had not jet been implemented. They seem like logical extensions to general purpose IO lines.

Adding the active_low attribute was necessary because the IO lines used in the testbed are connected to relays which are active_low.

---

All development and testing was done on a raspberry pi 4 with opto-coupler relays connected to the GPIO lines to control power and reset buttons.

---

Checklist

• Documentation for the feature
• Tests for the feature can be found in the examples/sysfsgpio directory
• The arguments and description in doc/configuration.rst have been updated
• PR has been tested by pulling high and low IO lines using various calls from the DigitalOutput, Reset, Power and Button protocols, both using the exporter/client and as a standalone python script.

[pmelange]

This PR is a reduced version of #1569 without the libgpiod code.

[pmelange]

Rebased to main development branch.

[Emantor]

A few notes:

• The drivers implementing the DigitalOutputProtocol don't need to implement the Poweror ResetProtocol, the repective adapter drivers DigitalOutputPowerDriver and DigitalOutputResetDriver should be used on top of the initial driver.
• The other DigitalOutputDrivers implement an invert property on the resource, the GpioDigitalOutputDriver should implement this pattern as well

I don't think the button abstraction is needed, from the labgrid POV we are pulling a GPIO line either high or low, that this corresponds to holding a button should be irrelevant and is best abstracted in the board strategy.

[pmelange]

A few notes:

• The drivers implementing the DigitalOutputProtocol don't need to implement the Poweror ResetProtocol, the repective adapter drivers DigitalOutputPowerDriver and DigitalOutputResetDriver should be used on top of the initial driver.

Using labgrid-client to try to run power methods (on/off/cycle) on a SysfsGPIO resource results in
labgrid-client: error: target has no compatible resource available

Am I doing something wrong?

I don't think the button abstraction is needed, from the labgrid POV we are pulling a GPIO line either high or low, that this corresponds to holding a button should be irrelevant and is best abstracted in the board strategy.

The ability to press_for a certain amount of time is still needed for my tests. With labgrid-client, the delay of calling an action can easily be longer than the press_for delay and is not accurate.

example: labgrid-client calling on "io" and pulling high, sleep for 2 seconds, pulling low...

real 0m8.138s
user 0m2.842s
sys 0m0.227s

example: labgrid-cleint calling on "button" to push_for with a 2 second delay...

real 0m5.073s
user 0m1.410s
sys 0m0.129s

[pmelange]

A few notes:

• The drivers implementing the DigitalOutputProtocol don't need to implement the Poweror ResetProtocol, the repective adapter drivers DigitalOutputPowerDriver and DigitalOutputResetDriver should be used on top of the initial driver.

Using labgrid-client to try to run power methods (on/off/cycle) on a SysfsGPIO resource results in labgrid-client: error: target has no compatible resource available

Am I doing something wrong?

I have tried the following and still not getting power methods to work on the SysfsGPIO resource with labgrid-client.

diff --git a/labgrid/remote/client.py b/labgrid/remote/client.py
index e67a28e9..bf98e354 100755
--- a/labgrid/remote/client.py
+++ b/labgrid/remote/client.py
@@ -859,7 +859,7 @@ class ClientSession:
         name = self.args.name
         target = self._get_target(place)
         from ..resource.power import NetworkPowerPort, PDUDaemonPort
-        from ..resource.remote import NetworkUSBPowerPort, NetworkSiSPMPowerPort
+        from ..resource.remote import NetworkUSBPowerPort, NetworkSiSPMPowerPort, NetworkSysfsGPIO
         from ..resource import TasmotaPowerPort, NetworkYKUSHPowerPort
 
         drv = None
@@ -881,6 +881,8 @@ class ClientSession:
                     drv = self._get_driver_or_new(target, "TasmotaPowerDriver", name=name)
                 elif isinstance(resource, NetworkYKUSHPowerPort):
                     drv = self._get_driver_or_new(target, "YKUSHPowerDriver", name=name)
+                elif isinstance(resource, NetworkSysfsGPIO):
+                    drv = self._get_driver_or_new(target, "DigitalOutputPowerDriver", name=name)
                 if drv:
                     break

result...

$ labgrid-client -p aux1 show
Place 'aux1':
  matches:
    testlab02/aux1/NetworkSysfsGPIO
  acquired: testlab02/pi
  acquired resources:
    testlab02/aux1/NetworkSysfsGPIO/SysfsGPIO
  created: 2025-02-05 11:07:56.238652
  changed: 2025-02-05 11:08:15.580108
Acquired resource 'SysfsGPIO' (testlab02/aux1/NetworkSysfsGPIO/SysfsGPIO):
  {'acquired': 'aux1',
   'avail': True,
   'cls': 'NetworkSysfsGPIO',
   'params': {'extra': {'proxy': 'testlab02', 'proxy_required': False},
              'host': 'testlab02',
              'index': 537}}
$ labgrid-client -p aux1 power on
labgrid-client: error: binding DigitalOutputPowerDriver failed: no DigitalOutputProtocol driver found in Target(name='aux1', env=None)
This is likely caused by an error or missing driver in the environment configuration.