Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.38%. Comparing base (8c47e44) to head (092d0f3).
⚠️ Report is 4 commits behind head on master.

@@           Coverage Diff           @@
##           master   #17999   +/-   ##
=======================================
  Coverage   98.38%   98.38%           
=======================================
  Files         171      171           
  Lines       22296    22296           
=======================================
  Hits        21937    21937           
  Misses        359      359           

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

@projectgus , I have been working on an alternative way to ID the serial ports based on VID/PID : #17800

While that guarantees that the dtr won't be set for usb-cdc, there is a risk of missing out on some serial devices.
We can bake in the known ones, and load additional ones from the Mpremote config.py now that it works across platforms

@projectgus , I have been working on an alternative way to ID the serial ports based on VID/PID : #17800

While that guarantees that the dtr won't be set for usb-cdc, there is a risk of missing out on some serial devices. We can bake in the known ones, and load additional ones from the Mpremote config.py now that it works across platforms

Thanks @Josverl. I did see this, but I have some concern that the list of possible ESP* USB/serial chips will trend in the limit towards the current logic (i.e. someone somewhere has made an ESP board with approximately every USB/serial converter on the market).

I actually have another idea for how to manage this, I'll try to put up a draft PR soon and see what you think.

Whether or not we merge #18001, I suggest we still consider this PR for a v1.26.1 release (as it's much lower risk of regression).

Yes, I think we'll need a v1.26.1.

someone somewhere has made an ESP board with approximately every USB/serial converter on the market.

I agree that the list is likely endless , and unobtainable - but I do not think that we can truncate the list to just one VID/PID either.
While I do not have any Pycom device, I think that would not be detected , while it could be detected.

So if we built the logic to add :

• a, known but incomplete, list of VID/PIDs ,
• a way to change the behaviour by either :
  • parameters : --dtr high|low|none --rts high|low|none ( careful of inversion logic on ESPxx boards)
  • or config ( VID / PID list )

I think we can offer both simple reliability for most boards , and ability to work with any boards.

( bit HIL testing takes time- and timeframes matter - so its OK to smash the Big bugs first, and worry about the little critters later if you want to release 1.26.1 )

(Sorry I wrote a reply here earlier but GitHub seems to have eaten it.)

its OK to smash the Big bugs first, and worry about the little critters later if you want to release 1.26.1 )

Yes, this PR is only an attempt to fix the 1.26 regression introduced by #10347, not to solve all Windows USB/Serial issues. I've updated the description with some tables to make it clearer what does and doesn't change with this PR.

Regarding the big picture on Windows USB/serial logic: I think we can discuss this in the comments on #17800 and #18001. I still want to figure out if/when the latter approach doesn't work, if it turns out to be unsuitable then something like #17800 seems like the next best option. Adding a way to override the mpremote DTR & RTS defaults seems like a good feature regardless, fully agree.