Debug Terminal: Automatic (event-driven) port arrival/departure handling

[PropGit]

Gracefully handle USB-based Virtual COM Port arrivals and departures.

The legacy serial port support that is also used for USB-based Virtual COM Ports may act in undesirable ways if the application has the port open when unexpectedly is it physically disconnected (causing the port to disappear from the system). On Windows, this often resulted in preemptive process lock-out.

1. Test what happens on various supported platforms when an open port is physically removed
2. If the result is unfavorable, see if there's a way to resolve it like what we did in the BSE.

More notes can be found in

• the Settings section of the Debug Terminal document.
• the Communications > Serial/USB Ports > Automatic (event-driven) port refresh section of the Chrome IDE Phase 2 Discussion Notes document.

[PropGit]

UPDATE: Testing on Windows.

On Win 7 64-bit, when Chrome IDE has downloaded and is successfully receiving data from the BASIC Stamp, disconnecting the USB port doesn't cause a visible problem immediately; however, the port remains open and presumably Chrome IDE's handle is invalid.

• Disconnecting USB port while in use causes no visible issue
  • Chrome IDE still functions and can download to other ports
• Reconnecting USB port doesn't result in Debug Terminal display working again
• Trying to download again to that port fails with a message indicating Chrome IDE can't open the port
  • Perhaps, when a user tries to download, a simple call to close the handle first, then a call to open the port would fix this?
• Closing Chrome IDE and reopening Chrome IDE allows it to download to the port once again

Though this is a better situation than what we had experienced in BSE on Windows upon active port departure, we still need Chrome IDE to handle it more gracefully than it currently does by automatically handling the situation as described in the Debug Terminal document (noted in prev post).

The idea to tap into USB events and then re-enumerate the existing COM port list is a good one that will fit well as part of this solution.

[PropGit]

@2fast2fourier - Here's a list of the VID/PID pairs we are interested in monitoring for spontaneous departure/re-arrival:

   VID   /  PID   - Device 
  0x0403 / 0x6001 - FT232AM/BM/R, FT245R
  0x0403 / 0x6015 - FT231X

[PropGit]

Reminder, the algorithm for handling departure and arrival events is listed in the third major bullet of the Settings section of the Debug Terminal document. Any mention of "visible port field" can be treated as "the current known port in use" since we don't currently have a visible port field.

[phated]

The comment at #299 (comment) outlines a caveat on Windows for this feature. However, it will work on OSX and ChromeOS due to no reliance on WinUSB on those platforms.

[PropGit]

Verified:

• Works on Mac OS X
  • must be host; feature does not work on VM
• Works on Chromebook
• Works on Ubuntu
  • must be host; feature does not work on VM
• Does not work on Windows for reasons we can not fix