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

Implement persistent state #201

Open
2 of 3 tasks
PatrickKa opened this issue Dec 16, 2023 · 6 comments
Open
2 of 3 tasks

Implement persistent state #201

PatrickKa opened this issue Dec 16, 2023 · 6 comments

Comments

@PatrickKa
Copy link
Contributor

PatrickKa commented Dec 16, 2023

Description

The persistent state contains data for the bootloader, data of the current state of the COBC, housekeeping data as well as the EDU program status history and the EDU program queue. I totally forgot about the last two. We already have them implemented but only in RAM. I am not sure how to best move them to the FRAM. Either we only have them in the FRAM and load every time from there. Or we cache them in RAM and load periodically and/or when writing.

Regarding the rest, that is just a few variables that need hardly any space and should therefore be quick to read and write. Since they do contain very important things like the activeFirmwareImage I want to employ a self-healing mechanism for them (store three times, compare and eliminate difference on read). This should get its own abstraction called PersistentVariable.

To do

@PatrickKa
Copy link
Contributor Author

Blocked by #185 and #192

@PatrickKa
Copy link
Contributor Author

Also blocked by #207 because we need tests.

@PatrickKa
Copy link
Contributor Author

PatrickKa commented Dec 23, 2023

I think it would be good if we employed some form of error detection and correction (EDAC) for the persistent state. The most simple to implement is probably triple modular redundancy, but this has a memory overhead of 200 %. The persistent state is not very large, however, if we want to use the same EDAC method also for the telemetry memory, then this is not feasible. Hamming or Reed–Solomon codes are better in regard to overhead, but there are lots of other options to choose from.

I created issue #239 for this and added it to this epic.

@PatrickKa
Copy link
Contributor Author

I unblocked this Epic because the newly added #239 can already be worked on.

@PatrickKa
Copy link
Contributor Author

I removed #239 from this epic since it is also related to the telemetry memory (#179) and should therefore be a standalone issue which blocks this one, so:

Blocked by #239

@PatrickKa
Copy link
Contributor Author

No longer blocked by #239 since we will not implement it for everything in the persistent state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant