pbio/protocol: add slots info to hub capabilities and status

[dlech]

In order to support multiple program slots, connected apps will need to know how many slots are available on the hub and what the currently selected slot is. These are added to the hub capabilities and status report respectively and the Pybricks Profile version is bumped to 1.5.0.

[coveralls]

coverage: 57.162% (+0.02%) from 57.143%
when pulling ed3272d on dlech
into 6fdc7e1 on master.

[github-actions]

Download the artifacts for this pull request:

• pr_number.zip
• mpy-cross.zip
• nxt-firmware-build-3930-gitd0e31e54.zip
• movehub-firmware-build-3930-gitd0e31e54.zip
• ev3-firmware-build-3930-gitd0e31e54.zip
• technichub-firmware-build-3930-gitd0e31e54.zip
• essentialhub-firmware-build-3930-gitd0e31e54.zip
• primehub-firmware-build-3930-gitd0e31e54.zip
• cityhub-firmware-build-3930-gitd0e31e54.zip

[laurensvalk]

Thanks for working on this, this is much appreciated.

To make this fully useful, should we also move pbsys_storage_get_maximum_program_size() from hub capabilities to the status?

This should resolve most of the limitations of this initial slot approach.

(Or we can have a closer look at uploads in general, since memory offsets doesn't quite work anymore in this approach - the current way of handling it is a bit of a hack. But this might take a lot longer to get right).

[dlech]

To make this fully useful, should we also move pbsys_storage_get_maximum_program_size() from hub capabilities to the status?

No, I think this would take too many bytes in the status message for something only changes in response to an external command.

Instead, I think we could consider a new characteristic that we can read to ask "what is in the slots". This would only be present on hubs that support slots. This could return file names and program sizes so we can see the current layout and how much free space is left. And is useful if you haven't used your hub for a while and forgot what was on it.

And I had a shower thought this morning that we probably also want to add a command to allow remotely selecting the slot on the hub UI.

[laurensvalk]

Yeah, it's probably worth brainstorming a bit over 🍵 / ☕ . Would be great if we come up with something that will be generic enough for what we want to do after this, even if we only implement of subset of those ideas for now.

add a command to allow remotely selecting the slot on the hub UI.

And also delete. Could be part of the broader discussion above.

[laurensvalk]

Nice! I think we concluded on our chat last week that this will allow us to do most of what we need for now.

The only problem is that users who install this via Pybricks Beta will have a broken experience with Pybricks Code. Once you select a different slot, programs loaded from Pybricks Code won't appear to start (or a different one will) because it always starts slot 0.

pybricks/pybricks-code#2343 would handle that. So could we perhaps omit the slot payload for hubs running < 1.5.0?

[dlech]

The only problem is that users who install this via Pybricks Beta will have a broken experience with Pybricks Code

Since we are bumping the Pybricks Profile version number, if this happens, Pybricks Code will inform users that the firmware is too new and that some features may no longer work correctly. So I don't think we need to go out of the way to make newer firmware work with older programming tools. We've never supported that scenario in the past.

So could we perhaps omit the slot payload for hubs running < 1.5.0?

Since the hub is telling Pybricks Code how many slots it has, Pybricks Code should already be doing the right thing in this regard. There aren't any officially released firmwares like this that have slots enabled, so it doesn't matter if we send 0 or no argument, IIRC.

[laurensvalk]

We are going to have this firmware in beta for quite a while I think, so this is quite likely to raise some issues. (We could indeed decide to just accept it; I am not sure what's best.)

Since the hub is telling Pybricks Code how many slots it has, Pybricks Code should already be doing the right thing in this regard. There aren't any officially released firmwares like this that have slots enabled, so it doesn't matter if we send 0 or no argument, IIRC.

from pybricks.hubs import PrimeHub
from pybricks.parameters import Color
from pybricks.tools import wait

hub = PrimeHub()
hub.light.on(Color.BLUE) # Put red in first slot, green in second slot, blue in third
wait(5000)

Slots are downloaded to the selected slot, but it always runs 0, so you'd always see red even if the current program tries to make it blue.

[dlech]

Slots are downloaded to the selected slot, but it always runs 0, so you'd always see red even if the current program tries to make it blue.

Right, but this only happens when you are running newer firmware on older Pybricks Code and so will have received the warning message that some things might not work as expected.

[laurensvalk]

OK, yeah let's keep it simple.

[laurensvalk]

I suppose we could even merge and publish pybricks/pybricks-code#2344 relatively soon, well before we even get to a firmware beta. Then nobody should notice.

[laurensvalk]

Have added changelog. Will merge when CI is ready.