-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
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? |
I agree. I think the upcoming approach will be a good balance of both, without any degradation in speed.
If you want to see the program size, open the console in your browser using You can use |
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.
See also pybricks/pybricks-micropython@85573bf#r146188713 which needs fixing as part of this. |
This approach will be used for now, as done via pybricks/pybricks-micropython#266. We can follow up there. |
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.
The text was updated successfully, but these errors were encountered: