[Feature] Reserve memory region for persistent system settings.
laurensvalk opened this issue · comments
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. #1615
- Maybe auto-run on power on, see also https://github.com/orgs/pybricks/discussions/982
- gyro calibration data. Maybe 3*4 bytes. #943
- acceleration calibration data. Maybe 3*4 bytes #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 #1382
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?
Maybe on those hubs, we could use a magic number or checksum to tell if the persistent data is valid or not.
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)
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.
Oh, don't worry! Please keep the comments coming before your morning coffee, those are often the best 😄
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.
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.
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 (...)
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.