Reduce the chances of xon/xoff causing comms to wedge

[obra]

As previously implemented, it's possible that our xon/off flow control could send XOFF, do a read, and then...not send XON, leading to a stuck pipe

[tlyu]

I was still getting XOFF with no XON with one of my test cases (63 A followed by a newline, sent via tio hexadecimal mode).

I added the additional patch here, which fixed it. The extra calls to flush() are probably also a good idea.

--- a/plugins/Kaleidoscope-FocusSerial/src/kaleidoscope/plugin/FocusSerial.cpp
+++ b/plugins/Kaleidoscope-FocusSerial/src/kaleidoscope/plugin/FocusSerial.cpp
@@ -39,11 +39,13 @@ void FocusSerial::manageFlowControl() {
   if (xon == true) {
     if (avail > RECV_BUFFER_THRESHOLD) {
       Runtime.serialPort().write(XOFF);  // Send XOFF to stop data
+      Runtime.serialPort().flush();
       xon = false;
     }
   } else {
     if (avail < RECV_BUFFER_RESUME) {
       Runtime.serialPort().write(XON);  // Send XON to resume data
+      Runtime.serialPort().flush();
       xon = true;
     }
   }
@@ -65,6 +67,7 @@ EventHandlerResult FocusSerial::afterEachCycle() {
       break;
     }
     c = Runtime.serialPort().read();
+    manageFlowControl();
     // Don't store the separator; just stash it
     if (c == SEPARATOR) {
       break;
@@ -82,6 +85,7 @@ EventHandlerResult FocusSerial::afterEachCycle() {
   Runtime.onFocusEvent(input_);
   while (Runtime.serialPort().available()) {
     c = Runtime.serialPort().read();
+    manageFlowControl();
     if (c == NEWLINE) {
       // newline serves as an end-of-command marker
       // don't drain the buffer past there

[tlyu]

Also, not a blocker for this change, but I think that if we can get the USB-level flow control to work with the new ZLP patches, we shouldn't add complexity by adding XON/XOFF flow control. Or maybe implement it at the Serial abstraction, if we really have to, but that has its own risks.

[obra]

Just to confirm, I'd be delighted if it turned out we didn't need xon/xoff flow control.