Firmware with USB MSC support?

[dschwert]

Hi!

Is there a firmware for download with `MICROPY_HW_USB_MSC` enabled?

Even though concurrent flash memory access from PC and Micropython has it's problems, it's still a great selling point being able to 'flash' software without programmer.

Regards,
Dietmar

[jimmo]

Is there a firmware for download with `MICROPY_HW_USB_MSC` enabled?

Not as a pre-built image, although if there's interest it's definitely something we could do. (Like you've pointed out, it's just a configuration option, so we could do this similar to how we provide build variants for e.g. pyboard with threading/networking/double-fp/etc)

Here's a thread with more details: https://github.com/micropython/micropyt ... 1048777491

Even though concurrent flash memory access from PC and Micropython has it's problems, it's still a great selling point being able to 'flash' software without programmer.

It's true that it's a very neat feature, but my experience is that for all but the simplest of projects it's just a source of trouble and confusion.

It also prevents us from using the far superior LittleFS filesystem (as to support USB MSC we need to use FAT instead).

I use mpremote (https://docs.micropython.org/en/latest/ ... emote.html) which provides an overall much better workflow. In particular the "mount" feature avoids even needing to think about copying files.

[Roberthh]

USB MSC support is enabled by default for rp2 boards only for Arduino nano connect 2040. And there is a PR open to prevent file corruption by enforcing exclusive access. So at least it will be reliable then, but using mpremote is easier.
About Littlefs and MSC: there is a fuse FS driver for Linux allowing to mount a board with a littlefs file system. Still, there is the concurrent access trap to be avoided.

[dschwert]

Not as a pre-built image, although if there's interest it's definitely something we could do.

That would be great. I don't know how big the demand is, though.

For sure the alternatives are preferable for people who work with MicroPython every day. For the casual user MSC is the easiest and often it's nice to have two communication channels (REPL and a mainloop are mutually exclusive).
Also, with MSC I can tell someone on the phone how to replace an program a defective board.

Regards,
Dietmar

[Roberthh]

MicroPython is not a multitasking operating system, and MSC is not a server file sharing protocol. While MSC is enabled, code on the board must not write to the board's file system. Otherwise trouble is for sure.

[hippy]

It's true that it's a very neat feature, but my experience is that for all but the simplest of projects it's just a source of trouble and confusion.

It also prevents us from using the far superior LittleFS filesystem (as to support USB MSC we need to use FAT instead).

I would second that. My approach has been to keep the MicroPython file system wholly internal, and create an additional MSC disk which can be exposed via USB.

That's a work in progress but seems to function as expected. One might have two MSC devices, one to be written by a PC or host, the other read-only. That might help alleviate some of the problems when both sides may be updating a shared file system.

[jimmo]

I would second that. My approach has been to keep the MicroPython file system wholly internal, and create an additional MSC disk which can be exposed via USB

Yes this is exactly the sort of scenario that the second-last paragraph of https://github.com/micropython/micropyt ... 1048777491 is about that we'd like to move towards. Have a primary LittleFS partition "owned" by the device, and another FAT one "owned" by USB that the code can only mount when USB isn't using it.