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] Multiple program slot implementation #1790

Closed
laurensvalk opened this issue Aug 29, 2024 · 4 comments
Closed

[Feature] Multiple program slot implementation #1790

laurensvalk opened this issue Aug 29, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request hub: primehub/inventorhub Issues related to the LEGO SPIKE Prime hub and LEGO MINDSTORMS Robot Invetor hub software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime)

Comments

@laurensvalk
Copy link
Member

laurensvalk commented Aug 29, 2024

Having support for multiple programs has been a much requested feature. Users can combine their programs with their own menu already. This is very powerful, but somewhat advanced.

There is some ongoing work in pybricks/pybricks-micropython#264 to generalize to multiple programs. There are also some ideas for the hub UI to start multiple programs in #139.

But saving, loading and starting the programs in a technical sense is a bit of a separate topic. This issue aims to collect some ideas.

Possible first approach

Right now, we don't use a file system. We load a region from external SPI flash that fits in RAM. Everything happens in RAM during runtime. On shutdown, it is saved back that same region in flash. This makes runtime "file operations" instant and keeps everything pretty simple, and equivalent to the hubs without external flash.

We could start off by keeping it that way, and keep 5 variably sized programs consecutively in RAM. If a program needs to be overwritten, all the others get memmove'd to the start of user RAM, and the current program is saved as the last one. Since the user is mostly debugging and experimenting with one program at the time, everything is going to be as quick as it is today. memmove is only needed the first time a user downloads a new program after changing the slot.

The main downside is that the sum of all 5 programs is still limited to 256 KB. On the other hand, I don't recall anyone mentioning hitting the limit, not even with multi-file menu programs. So maybe it's OK to start this way.

Use N chunks of flash

We could do the above, but save/load a new 256 KB region when you change the slot. Although if we go this far, we should instead probably do the following instead.

Use a file system on SPI flash

Now that SPIKE V3 is properly settled and nobody should be using V2 anymore, we could potentially start using a real file system, or even the standard SPIKEV3 file system.

We can potentially do this later without changing anything in the UI.

@laurensvalk laurensvalk added enhancement New feature or request hub: primehub/inventorhub Issues related to the LEGO SPIKE Prime hub and LEGO MINDSTORMS Robot Invetor hub software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime) labels Aug 29, 2024
@FLL-Team-24277
Copy link

We are very comfortable with the single program as it currently works, and we love the speed with bootup and stopping and restarting programs. We very much would not want to see any degradation there. But I do see how many teams would prefer to have an easy way to store/launch multiple programs. Maybe it could be a flash option when loading pybricks onto the firmware?

Is there an easy way to see how much memory our current programs are taking?

@laurensvalk
Copy link
Member Author

We are very comfortable with the single program as it currently works, and we love the speed with bootup and stopping and restarting programs. We very much would not want to see any degradation there.

I agree. I think the upcoming approach will be a good balance of both, without any degradation in speed.

Is there an easy way to see how much memory our current programs are taking?

If you want to see the program size, open the console in your browser using ctrl shift i. When you run a program, it prints the size here.

You can use mem_info to get information about free RAM.

laurensvalk referenced this issue in pybricks/pybricks-micropython Sep 3, 2024
We were using a separate "header" type with a known size so the program size could be a fixed remainder. But it isn't really a header since it contains user data, and soon also persistent system data.

We can accomplish the same statically allocated size by making the map (with unknown size program_data[] at the end) a union with the size of the writable block device.
@laurensvalk
Copy link
Member Author

See also pybricks/pybricks-micropython@85573bf#r146188713 which needs fixing as part of this.

@laurensvalk
Copy link
Member Author

We could start off by keeping it that way, and keep 5 variably sized programs consecutively in RAM.

This approach will be used for now, as done via pybricks/pybricks-micropython#266. We can follow up there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request hub: primehub/inventorhub Issues related to the LEGO SPIKE Prime hub and LEGO MINDSTORMS Robot Invetor hub software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime)
Projects
None yet
Development

No branches or pull requests

2 participants