Summary

There are currently a few "hardware" tests that need external board connections to be made for them to work, eg bridging a pair of pins. Eg all tests in tests/extmod_hardware need some kind of connection.

Along with the physical connections -- which are different for each board -- there needs to be corresponding Python settings, eg which UART instance to use and which pins for TX/RX.

These settings are currently hard-coded in each test file. That has a few problems:

• settings are repeated, eg all the UART tests have pretty much the same settings code duplicated across them
• changing the settings means changing many files
• adding a new board means adding a lot of code
• the tests get bigger and bigger with each new board that they support, meaning they may not fit on targets with a small amount of RAM (that's already the case with tests/extmod_hardware/machine_pwm.py)
• if you have a custom board you have to manually edit the test to add your own settings

This PR aims to solve all the above problems by splitting the board-specific settings out into separate files, one for each board (or port). They are placed in the tests/target_wiring/ directory. The run-tests.py test runner then loads the appropriate configuration for the target that is being tested, sends it to the board so it's available as import target_wiring (without needing a filesystem), and then executes the test (only tests that need target_wiring have it loaded).

This PR adds support for this target_wiring module, and converts all the existing machine.UART tests to use it.

Testing

Tested locally on PYBV10 and ESP32-S2. Still needs further testing once we decide this is the way forward.

Trade-offs and Alternatives

Although the idea is straightforward, there were many decisions to make in the implementation:

1. Selection of the correct target_wiring module follows a hierarchy: if an exact match for the board name is found (via sys.implementation._build) then that's used, otherwise there's a possible wildcard match on the board name (eg for PYB* boards, they can all use the same config), otherwise there's a match on the port name (eg rp2 boards can all use the same config). This allows a lot of flexibility (maybe too much?).
2. I used a trick to send the target_wiring module to the board without using the filesystem or VFS hook. It just evaluates a new class called target_wiring with the body of the class the script with the settings. This should be pretty minimal and work on targets without a filesystem/VFS.
3. The same configuration is reused for extmod/machine_uart*.py tests ... they are not strictly hardware tests (they don't require external connections) but they do need to know which UART instance to use, and they can reuse the same instance used by extmod_hardware/machine_uart*.py tests. Hopefully this won't be an issue, but it does confuse somewhat which tests require target_wiring configuration and which don't (ie it's no longer as simple as saying that only extmod_hardware/ tests need target_wiring).
4. Eventually there may be other UART tests that need to be connected to a separate board. As such I named the config options uart_loopback_args and uart_loopback_kwargs. This shows the general problem that the approach may not scale well if lots of tests need subtly different configurations, eg I2CTarget will need a loopback configuration (4 pins) and a non-loopback configuration (another 2 pins). To make it work, the config for these either need to be named differently, or selected very carefully so the pins can overlap.
5. Tests like extmod_hardware/machine_pwm.py can reuse the UART loopback pins, but probably they should be named differently, in case they can't be reused.
6. Need to think about how to handle zephyr boards, how to detect which configuration to use (need to either add special handling in run-tests.py for zephyr, or expose sys.implementation._build on that port).
7. To manually run a test using this new target_wiring module (without using run-tests.py) requires the user to explicitly copy across the correct target_wiring.py file to their device.
8. If there's a target_wiring.py on the device then it is overridden by the one injected by run-tests.py. I think this is desired behaviour, so you don't have a stale/old file on there that messes up the test.
9. Need to add a way in run-tests.py for the user to select/override which target_wiring.py module to use, eg for custom boards, eg for Octoprobe.