-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Redesign PG loading from EEPROM #2401
Conversation
All parameter groups initialized, either from EEPROM or reset to default. Stored record version is checked, mismatched version is ignored
This should help with #2395. |
@hydra: Is it OK to |
Unittests will be fixed soon |
@ledvinap nice to see some progress on this, cool. there are a few cases that need to be handled:
|
Stored configuration is used when it does exist (correct profile/system +PGN) and version does match
PG is reset when EEPROM record is not found
PG is reset first, than stored data are copied over it.
Record is reset on version mismatch (nothing is copied over default values) Handling of arrays may be improved - pad/trim on per-item basis, then reset remaining items if necessary. But that can go into next PR. Also it will be quite easy to implement PG upgrade mechanism - register function that will chane record to higher version number. Multiple upgrade steps may be performed automatically, oldest supported CF version may be handled by #define, including only upgrade functions that fit available space |
@ledvinap great. so all the cases outlined above are all handled by this PR as-is? |
// true if the config is valid. | ||
bool scanEEPROM(bool andLoad) // FIXME boolean argument. | ||
// Scan the EEPROM config. Returns true if the config is valid. | ||
bool scanEEPROM(void) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to see the boolean parameter gone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
woohoo!
{ | ||
const uint8_t *p = &__config_start; | ||
p += sizeof(configHeader_t); // skip header | ||
while(true) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while (true)
space after while. Similarly for a few if
s in the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I'll fix it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW: find . -type f -exec grep -nH -E '\<(if|switch|for|do|while)[(]' {} +
@hydra : I hope so .. It needs testing, I'll prepare some unittests ... |
remove unnecessary code
if you mean, is it ok to change the prefix of the eeprom functions to have eeprom at the start. yes. but not in this PR please. as @martinbudden metioned recently let's keep larger renames a little more focused. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😄
@ledvinap ready? |
@ledvinap in doing a bit of testing and monitoring the reg->pgn from inside |
ahh wait, never mind, lol, that's the version in the top 4 bits. |
I do note, that after the config is loaded and some settings are reset the config is not immediately saved and the 'upgrade' process is followed on every boot until the config is saved once. I think that's probably acceptable but I'd like your thoughts. |
IMO repeated upgrade is fine. If you downgrade/change version before saving, you get original config back. Can be especially useful if you flash wrong version. |
BTW: It should be quite easy to skip save when config did not change (use code identical to load and compare EEPROM records to PG). |
yeah, not-saving is useful feature actually 😄 nice. |
This PR is not that large, I don't see any problem. But I did not test it on actual hardware. |
Yes I tested it on an SP Racing F3 EVO and went from 1.13.0 to the latest master + this PR. I'll merge it now, we can fix in next RC if something comes up. |
@ledvinap I'm finding if I upgrade from 1.13.0 to master then cli dump fails due to incorrect value of telemetry_send_cells. This needs investigation. |
fixed in #2421. The bug was there before this PR, I totally missed it ... At least new code is a bit nicer ... |
Preparation for conversion to parameter groups 5
All parameter groups initialized, either from EEPROM or reset to
default.
Stored record version is checked, mismatched version is ignored