Adapting to a New DUT

The concrete work behind „customized for your application". The docking shields shown on the hardware page are exactly what the first row of this table produces.

To test a different target system, the following adaptations are required:

Layer	Adaptation
Hardware	Design a docking shield mapping the board's GPIO/SPI/UART to DUT connectors
CPU1 — hardware abstraction	Configure pin assignments, implement DUT-specific protocols and peripheral simulation
CPU2 — test logic	Write the C test logic or simulation model for the new target
Python API	Update signal name → hardware mappings in the configuration table
Test scenarios	Describe the DUT's expected behavior in your test framework of choice
Test steps	Extend or rewrite the reusable steps for DUT-specific preconditions and assertions

The last two rows depend on how you structure your tests. In the Behave example they correspond to new .feature files and their step definitions; with pytest they would be test modules and fixtures.

How much CPU2 work is needed depends on the DUT

If the target's environment can be driven with the existing hardware abstraction primitives, CPU2 may need little or no custom code — Python can drive the sequence directly. Custom C logic on CPU2 becomes necessary when reactions must happen faster than a network round trip, or when you are modelling continuous behavior such as a motor or sensor.

Integrating additional lab equipment

Additional lab equipment can also be included in the test framework. For example, a programmable power supply controlled via Python can simulate supply voltage drops or brown-out conditions during a scenario.

Any instrument with a serial, USB, or network API can be wrapped in a test step and used alongside the LoopCheck commands.