Support For All MicroPython Boards

[sfe-SparkFro]

Feature Request 🚀

Is your feature request related to a problem? Please describe.

This extension can't be used with most MicroPython boards.

There are hundreds of boards that run MicroPython (this list doesn't even include all the forks: https://micropython.org/download/), but only a handful of boards can be used with this extension. No SparkFun boards can be used, for example: https://micropython.org/download/?vendor=Sparkfun

Describe the solution you'd like

Add core feature support for all MicroPython boards.

To be clear, this request is not for all features of this extension to be supported on all boards. I understand that some features are specific to particular ports or boards (eg. auto-completion), this request is not related to those features. However the core features like connecting to the REPL and accessing the file system should be the same across all ports and boards. Tools like mpremote for example can handle these features across all MicroPython boards, so this extension should be able to as well.

Describe alternatives you've considered

For unsupported board types, users currently have to go elsewhere. The best alternative to my knowledge is Thonny, which is beginner-friendly, but isn't really suitable for advanced users wanting a more feature-rich IDE. No other tools I've come across handle MicroPython boards as well as Thonny and this extension, particularly with respect to REPL access, file management and editing, etc.

I personally turn to VS Code for most of my development, as do many others. I'm not aware of any other VS Code extensions that interface with MicroPython devices that are actually up to date and maintained, so this extension is really the only viable option for VS Code.

Teachability, Documentation, Adoption, Migration Strategy

I think it would make sense to have a "generic" board support like Thonny does. Any features specific to particular ports or boards (eg. auto-completion) would obviously be missing, but that shouldn't prevent core features (REPL, file management, etc.) from being used with a "generic" board.

We at SparkFun would be interested in highlighting this extension for users as a more advanced alternative to Thonny. However since this extension can't be used on any of our boards, we can't recommend it for our customers. If generic board support is added, we will definitely reconsider that decision!

[tgrandgent]

There might be some unintended recent change in behavior here.

I've used this extension periodically over the past 3 years with the Adafruit QT Py RP2040. Today with the current version 4.2.1 I tried to connect and it would not connect whether I manually specified a serial port or not. I was still able to connect to a Pico and Pimoroni Presto.

I looked at the list of open issues for MicroPico and found this one as well as #281 and #287 which all seem possibly related. Based on #281 I tried reverting from 4.2.1 to 4.1.0 and that allowed me to connect to the QT Py RP2040 as long as I manually specified the serial port. The virtual REPL worked and I could run code and access the filesystem. I then went back to 4.2.1 and confirmed I could no longer connect.

@sfe-SparkFro Are you able to use a SparkFun board with 4.1.0 (with serial port manually specified)?

Regarding the cause:

There aren't that many commits after 4.1.0. It seems like the problem may have been introduced by 7aa0bdb and/or 7640366. The commit message for 7640366 is "Upgrade to pico-mpy-com v1.0.22" but the pico-mpy-com repo on GitHub only goes up to 1.0.21 at the moment (?).

In pico-mpy-com 1.0.21 there is usbIds.ts which looks for specific VIDs and PIDs in a function called isUsbDeviceSupported. Adafruit and SparkFun VIDs are not listed but Pimoroni is. I don't know for sure but it looks like previously this function was only used when running the command to list serial ports and now it's used during the connect process. This would explain why it became impossible after 4.1.0 to connect and use MicroPico with boards that aren't whitelisted here. Hopefully this is an unintended change and the previous behavior of allowing connection to all boards can be restored.

[sfe-SparkFro]

Thanks for looking into this!

I'm not able to observe any difference in behavior between 4.1.0 and 4.2.1. I tried flashing the QT Py RP2040 firmware to a Pico W (I don't have one of those boards on hand, but it's still an RP2040 nevertheless), but 4.1.0 still failed to connect for me.

I also tried using this board with our MicroPython firmware flashed, both 4.1.0 and 4.2.1 fail to connect with the serial port manually specified. If I instead flash the Pico 2 W firmware, then it connects just fine.

Curious why I can't get a successful connection with custom firmware on 4.1.0, but you can. The only settings I changed were disabling Auto Connect and setting Manual Com Device to the COM port that the board enumerated as. I even tried reinstalling the extension, no luck.

[sfe-SparkFro]

I also gave 4.0.6 a try (because of #287), still no luck.

[sooslaca]

To quote @tgrandgent : "I don't know for sure but it looks like previously this function was only used when running the command to list serial ports and now it's used during the connect process"

Yes, this is the problem. Even if I define manualComDevice the VID/PID check is running, so not connecting.

@paulober It would be nice if we set manualComDevice and autoConnect = false then ignore all these checks. Or add another setting to ignore VID/PID checks.

Thank you

[maruta]

@tgrandgent
Thank you for the helpful information.

I'm using an M5Stack ATOM S3R with the UIFlow2 firmware, and the latest version of MicroPico did not work.
For my case, downgrading MicroPico to version 4.1.0 completely solved the issue.

I am also eagerly awaiting a resolution to this issue.