Repository navigation
Enable hardware flow control in SerialTransport #59
Description
SerialTransport in harp-serial opens the port without hardware flow control. The ATxmega core relies on it: after receiving a request, the device raises its RTS line until it has processed the request, which it does about once per millisecond. When the host ignores that line, the device drops requests sent closer together than that, silently and with no reply.
Measured on Windows with a Behavior board running core.atxmega, sending reads through SerialTransport with no wait for replies:
| Requests | As opened today | With rtscts set |
|---|---|---|
| Pair in one write | 50 of 100 lost | 0 lost |
| Pair, 0.5 ms apart | 22 of 100 lost | 0 lost |
| Pair, 1 ms apart | 0 lost | 0 lost |
| Four in one write | 145 of 200 lost | 0 lost |
| Eight in one write | 332 of 400 lost | 0 lost |
Any code that sends a request before the previous reply arrives can run into this, for example requests issued from several threads. The losses were first reported in harp-tech/core.atxmega#16.
Bonsai.Harp opens the port with Handshake.RequestToSend, so the proposed change is to pass rtscts=True when opening the port. Requiring this in the specification is proposed in harp-tech/protocol#244.
One question before changing the default: on devices with native USB CDC, such as those built on the Pico core, the RTS and CTS lines are virtual, and whether enabling flow control is harmless there has not been measured. Bonsai.Harp enables it for every device, which suggests it is.
Activity