~~~~~~~~~~~~~~~~~~~~~
- A colored StepReporter was added and can be used with ``pytest
--lg-colored-steps``.
- ``labgrid-client`` can now use the last changed information to sort listed
resources and places.
- ``labgrid-client ssh`` now uses ip/user/password from NetworkService resource
if available
- The pytest plugin option ``--lg-log`` enables logging of the serial traffic
into a file (see below).
- The environement files can contain feature flags which can be used to control
which tests are run in pytest.
- ``LG_*`` variables from the OS environment can be used in the config file with
the ``!template`` directive.
- The new "managed file" support takes a local file and synchronizes it to a
resource on a remote host. If the resource is not a `NetworkResource`, the
local file is used instead.
- ProxyManager: a class to automatically create ssh forwardings to proxy
connections over the exporter
- SSHManager: a global manager to multiplex connections to different exporters
- The target now saves it's attached drivers, resources and protocols in a
lookup table, avoiding the need of importing many Drivers and Protocols (see
`Syntactic sugar for Targets`_)
- When multiple Drivers implement the same Protocol, the best one can be
selected using a priority (see below).
- The new subcommand ``labgrid-client monitor`` shows resource or places
changes as they happen, which is useful during development or debugging.
- The environment yaml file can now list Python files (under the 'imports' key).
They are imported before constructing the Targets, which simplifies using
custom Resources, Drivers or Strategies.
- The pytest plugin now stores metadata about the environment yaml file in the
junit XML output.
- The ``labgrid-client`` tool now understands a ``--state`` option to
transition to the provided state using a :any:`Strategy`.
This requires an environment yaml file with a :any:`RemotePlace` Resources and
matching Drivers.
- Resource matches for places configured in the coordinator can now have a
name, allowing multiple resources with the same class.
- The new `Target.__getitem__` method makes writing using protocols less verbose.
- Experimental: The labgrid-autoinstall tool was added (see below).
New and Updated Drivers
~~~~~~~~~~~~~~~~~~~~~~~
- The new `DigitalOutputResetDriver` adapts a driver implementing the
DigitalOutputProtocol to the ResetProtocol.
- The new `ModbusCoilDriver` support outputs on a ModbusTCP device.
- The new ``NetworkUSBStorageDriver`` allows writing to remote USB storage
devices (such as SD cards or memory sticks connected to a mux).
- The new `QEMUDriver` runs a system image in QEmu and implements the
:any:`ConsoleProtocol` and :any:`PowerProtocol`.
This allows using labgrid without any real hardware.
- The new `QuartusHPSDriver` controls the "Quartus Prime Programmer and Tools"
to flash a target's QSPI.
- The new `SerialPortDigitalOutputDriver` controls the state of a GPIO using
the control lines of a serial port.
- The new `SigrokDriver` uses a (local or remote) device supported by sigrok to
record samples.
- The new `SmallUBootDriver` supports the extremely limited U-Boot found in
cheap WiFi routers.
- The new `USBSDMuxDriver` controls a Pengutronix USB-SD-Mux device.
- The new `USBTMCDriver` can fetch measurements and screenshots from the
"Keysight DSOX2000 series" and the "Tektronix TDS 2000 series".
- The new `USBVideoDriver` can stream video from a remote H.264
UVC (USB Video Class) camera using gstreamer over SSH. Currently,
configuration for the "Logitech HD Pro Webcam C920" exists.
- The new `XenaDriver` allows interacting with Xena network testing equipment.
- The new `YKUSHPowerDriver` and `USBPowerDriver` support software-controlled
USB hubs.
- The bootloader drivers now have a ``reset`` method.
- The `BareboxDriver`'s boot string is now configurable, which allows it to work
with the ``quiet`` Linux boot parameter.
- The `IMXUSBLoader` now recognizes more USB IDs.
- The `OpenOCDDriver` is now more flexible with loading configuration files.
- The `NetworkPowerDriver` now additionally supports:
- 24 port "Gude Expert Power Control 8080"
- 8 port "Gude Expert Power Control 8316"
- NETIO 4 models (via telnet)
- a simple REST interface
- The `SerialDriver` now supports using plain TCP instead of RFC 2217, which is
needed from some console servers.
- The `ShellDriver` has been improved:
- It supports configuring the various timeouts used during the login process.
- It can use xmodem to transfer file from and to the target.
Incompatible Changes
~~~~~~~~~~~~~~~~~~~~
- When using the coordinator, it must be upgrade together with the clients
because of the newly introduce match names.
- Resources and Drivers now need to be created with an explicit name
parameter.
It can be ``None`` to keep the old behaviour.
See below for details.
- Classes derived from :any:`Resource` or :any:`Driver` now need to use
``attr.s(cmp=False)`` instead of ``attr.s`` because of a change in the
attrs module version 17.1.0.
Syntactic sugar for Targets
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Targets are now able to retrieve requested drivers, resources or protocols by
name instead of by class.
This allows removing many imports, e.g.
::
from labgrid.driver import ShellDriver
shell = target.get_driver(ShellDriver)
becomes
::
shell = target.get_driver("ShellDriver")
Also take a look at the examples, they have been ported to the new syntax as well.
Multiple Driver Instances
~~~~~~~~~~~~~~~~~~~~~~~~~
For some Protocols, it is useful to allow multiple instances.
DigitalOutputProtocol:
A board may have two jumpers to control the boot mode in addition to a reset
GPIO.
Previously, it was not possible to use these on a single target.
ConsoleProtocol:
Some boards have multiple console interfaces or expose a login prompt via a
USB serial gadget.
PowerProtocol:
In some cases, multiple power ports need to be controlled for one Target.
To support these use cases, Resources and Drivers must be created with a
name parameter.
When updating your code to this version, you can either simply set the name to
``None`` to keep the previous behaviour.
Alternatively, pass a string as the name.
Old:
.. code-block:: python
>>> t = Target("MyTarget")
>>> SerialPort(t)
SerialPort(target=Target(name='MyTarget', env=None), state=<BindingState.bound: 1>, avail=True, port=None, speed=115200)
>>> SerialDriver(t)
SerialDriver(target=Target(name='MyTarget', env=None), state=<BindingState.bound: 1>, txdelay=0.0)
New (with name=None):
.. code-block:: python
>>> t = Target("MyTarget")
>>> SerialPort(t, None)
SerialPort(target=Target(name='MyTarget', env=None), name=None, state=<BindingState.bound: 1>, avail=True, port=None, speed=115200)
>>> SerialDriver(t, None)
SerialDriver(target=Target(name='MyTarget', env=None), name=None, state=<BindingState.bound: 1>, txdelay=0.0)
New (with real names):
.. code-block:: python
>>> t = Target("MyTarget")
>>> SerialPort(t, "MyPort")
SerialPort(target=Target(name='MyTarget', env=None), name='MyPort', state=<BindingState.bound: 1>, avail=True, port=None, speed=115200)
>>> SerialDriver(t, "MyDriver")
SerialDriver(target=Target(name='MyTarget', env=None), name='MyDriver', state=<BindingState.bound: 1>, txdelay=0.0)
Priorities
~~~~~~~~~~
Each driver supports a priorities class variable.
This allows drivers which implement the same protocol to add a priority option
to each of their protocols.
This way a `NetworkPowerDriver` can implement the `ResetProtocol`, but if another
`ResetProtocol` driver with a higher protocol is available, it will be selected
instead.
See the documentation for details.
ConsoleLogging Reporter
~~~~~~~~~~~~~~~~~~~~~~~
The ConsoleLoggingReporter can be used with the pytest plugin or the library.
It records the Data send from a DUT to the computer running labgrid.
The logfile contains a header with the name of the device from the environment
configuration and a timestamp.
When using the library, the reporter can be started with::
from labgrid.consoleloggingreporter import ConsoleLoggingReporter
ConsoleLoggingReporter.start(".")
where "." is the output directory.
The pytest plugin accepts the ``--lg-log`` commandline option, either with or
without an output path.
Auto-Installer Tool
~~~~~~~~~~~~~~~~~~~
To simplify using labgrid for provisioning several boards in parallel, the
``labgrid-autoinstall`` tool was added.
It reads a YAML file defining several targets and a Python script to be run for
each board.
Interally, it spawns a child process for each target, which waits until a matching
resource becomes available and then executes the script.
For example, this makes it simple to load a bootloader via the
:any:`BootstrapProtocol`, use the :any:`AndroidFastbootDriver` to upload a
kernel with initramfs and then write the target's eMMC over a USB Mass Storage
gadget.
.. note::
``labgrid-autoinstall`` is still experimental and no documentation has been written.
Contributions from: Ahmad Fatoum, Bastian Krause, Björn Lässig, Chris Fiege, Enrico Joerns, Esben Haabendal, Felix Lampe, Florian Scherf, Georg Hofmann, Jan Lübbe, Jan Remmet, Johannes Nau, Kasper Revsbech, Kjeld Flarup, Laurentiu Palcu, Oleksij Rempel, Roland Hieber, Rouven Czerwinski, Stanley Phoong Cheong Kwan, Steffen Trumtrar, Tobi Gschwendtner, Vincent Prince