Skip to content
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

Merged
merged 4 commits into from
Sep 15, 2016

Conversation

ledvinap
Copy link
Contributor

All parameter groups initialized, either from EEPROM or reset to
default.
Stored record version is checked, mismatched version is ignored

All parameter groups  initialized, either from EEPROM or reset to
default.
Stored record version is checked, mismatched version is ignored
@ledvinap
Copy link
Contributor Author

This should help with #2395.
Review/comments are welcome, but the code is not yet ready for merge. I'll force-push new version, don't base new work on this PR

@ledvinap
Copy link
Contributor Author

@hydra: Is it OK to config_eeprom.c functions to start with EEPROM?

@ledvinap
Copy link
Contributor Author

Unittests will be fixed soon

@hydra
Copy link
Contributor

hydra commented Sep 14, 2016

@ledvinap nice to see some progress on this, cool.

there are a few cases that need to be handled:

  1. load existing pg
  2. initialise pg's that cannot be found
  3. load pg with matching version that has NEW fields at the end of the record - the new fields must be reset to defaults - size mismatch.
  4. re-initialise pg's the have a version mismatch.

@hydra hydra changed the title Redesign PG loaging from EEPROM Redesign PG loading from EEPROM Sep 14, 2016
@hydra hydra added this to the 1.14.0 milestone Sep 14, 2016
@hydra hydra added the Critical label Sep 14, 2016
@ledvinap
Copy link
Contributor Author

  1. load existing pg

Stored configuration is used when it does exist (correct profile/system +PGN) and version does match

  1. initialise pg's that cannot be found

PG is reset when EEPROM record is not found

  1. load pg with matching version that has NEW fields at the end of the record - the new fields must be reset to defaults - size mismatch.

PG is reset first, than stored data are copied over it.

  1. re-initialise pg's the have a version mismatch.

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

@hydra
Copy link
Contributor

hydra commented Sep 14, 2016

@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)
Copy link
Contributor

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.

Copy link
Contributor

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) {
Copy link
Contributor

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 ifs in the code.

Copy link
Contributor Author

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

Copy link
Contributor Author

@ledvinap ledvinap Sep 15, 2016

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)[(]' {} +

@ledvinap
Copy link
Contributor Author

@hydra : I hope so .. It needs testing, I'll prepare some unittests ...

remove unnecessary code
@hydra
Copy link
Contributor

hydra commented Sep 15, 2016

@hydra: Is it OK to config_eeprom.c functions to start with EEPROM?

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.

Copy link
Contributor

@hydra hydra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😄

@hydra
Copy link
Contributor

hydra commented Sep 15, 2016

@ledvinap ready?

@hydra
Copy link
Contributor

hydra commented Sep 15, 2016

@ledvinap in doing a bit of testing and monitoring the reg->pgn from inside pgLoad I noticed unexpected values, such as 4123 and 4107. I had basically flashed the 1.13.0 binary, let it boot and then upgraded the firmware to master via SWD to see what what was being reset and what wasn't when i noticed these unexpected values.

@hydra
Copy link
Contributor

hydra commented Sep 15, 2016

ahh wait, never mind, lol, that's the version in the top 4 bits.

@hydra
Copy link
Contributor

hydra commented Sep 15, 2016

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.

@ledvinap
Copy link
Contributor Author

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.
If config upgrade using intermediate versions is desired, you can save explicitly.

@ledvinap
Copy link
Contributor Author

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).

@hydra
Copy link
Contributor

hydra commented Sep 15, 2016

yeah, not-saving is useful feature actually 😄

nice.

@ledvinap
Copy link
Contributor Author

This PR is not that large, I don't see any problem. But I did not test it on actual hardware.
If you tested it on HW (any board should do), is should be safe to merge.,

@hydra
Copy link
Contributor

hydra commented Sep 15, 2016

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.

@hydra hydra merged commit 3d36914 into cleanflight:master Sep 15, 2016
@hydra
Copy link
Contributor

hydra commented Sep 21, 2016

@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.

@ledvinap
Copy link
Contributor Author

fixed in #2421. The bug was there before this PR, I totally missed it ... At least new code is a bit nicer ...

@ledvinap ledvinap deleted the improvement-pg-reset branch September 22, 2016 09:21
martinbudden added a commit to martinbudden/cleanflight that referenced this pull request Feb 16, 2017
Preparation for conversion to parameter groups 5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants