3.1r1: 8.12.2, collision avoidance

[jadamcrain]

3.1r1's 8.12.2 over the serial transport from #54. 3.1r1 is now implemented in full.

Steps (each set of delays runs them all):

• Steps 1–2: generate class 1 events, then read class 1 with link control block 0xC4. The DUT must answer with data. The time from the end of the read to the start of the answer gives its turnaround.
• Step 3: size the noise as a whole number of frames that ends within the window from the later of the turnaround and the fixed delay, to the turnaround plus both delays. It aims for the frame count nearest the middle. If no count fits, the run aborts as a bench problem.
• Steps 4–6: send the read followed at once by the noise. The answer must start no sooner than the fixed delay after the noise ends, and no later than both delays after it.
• Step 7: repeat that ten times in all. The delays must spread over more than the tolerance. Where the maximum random delay is at least four times the tolerance, at most 6 of the 10 may be within a quarter of the tolerance of any one; a truly random device trips that well under 1% of the time. Where the random delay is too short to tell its values apart, the result notes that this wasn't verified.
• Steps 8–9: send noise, a gap of half the fixed delay, then noise again, so the DUT must back off twice. The harness measures an upper bound on the gap it made; if that isn't shorter than the fixed delay, the run aborts as a bench problem.
• Steps 10–11: set the other delays through the plugin (setCollisionDelays) and repeat. The usual delays are restored at the end, even after a failure.

The answer and the noise

• The answer counted is the first frame of a response to the master, with the read's sequence number, not unsolicited, carrying objects. The harness's own echoed frames are skipped.
• The noise is REQUEST LINK STATUS frames to a reserved address, which no device answers.
• For a DUT that watches carrier, the harness asserts RTS while it sends noise.
• The answers aren't confirmed, so the events stay for every read.

Timing. All times are measured on the host:

• The serial channel now reads the port on a background thread, which timestamps bytes as they arrive whatever the harness is doing. The frame parser keeps the first byte's time for each frame (readFrameTimed).
• Writes block until the bytes are sent. The noise's end is the later of when the write returned and the write's start plus its bytes' time on the line.
• serial.timingToleranceMs allows for what the adapter adds, both ways, e.g. a USB adapter's latency timer.

Options

• serial.collisionAvoidance
• serial.collisionDetection (data or carrier)
• serial.fixedDelayMs and serial.maxRandomDelayMs
• serial.otherFixedDelayMs and serial.otherMaxRandomDelayMs
• serial.timingToleranceMs

The configuration check requires a fixed delay above 0, and other delays that change both values.

Tests:

• a simulated line on virtual time, with a device that backs off as it should, one that answers over the noise, ones whose delays don't vary or mostly repeat, and one that watches carrier;
• the parser's arrival times;
• a pty test showing that bytes are timed when they arrive, not when they're read.

The timing hasn't been run against a real serial device.

2.7's 8.12.2 stays not implemented, and its -describe output is unchanged.