mpremote - Filetransfer during repl session

[WolleKette]

When I have established a repl connection to a microcontroller with mpremote in a terminal (macos), is there a way to transfer files without ending the repl session?

Apparently this is not possible. But IDE's like Thonny or VSCode do something like that.

[ricksorensen]

Have you tried mpremote with resume option? https://docs.micropython.org/en/latest/reference/mpremote.html#mpremote-command-resume

resume – maintain existing interpreter state for subsequent commands:

$ mpremote resume
This disables [auto-soft-reset](https://docs.micropython.org/en/latest/reference/mpremote.html#mpremote-reset). This is useful if you want to run a subsequent command on a board without first soft-resetting it.

e.g. mpremote resume cp xxxx.yy :

[WolleKette]

I'm not sure if I understand this correctly.

In one terminal, I use

mpremote or
mpremote connect /dev/cu.usbmodem2303

In a second terminal, I would now like to copy something or, for example, execute ls.

mpremote resume cp ... :

brings the message: failed to access /dev/cu.usbmodem2303 (it may be in use by another program)

[ricksorensen]

mpremote does not allow multiple connetions. Escape mpremote (ctrl-]), then use mpremote resume cp xxxx :.. to execute command without resetting the remote system. Then one can use mpremote resume (with no arguments) to return to the running REPL on the module.

[WolleKette]

Ok. Thank you very much for your explanations. I had already thought that. I only asked again here because I had read something to the contrary somewhere. I was once again looking for an alternative for Thonny in my workflow.

I use PyCharm on MacOS for code development and Thonny for transfer and debugging on the uC. But while mpremote always works, Thonny is pretty bitchy. With esp controllers it still works, but with stm it's terrible. So once again I was hoping for an alternative. ;-)

[Josverl]

The vscode extensions I have been involved with all have their own handrolled serial communication layer that multiplexes repl with the housekeeping and synchronization of files. I'm pretty sure Thonny does this as well.
It's a dicy game and quite hard to get right all the time across all the ports.
Also most serial libraries have some peculiarities in across host platforms.

The there are OS architecture differences, windows only offers exclusive serial port access, while most Linuxes can share, but the standard permissions only allow access to the first three ports, Mac has its own dealings with some of the ports.

I'd love to have a simple solution to this, but alas, reality strikes again

[peterhinch]

Another approach is to use mpremote to mount your PC directory. Then you can keep the REPL open, editing the files on the PC and never copying them to the device's flash.

[dov]

I was about to suggest a similar idea when I encountered this discussion. My idea is to add an escape character within the repl session to run local mpremote commands. Here is what such a session would then look like:

>>> print('hello')  # Normal python
>>> !cp /tmp/hello.py :hello.py  # Run a mpremote command
>>> execfile('hello.py')  # Back in python

My idea was that when encountering an exclamation mark, then the (local) repl session would terminate the remote connection, execute the command, and the reattach (resume).

[Josverl]

@dov
if only it was so simple,
but what would happen to a running application that runs on the MCU ?
as it will need to be stopped/interrupted to do that file transfer, as the filetransfer is actually implemented by running an MicroPython script.
Then restoring that , including the state.

With regards to the suggestion: to allow >>> execfile('hello.py') # Back in python :
Allowing an tool + MCU script to execute arbitrary code on the host is, in my personal , and professional opinion, very very dangerous indeed.
It is something I would never consider installing on any of my machines.

[dov]

Perhaps I didn't explain myself properly. The idea of the escape character is just to simplify the running of mpremote commands when already running a repl session. It is really just a shortcut for doing:

1. Crtl-] to exit mpremote a0 resume
2. Running mpremote a0 command....
3. Run mpremote a0 resume to get back into mpremote

It should only be allowed when the user is already at the '>>>' prompt, so if there is an application on the MCU, you won't be able to run an escape command.

Btw, the execfile('hello.py') example is running on the MCU and not on the host.

I have more or finished implementing this behavior under an emacs comint session, and it is behaving quite nicely, imho.

See: https://gist.github.com/dov/9c97b8b9692fdeac7ce4e62400f8de8d

[Josverl]

so if there is an application on the MCU, you won't be able to run an escape command.

With aiorepl you can have both a repl and a asyncio application running.

But the main point is that with the mpremote mount folder there is simply no need to copy files.
I press the save-chord in any editor of choice, and the (updated) file is 'just there' in '/remote.hello.py'
In some cases I want to restart , then I need 2 keys , Ctrl-S in my editor, and Ctrl-D in my mpremote repl.
Its not perfect , but good enough

But I get what you are trying to do, I have tried to build similar editor integrations together with others in various languages and tools.
I would suggest investing in automated tests with some randomness, cause there are tons of edge cases that I suspect you will find sooner or later.