probe-rs over TCP

[ismell]

Hello,
I was wondering if probe-rs/probe-run/cargo-embed has a way to do remote development? i.e., build code on my laptop, and connect to a remote probe-rs endpoint over TCP so I can flash/debug? OpenOCD supports this by starting a TCP server that I can then connect to via GDB using the target remote command. Does probe-rs support something similar? I have my raspberry pico debugger connected to a raspberry pi 4. I would rather edit/compile on my laptop since it's a lot faster.

Thanks!

[noppej]

With probe-rs-debugger, you can launch a server, and then connect to it with the VSCode extension, to compile/debug/test. I use this all the time between my Mac laptop, and Mac desktop, but have never tried it with the server running on Pi. Let me know if you get it to work :)

[noppej]

Instead of having to manually set up a tunnel to get around the 127.0.0.1 bind, I could instead configure VSCode to use a launch type request.

VSCode uses terminology that is ambiguous in the embedded world. If you read the spec you will see that the term launch refers to the debuggee (target application) and not to the debug adapter server. In our extension, VSCode will spawn the debug adapter server, irrespective of whether you choose to launch or attach to the debuggee.

[noppej]

I changed the executable to ~/bin/probe-rs-debugger-ssh:

Using the launch.json property of runTimeExecutable is a nice clean way to do it. There is also a launch.json property for runTimeArgs that you can use to pass arguments to it.

As you've already discovered in ...

One other thing I noticed is that the debugger executable doesn't get killed by the extension if it fails:

... you are mimicking a situation where VSCode spawns the debug server. In this case, the debug server will only terminate itself once the VSCode debug session ends. In your case, because of the error, VSCode never starts the session and so the server is hanging around waiting for 'start session ... do stuff ... end session' before it exits itself.

In theory we can detect this situation, and send an os signal to kill the process ... PR's welcome :)

[noppej]

One option to fix this is to have the extension read probe-rs-debugger's stdout looking for the probe-rs-debug: Listening for requests on port <port> message instead

Until recently, this is exactly how it worked, and we changed it because checking the port was deemed more elegant. I actually think your suggestion of looping a few (finite) times to retry, is not a bad alternative ... PR's welcome :)

[noppej]

I think the harder problem to solve is how to cleanly get the target bin over to the probe-rs-debugger server so that it can flash it.

Any alternative (to your scp solution) ideas on doing that?

[radnvlad]

So I built probe-rs with std::net::IpAddr::V4(Ipv4Addr::UNSPECIFIED) and then I indeed can connect and debug.

Problem is... vscode tries then to use the file as if it's open on the remote server and not locally in vscode,

2nd thing is... probe.rs kind of expects it to have the .elf availabe to it locally, what I specify with "programBinary" needs to be on server (is that necessary?)

Do you think a PR would be useful to have this as a option,even the UNSPECIFIED one would help, else I can just run my own built binary locally, no problem.