search

pybricks / support

Pybricks support and general discussion
MIT License
109 stars 7 forks source link

[Feature] Multiple program slot implementation #1790

Closed laurensvalk closed 2 months ago

laurensvalk commented 3 months ago

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 https://github.com/pybricks/pybricks-micropython/pull/264 to generalize to multiple programs. There are also some ideas for the hub UI to start multiple programs in https://github.com/pybricks/support/issues/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.

FLL-Team-24277 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

See also https://github.com/pybricks/pybricks-micropython/commit/85573bfe99f81b4927ff2ea46882b775e2028cb1#r146188713 which needs fixing as part of this.

laurensvalk commented 2 months ago

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 https://github.com/pybricks/pybricks-micropython/pull/266. We can follow up there.