pyboard.py: Default to the last available serial port on the system

[daid]

A small addition to the pyboard.py upload tool. This makes it default to the last serial port available on the system instead of /dev/ttyACM0.

My main reason for adding this is that port numbers on windows are not very predictable, and looking up the port each time is quite annoying.
The reason for picking the last port in the list, is that physical RS232 ports (even if they are rare) are first in the list before USB ports. So the last thing in the list is the thing you most recently plugged in. So very likely your target.

End result of this change is that not specifying a port on Windows works. And not specifying a port on Linux will act slightly different if you have multiple boards connected.

[github-actions]

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
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

[Josverl]

Why?

Not specifing a port never has failed me on Windows, nor on Linux.

This would break the common workflow and expectation for a reverse one which would be rather surprising, to say the least

And if you are talking about the last one, should COM11: be before, or after COM3?

Also I find that port numbers on windows are highly predictable and stable across plug in, usb hubs and reboots of both host and MCU, while my limited experience on Ubuntu has thought me that is not always the case, and plug-in order and MCU restarts can result in differ port names.

What is the root cause of the issue you are trying to solve? Is there perhaps a BT set rial port set at a lower port than your MCU?

[daid]

Not specifing a port never has failed me on Windows, nor on Linux.

Then most likely, you have an environment variable (PYBOARD_DEVICE) set on Windows (or something else set it for you). As it cannot work without a parameter or environment setting in Windows. On Linux, it's quite likely that your board is /dev/ttyACM0

This would break the common workflow and expectation for a reverse one which would be rather surprising, to say the least

I think you are wrong here, it doesn't break a common workflow. As the default of /dev/ttyACM0 isn't valid on Windows, and very likely the one and only or last detected serial port on Linux.

And if you are talking about the last one, should COM11 be before, or after COM3?

COM11 comes after COM3 in the listed serial ports from the pyserial utils.

Also I find that port numbers on windows are highly predictable and stable across plug in, usb hubs and reboots of both host and MCU

Windows ensures the same device produces the same port number. However, I'm not plugging in the same device all the time, I'm switching between a lot of devices. In which case Windows produces different port numbers for each.

while my limited experience on Ubuntu has thought me that is not always the case, and plug-in order and MCU restarts can result in differ port names.

Per default (unless you setup udev rules) Linux just numbers them by detection order, so the first becomes /dev/ttyACM0, 2nd /dev/ttyACM1, and if you unplug the first one and plug in a different board that now becomes /dev/ttyACM0. UNLESS something still had the port /dev/ttyACM0 open, in which case that is still "reserved" and then it becomes /dev/ttyACM2. Which is why it can feel unpredictable on Linux.

What is the root cause of the issue you are trying to solve? Is there perhaps a BT set rial port set at a lower port than your MCU?

The root cause of my issue is that I'm swapping a lot of different boards and Windows all gives these different port numbers.

A different solution that wouldn't change the current (IMHO broken on Windows) default behavior is to have a --device auto as parameter to auto find which serial port to use.