Skip to main content

Peripherals & interfaces

MIMICK models everything attached to a bench with two ideas: peripherals and interfaces. Together they tell you what you can talk to and how to address it.

Peripherals​

A peripheral is a piece of hardware reachable from a bench: a USB-to-serial cable, an FTDI adapter, a network-attached relay, and so on. You declare each one in the bench's peripheral config under a name you choose, and that name stays the same across unplugging and replugging.

You can list the peripherals on your active bench at any time:

mimick peripheral list

To see one peripheral in detail, pass its address to info:

mimick peripheral info lan.ethernet0

This reports how the peripheral is attached and what it's doing. For a network interface that includes link state, addressing, and the DHCP leases it has handed out. Add --format json to get the same detail for a script.

Interfaces​

An interface is a way of talking to a peripheral: a bus or protocol it exposes, such as a serial console, UART, SPI, GPIO, or a relay channel. A single peripheral often exposes several interfaces at once. An FTDI FT232H, for instance, can present SPI and GPIO from the same physical device.

When a peripheral exposes more than one of the same interface (say, several serial ports), you pick which one with a capability-channel index.

Interfaces available today​

MIMICK supports these interfaces now:

  • Interactive console (TTY): a live terminal to a serial console.
  • UART: raw serial byte send and receive.
  • SPI: full-duplex transfers and register reads and writes.
  • GPIO: read, write, and watch individual pins.
  • Relay: switch discrete channels, for example to power-cycle a DUT.

Addresses​

Each interface has an address made of the peripheral's name, the interface type, and its channel:

dut_console.tty0
mpsse.spi0

When a peripheral has only one interface, its name alone works too. You pass an address to mimick peripheral info and, after the command name, to the interface commands such as mimick connect and mimick uart. The -p flag takes the same address:

mimick connect dut_console.tty0
mimick relay write -p button_relay 1 on

An address names the peripheral, not the hardware. The USB port or device path the hardware sits on shows in the HWADDR column of mimick peripheral list, and you can't use it as an address.

Tell a bench what's attached​

A bench learns its peripherals from one YAML file, peripherals.yaml. A new bench starts with an empty file, so it has no peripherals until you deploy one. The configuration file reference lists its structure, and each driver page lists the settings for one kind of hardware.

Deploy the file​

From the CLI, pull the bench's current file, edit it, and deploy it back:

mimick peripheral config > peripherals.yaml
mimick peripheral config-set peripherals.yaml

Both commands act on the bench you selected with mimick bench use. Add --bench <bench> to target a different one.

In the web UI, organization admins see a Config tab on the bench page. It holds a YAML editor with Deploy, Refresh, and Revert buttons. While the bench is offline, the tab shows the last copy the Cloud saw, read-only.

The bench must be online to take a new file. It reloads the file in place, without a restart:

  • Peripherals you didn't change keep running, and so do any sessions open on them.
  • Peripherals you changed or removed are closed.
  • Deploying a file identical to the current one does nothing.

If the file breaks one of the file-wide validation rules, the bench rejects it, the CLI or web UI shows the error, and the bench keeps its current file.

Find a location​

Each peripheral's location tells the bench where to find its hardware. mimick peripheral list also shows hardware the bench detects that no peripheral claims yet, and its HWADDR column holds the value to paste into location. This works for USB serial devices, FTDI adapters, and network ports. For hardware the bench can't detect on its own, such as a network relay, use the address from the device's own documentation.

Configs and setups​

Some hardware has more than one useful configuration. A network port might serve DHCP to the device under test (DUT) in one test and take an address from the DUT's network in the next. Instead of editing the file between tests, you can declare each variant as a named config of the same peripheral. Only one config of a peripheral is active at a time.

A setup groups configs across several peripherals, so one switch puts the whole bench into a known state, such as "lab" or "field". The bench activates the default setup at boot. See configs and setups for the syntax.

Switch a setup​

Switch setups from the Inventory tab of the bench page in the web UI. The Setup list activates a whole setup, and the list on each peripheral row switches that one peripheral's config. The setup list reads Custom when the active configs don't match any one setup.

A switch has a few limits:

  • It isn't saved to the file. When the bench restarts, it returns to the default setup.
  • It can't happen while a peripheral is in use. Close any session open on it first.
  • The CLI has no command to switch setups or configs.

Missing peripherals​

A peripheral whose hardware the bench can't open stays in the list with the status missing, and commands against it return a clear error. That covers a device that's unplugged or unreachable, and a peripheral whose settings its driver rejects. In the web UI, hover over the status badge on the Inventory tab to see the reason.

The bench checks missing peripherals again every 30 seconds and brings each one back as soon as it opens. Run mimick peripheral refresh to check right away, for example after you plug a device in.