Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.38%. Comparing base (2bd337e) to head (0575173).
⚠️ Report is 1 commits behind head on master.

@@           Coverage Diff           @@##           master   #18533   +/-   ##=======================================  Coverage   98.38%   98.38%           =======================================  Files         171      171             Lines       22300    22300           =======================================  Hits        21939    21939             Misses        361      361

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report?Share it here.

Should there be an option to filter out the Bluetooth serial.?

Bluetooth serial: when Windows creates outgoing/incoming RFCOMM ports, they appear as COMx and are listed in the registry.

AFAIK the registry does not provide sufficient detail for that.

Should there be an option to filter out the Bluetooth serial.?

Bluetooth serial: when Windows creates outgoing/incoming RFCOMM ports, they appear as COMx and are listed in the registry.

AFAIK the registry does not provide sufficient detail for that.

Good idea — could be added to a TODO/wishlist for post-merge enhancements (e.g. UART.list(bluetooth=False) or similar).
For now, Bluetooth SPP ports work identically to physical serial.
Users may legitimately want to communicate with BT devices via UART API.
Let's keep it simple and let users decide what they need.

@dpgeorge,@stinos
Feel free to let me know if I missed anything.
Are there any suggestions to improve the chances of a merge?

could be added to a TODO/wishlist for post-merge enhancements
Let's keep it simple and let users decide what they need.

My point is that by choosing the registry API - this will not be possible other than by replacing it entirely with another API that does provide access to richer information.
I think this is a relevant design decision at this point, and should not just be punted forward

could be added to a TODO/wishlist for post-merge enhancements
Let's keep it simple and let users decide what they need.

My point is that by choosing the registry API - this will not be possible other than by replacing it entirely with another API that does provide access to richer information. I think this is a relevant design decision at this point, and should not just be punted forward

Valid concern. Registry API (advapi32) indeed cannot distinguish Bluetooth ports.

However:

1. Other MicroPython ports (esp32, stm32, rp2) don't filter hardware either
2. pyserial's comports() also returns all ports - filtering is user's responsibility
3. SetupAPI would add ~50% more code and setupapi.dll dependency
4. Future enhancement possible without breaking changes (add optional filter param)

Even pyserial has open PR#70 (since 2016) to add Registry support - SetupAPI misses virtual ports (com0com).
For v1, keeping it simple and consistent with other ports seems reasonable. We can revisit if users request filtering.

- Registry        : advapi32 WinNT+   - Sees busy ports. No metadata (can't filter BT).                  [libserialport, jSSC/Arduino, .NET Runtime, Sysinternals Portmon]- QueryDosDevice  : kernel32 WinXP+   - Same issues + buffer guesswork.                                  [-]- SetupAPI        : setupapi Win2000+ - +50% code, slower - for metadata we don't need.                  [pyserial, node-serialport]- CreateFile loop : kernel32 Any      - Slow, misses busy ports, side effects (DTR toggle). antipattern. [Tera Term legacy]- WMI             : ole32+   Win2000+ - Massive complexity for no benefit. overkill

My experience and feedback from mpflash users was that they did not want enumeration and connections to Bluetooth serial ports by default (Windows, Linux, nor Mac) , and want an opt-in for the edge cases.

While enumeration and connection to all potential ports is different from single connection I think this view from the community is a relevant input.

Thanks for sharing your research
To me only Registry or SetupAPI make sense. but as Pyserial apparently uses SetupAPI under the hood, there is no need to rip-and replace in the future.

Filtering BT could be just using Pyserial, similar to themflash BT filter

So I think this PR is a good starting point.