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 )