[Feature] Reserve memory region for persistent system settings.

[laurensvalk]

Is your feature request related to a problem? Please describe.
We have a persistent memory section for user data. We might need one for system settings as well.

We can either reduce the existing user data size, or reduce program size instead.

Taking it out of the user data has the benefit that there is no breaking change for user programs already on SPIKE hubs when they upgrade the firmware. I've also not seen many projects that use large amounts of persistent data anyway.

Persistent data we could consider reserving space for:

• Bluetooth mode (on/off, other). Maybe this can be 1 byte to reserve for future state flags for USB. [Feature] Toggle Bluetooth with Bluetooth button. #1615
• Maybe auto-run on power on, see also https://github.com/orgs/pybricks/discussions/982
• gyro calibration data. Maybe 3*4 bytes. [Feature] User IMU calibration ideas #943
• acceleration calibration data. Maybe 3*4 bytes [Feature] User IMU calibration ideas #943
• system/boot sound (in)active (we don't have such sounds right now) or sound volume https://github.com/orgs/pybricks/discussions/929#discussioncomment-9213209
• Hub name, instead of baking it into the firmware
• recently used remote control name/address/host for [Feature] Remote connection UX #1382

[laurensvalk]

One issue when starting this is that the region could contain any random data to begin with on Spike Hubs. On Technic/Boost/City it is erased on update.

Do we want to clear it on first boot on SPIKE hubs? Should we erase user programs too?

[dlech]

Maybe on those hubs, we could use a magic number or checksum to tell if the persistent data is valid or not.

[afarago]

Could we consider having 3 BT modes?

• BT on open (current)
• BT off
• BT on secure - only connect to last connected MAC (after mode 1)

Though kids are nice it is a disaster if during the competition anyone can connect to your hub when doing the programming / testing part.

(You know the analogy - in the IoT abbreviation the letter "s" stands for security)

[laurensvalk]

Thanks @afarago --- it might be best to add that to #1615

This issue is more about the generics of storing persistent data 🙂

[afarago]

Apologies, I was going to, but accidentally left the wrong ticket open on my phone.
note to myself: never comment on github before the morning coffee.

I will add it there, please feel free to remove my comment(s) from here.

[laurensvalk]

Oh, don't worry! Please keep the comments coming before your morning coffee, those are often the best 😄

[laurensvalk]

I would like to avoid a repeat of #744, so maybe we should just take the space needed for persistent storage out of the user data area.

On the other platforms this shouldn't matter, since all user data gets erased during a firmware update anyway.

[dlech]

On the other platforms this shouldn't matter, since all user data gets erased during a firmware update anyway.

Perhaps we could emulate this on the SPIKE hubs by including a hash of the data plus the firmware version (or a data layout version that only changes when the layout changes, like this proposed change here - this would need to include PBSYS_APP_HUB_FEATURE_FLAGS in the hash too). If the hash is bad, the write over the memory with 0s before reading the first time.

[laurensvalk]

Related / maybe addressable at the same time #1496:

(...) a program is not really able to tell if the contents of the persistent storage are valid for the given program or not, because new programs are possible to install without clearing the storage, which makes it hard to use it safely (...)

[laurensvalk]

The mechanics for this have been implemented. There is just one setting for now, but we can add more with every release since the settings are erased after an update.