Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Remotely starting a stored program with pybricksdev #284

Closed
Novakasa opened this issue Mar 27, 2021 · 6 comments
Closed

[Feature] Remotely starting a stored program with pybricksdev #284

Novakasa opened this issue Mar 27, 2021 · 6 comments
Labels
enhancement New feature or request software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime) software: pybricksdev Issues related to the pybrickdev Python package

Comments

@Novakasa
Copy link

Novakasa commented Mar 27, 2021

Is your feature request related to a problem? Please describe.
I am incorporating multiple PoweredUp Hubs in a larger project which is controlled centrally on a PC using pybricksdev. When running it, I have to run BLEPUPConnection.run() for each Hub, which for me takes about 10 seconds (see #283). Given that we have the possibility to store a program on the hub permanently, it would be a nice feature to be able to start that program remotely using pybricksdev, so the program will not have to be copied to the hub every time I am testing my larger project. Even when #283 is addressed, each download and run operation takes about 2-3 seconds for me even with Pybricks Code, so I still think that this would be a useful addition to pybricksdev especially if you are using scripts of large sizes, which might take a bit longer to copy still.

Describe the solution you'd like
I can imagine adjusting the API by seperating copying and starting a program like so:

hub = BLEPUPConnection()
await hub.connect(my_address)
await hub.copy_script("my_script.py")
await hub.run_script("my_script.py")

And this should also work when ommitting copy_script when a program was already stored permanently when flashing the firmware.
If there might ever be the possiblity of storing multiple scripts on the hub, one could introduce a separate name parameter for copy_script and run_script so the scripts can be identified.

@Novakasa Novakasa added enhancement New feature or request triage Issues that have not been triaged yet labels Mar 27, 2021
@Novakasa Novakasa changed the title [Feature] Remotely starting a stored program [Feature] Remotely starting a stored program with pybricksdev Mar 27, 2021
@dlech dlech added software: pybricksdev Issues related to the pybrickdev Python package and removed triage Issues that have not been triaged yet labels Mar 27, 2021
@dlech dlech added the software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime) label May 20, 2021
@laurensvalk
Copy link
Member

laurensvalk commented Jul 30, 2021

It would be a nice feature to be able to start that program remotely using pybricksdev, so the program will not have to be copied to the hub every time I am testing my larger project.

Although seemingly unrelated, this would be solved by #408, by running a script that just does import main.

And this is perhaps even more useful than a special start command, since you'd be completely flexible in passing additional commands. You could upload the same main.py to all trains, and then start each with its own parameters as needed:

from main import SmartTrain

train = SmartTrain(param1, param2)
train.start()

@laurensvalk
Copy link
Member

This is now theoretically possible with pybricks/pybricks-micropython#109 and subsequent PRs. Sending program size 0 is the same as pressing the button.

Although it might be nicer to make a command for it just like we have the stop command. Then we can get rid of the special size to trigger the REPL as well.

@Novakasa
Copy link
Author

Novakasa commented Apr 3, 2023

This is now theoretically possible with pybricks/pybricks-micropython#109 and subsequent PRs. Sending program size 0 is the same as pressing the button.

Could that currently work using pybricksdev?

@dlech
Copy link
Member

dlech commented Apr 3, 2023

Although it might be nicer to make a command for it just like we have the stop command. Then we can get rid of the special size to trigger the REPL as well.

This has been done in the firmware, so it is possible now. There just isn't a high-level API for it in pybricksdev. It should be easy enough to split the download and run function into two functions.

@Novakasa
Copy link
Author

Novakasa commented Apr 4, 2023

Oh yeah, I see it now, I have no idea why I missed this earlier

@Novakasa
Copy link
Author

Novakasa commented Apr 28, 2023

If I understand correctly, the new function start_user_program indeed does what is requested here, however it seems that it doesn't really replace the old run function, since a lot of setup and state management for stdin, stdout, logfiles, etc still is only done in run (which always redownloads the program. Is start_user_program supposed to be called in isolation?

For me, the ideal API would be to have run but just have the download be optional.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime) software: pybricksdev Issues related to the pybrickdev Python package
Projects
None yet
Development

No branches or pull requests

3 participants