New device management approach

[lukaskremla]

In the last few days I've been considering how stubs and device type detection could be handled. Firstly, I would welcome moving the port selector drop down left of the connect/disconnect button in the MicroPython plugin window. This would make it easier to work with, as I often find myself having to go to the settings multiple times in a day, which can get annoying.

I understand that this could be difficult and that it has plenty of considerations, here are a few problems and their solutions I thought of:

Users changing the serial port when connected - upon successfully connecting it would be great to gray out the dropdown to not be clickable. From my experience working with the Jetbrains UI API perhaps this could be possible with some disable parameter/property.
Refreshing the serial port drop down - would it be possible to refresh the serial port listing each time the drop down is expanded?
Filtering out irrelevant serial devices - here I would look at how Thonny does it, I believe, using USB VID and PID. Thonny's port selector looks sort of like this: MicroPython (ESP32): Espressif Device @ /dev/cu.usbmodem101. Now this plugin could simplify it to ESP32: /dev/cu.usbmodem101. This would serve the purpose of making the selection clearer and it could also be used for handling stubs - although the best way here might be interrogating the device for specific device type and MicroPython version each time a connection is established.
There are two more considerations -> handling WebREPL and stubs when no device is connected:
For both of these problems I would go with an approach similar to how thonny does it. In Thonny you have the bottom right serial port drop down, which is the default quick access. Then its interpreter settings allow you to select a device manufacturer, specific communication type and then either the serial device or WebREPL credentials. The way this then propagates is that the main quick access serial device drop down is switched to displaying MicroPython (ESP32): ws://192.168... again this could be adapted like I suggested before.

This plugin's implementation could be expanded for choosing the MicroPython version as well, so that users have more control over specific stub settings should they need it.

[elmot]

Follow actual list of serial ports
That is done already in another plugin, https://plugins.jetbrains.com/plugin/8031-serial-port-monitor
I don't think those plugins work together normally, because they use the same low-level library

Filtering devices by VID:PID
For me this does not work, because many different devices share same IDs, while the same device may have different VID:PID pair.
I don't want to keep my own vid-pid database, but it might be left on users responsibility, like keeping per-project list of relevant VID:PID
Another problem is that finding UART<->VID:PID equivalence is platform specific, and not supported by java low-level UART libraries.

Device detection
I'd prefer to use https://pypi.org/project/mpflash/. It looks like the great job with device detection'n'flashing is done over there, and I see no reason to reinvent the wheel.

[lukaskremla]

I get the issue with tracking USB identifiers and after spending some more time looking at the existing communication layer I have even more understanding for why you're considering mpremote. I've realized how helpful it can be to get rid of the responsibility to maintain all this.

Now I actually think it might not be too bad of an idea to consider swapping the current serial connection layer for an mpremote integration while keeping the existing kotlin WebREPL logic until mpremote supports it.

I agree with you that mpflash seems like really good python library to integrate into this plugin. I can see it being very helpful not only for device detection, but also for stubs and possibly adding micropython port flashing functionality to the plugin itself.

Only note about mpflash as of right now is that it doesn't work too great on MacOS. The way that bluetooth ports work on MacOS means that mpflash attempts to scan them as well and it can hang for over a minute on scanning one port, this would be problematic if mpflash was meant to be used in this plugin. I've created a bug report, hopefully this problem can be resolved.

Besides that mpflash looks great!

[Josverl]

mpflash by default should skip bluetooth serial ports on all host OSes, but as I do not have a Mac, I need to rely on testing by others and logging and bug reports.
So thanks for reporting this.

[Josverl]

Update:
With the help of @lukaskremla I was able to update mpflash to v1.24.4 which on MacOS avoids devices causing time-outs and delays.

[lukaskremla]

I've spent some more time working with mpremote, two more insights I got out of it:

1. Device reset triggered by pressing the board's RST button (if it has one) will cause the REPL connection to drop. For me this would be annoying, as I prefer the more persistent REPL connection of the current communication implementation.

2. It seems like there's no functionality for automatically connecting to REPL and soft reseting the device to get all its prints (from the first line of boot.py)

3. might just be me missing something, but if that's not the case this could be problematic.

Right now, I'm not sure about mpremote, it appears to me that you have already gave some thought to how it could be implemented, so perhaps you know a way around these obstacles. My personal opinion is probably leaning towards staying in pure Kotlin because of the direct control it gives.

[elmot]

UI ideas you've expressed are all fine and doable.