Higher level driver modelling

[Fermi-4]

Hello,

I have a question having to do with higher level driver modeling (i.e. driver of drivers/resources)..
If I have the following situation where a driver uses 2 lower level drivers each of which use an instance of the ConsoleProtocol and then a higher level driver binding to an instance of A and B protocols like the following:

class A_Driver(Driver, A_Protocol):
      bindings = { "console": "ConsoleProtocol" }
      
      def a(self):
            pass

class B_Driver(Driver, B_Protocol):
      bindings = { "console": "ConsoleProtocol" }
      
      def b(self):
            pass

class MyDriver(Driver, MyProtocol):
       bindings = { "a": "A_Protocol", "b": "B_Protocol" }

And then for a testcase lets say I have:

def my_great_test(target_with_fakeconsole):
    a = A_Driver(target_with_fakeconsole, "a_handle")
    b = B_Driver(target_with_fakeconsole, "b_handle")
    my_higher_level_driver=MyDriver(target_with_fakeconsole, "high_level")
    target_with_fakeconsole.activate(my_higher_level_driver)

My questions are:

1. Is this the proper way to model something like this or am I going down the wrong path with this approach? If so, what would be a more idiomatic way of approaching this?
2. Assuming this is the proper way to do it, how could I have A_Driver and B_Driver both use the same ConsoleProtocol instance and both be active at the same time since the ConsoleExpectMixin will deactivate other clients when resolving conflicts?

[jluebbe]

• Is this the proper way to model something like this or am I going down the wrong path with this approach? If so, what would be a more idiomatic way of approaching this?

A concrete example would help with understanding your goal. https://labgrid.readthedocs.io/en/latest/configuration.html#environment-configuration has some example of how to specify which of a set of alternative drivers/resources a driver should bind to. There are also example with two parallel "chains" of RawSerialPorts and SerialDrivers.

• Assuming this is the proper way to do it, how could I have A_Driver and B_Driver both use the same ConsoleProtocol instance and both be active at the same time since the ConsoleExpectMixin will deactivate other clients when resolving conflicts?

Hmm. In contrast to an SSHDriver (for example), which can open multiple independent channels, the ConsoleDriver can't open more independent channels on demand. Our standard approach is to have one driver instance per "component" on the DUT side. So there is a ShellDriver for the Linux shell, a BareboxDriver for the barebox bootloader.

In your case, are there really two independent components using the DUT's console in parallel?

[Fermi-4]

Thanks for the quick reply!

A concrete example would help with understanding your goal.

Ok I will give you more concrete example.

I have 2 boards which can be powered on/off but in different ways.
board1 uses on board electrical switch controlled via a command issues over serial port (ConsoleProtocol)
board2 uses TasmotaPowerDriver to control its power.

I want to write a single driver class which can be used for both boards. Something like:

"""Drivers implementing PowerProtocol for each board  for each approach"""
...

class MyPowerDriver(Driver):
    bindings = { "power_handle": PowerProtocol }

    def power_on(self):
        self.power_handle.on()
    
    def power_off(self):
        self.power_handle.off()

And when I construct instance of MyPowerDriver I can pass either driver class to this class and have same functionality..
Is this kind of higher level abstraction possible to do?

Or here is another example:

I have boards which have following requirements:

• power on/off
• power on reset (POR)
• measure power
• set bootmode

Some boards can do these functions in different ways, but it is ultimately the same behavior

For most boards - there is a single SerialPort through which all of this functionality happens (ConsoleProtocol)
Each of the lower level drivers (por_handle, power_handle, etc) will need to access the same Console to issue the relevant commands

@target_factory.reg_driver
@attr.s(eq=False)
class AutomationDriver(Driver, AutomationProtocol):
    bindings = {
        "power_meter_handle": PowerMeterProtocol,
        "por_handle": ResetProtocol,
        "power_handle": PowerProtocol,
        "sysboot_handle": SysbootProtocol,
        "config_handle": ConfigurationProtocol
    }
@Driver.check_active
    @step(args=["code"])
    def set_bootmode(self, code: str):
        self.sysboot_handle.set_bootmode(code)

    @Driver.check_active
    @step()
    def por(self):
        self.por_handle.por()

    @Driver.check_active
    @step()
    def hold_por(self):
        self.por_handle.hold_por()
    
    @Driver.check_active
    @step()
    def release_por(self):
        self.por_handle.release_por()
    
    @Driver.check_active
    @step()
    def power_on(self):
        self.power_handle.on()
    
    @Driver.check_active
    @step()
    def power_off(self):
        self.power_handle.off()
    
    @Driver.check_active
    @step()
    def reset(self):
        self.por_handle.reset()

    @Driver.check_active
    @step(args=["samples", "delay"])
    def measure_power(self, samples: int, delay: int) -> List[RailData]:
        self.power_meter_handle.measure_power(samples, delay)

And therein lies the issue - when I activate AutomationDriver on a target it recursively accesses each binding/supplier and calls resolve_conflicts which will switch the binding/supplier to the bound state from active for all but the last one it traverses - so I get this error:

# setup omitted, assume all Fake drivers implementing the relevant protocols
my_automation_driver = AutomationDriver(target)
target.activate(my_automation_driver)

target.reset()

labgrid.binding.StateError: FakeResetDriver(target=Target(name='dummy', env=None), name='por_handle', state=<BindingState.bound: 1>) has not been activated, FakeResetDriver.reset cannot be called in state "bound"

In your case, are there really two independent components using the DUT's console in parallel?

I would say that they actually don't need to access in parallel...
rather I just need them to be able to access the console when I need them to/call those particular functions.

To add to this - I have done some more testing and if I remove the top level driver class it works at the target level:

def test(target_with_fakeconsole):
    meter_driver = target_with_fakeconsole.get_driver(target_with_fakeconsole,"PowerMeterProtocol")
    reset_driver = target_with_fakeconsole.get_driver(target_with_fakeconsole,"ResetProtocol")
    power_driver = target_with_fakeconsole.get_driver(target_with_fakeconsole,"PowerProtocol")
    sysboot_driver = target_with_fakeconsole.get_driver(target_with_fakeconsole, "SysbootProtocol")
    config_driver = target_with_fakeconsole.get_driver(target_with_fakeconsole, "ConfigurationProtocol")
    all_drivers = [meter_driver, reset_driver, power_driver, sysboot_driver, config_driver]
    for driver in all_drivers:
        target_with_fakeconsole.activate(driver)
        assert(driver.state == BindingState.active)
# PASS

The UBootStrategy class does something pretty similar to what I am looking for...

@target_factory.reg_driver
@attr.s(eq=False)
class UBootStrategy(Strategy):
    """UbootStrategy - Strategy to switch to uboot or shell"""
    bindings = {
        "power": "PowerProtocol",
        "console": "ConsoleProtocol",
        "uboot": "UBootDriver",
        "shell": "ShellDriver",
    }
  def transition(...):
   ...
    elif status == Status.off:
            self.target.deactivate(self.console)
            self.target.activate(self.power)
            self.power.off()
   ...
...

Maybe I can look at making the target activate/deactivate the other drivers when I call a function?
I think that might work but would be pretty verbose... will look into this