Reason I'm asking is, me and a friend are working on a fork to the firmware that requires the ability to turn new features on and off. Normally one would add booleans to the SplitSettings struct or the DeviceSettings struct. But that causes a problem. When someone uploads our fork, because the size of the settings data has been increased, it's rejected as corrupt and all the user settings get erased, including calibration data. Rather inconvenient.
This happens even when putting the 2.3.3 updater and our .bin file on the desktop as Roger recommends.
The short-term solution I came up with is to shorten one of the audience messages by 8-10 bytes and to use those bytes to store user settings. Horribly kludgey I know, but it does work. No erasing. But it could possibly inconvenience someone who just loves audience messages and uses all 16 of them.
So... does anyone do that?
One long-term solution for the erasing issue is to have the next official firmware update add to the DeviceSettings struct a large "reservedForFutureUse" array of bytes. The code would completely ignore this array, except to back it up to flash storage like all the other user settings. Then forkers could declare variables and/or arrays that overlap the reserved array and use them in their code. I asked Roger about this and he said he'd consult with Geert about it.
Another solution is to modify ls_extstorage.ino and add variables there. But my understanding is, if someone wants to go from our fork back to the official firmware, all the user settings get erased. This wouldn't happen with the other two methods.
This happens even when putting the 2.3.3 updater and our .bin file on the desktop as Roger recommends.
The short-term solution I came up with is to shorten one of the audience messages by 8-10 bytes and to use those bytes to store user settings. Horribly kludgey I know, but it does work. No erasing. But it could possibly inconvenience someone who just loves audience messages and uses all 16 of them.
So... does anyone do that?
One long-term solution for the erasing issue is to have the next official firmware update add to the DeviceSettings struct a large "reservedForFutureUse" array of bytes. The code would completely ignore this array, except to back it up to flash storage like all the other user settings. Then forkers could declare variables and/or arrays that overlap the reserved array and use them in their code. I asked Roger about this and he said he'd consult with Geert about it.
Another solution is to modify ls_extstorage.ino and add variables there. But my understanding is, if someone wants to go from our fork back to the official firmware, all the user settings get erased. This wouldn't happen with the other two methods.
Statistics: Posted by TallKite — Sun Jan 28, 2024 4:23 am — Replies 1 — Views 34
