Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #24818
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: What is your strategy to save non volatile data? |
| Date | 2016-08-12 00:17 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <noithu$8fa$2@dont-email.me> (permalink) |
| References | <nohs7p$ff3$1@dont-email.me> <noi142$ih$1@dont-email.me> <noi3gv$8qc$1@dont-email.me> <noipdo$nnv$1@dont-email.me> |
Il 11/08/2016 23:07, David Brown ha scritto:
> On 11/08/16 16:53, Don Y wrote:
>> On 8/11/2016 7:12 AM, David Brown wrote:
>>
>>> But for the common case of storing a small set of parameters, I usually
>>> work with a struct definition. Along with the parameters in
question, I
>>> include a "magic number" for identification, a "parameter structure
>>> version number" (very useful for upgrading the parameter set if a later
>>> version of the firmware uses more parameters), an update serial number,
>>> a CRC check field, and some space reserved for future additional
>>> parameters.
>>
>> To be clear, you are wrapping *all* of your parameters into a single
>> "parameters_to_be_saved" struct.
>>
>> This can work if they are "configuration parameters" -- data that are
>> consulted when setting up the application, restarting it, etc.
>
> Yes, exactly. I find this to be quite a common situation - but we all
> agree that different systems have different requirements and therefore
> different "best" solutions.
>
>>
>> This is different than trying to "save application/process state"
>> across power outages. In that case, the "state" may be scattered
>> through many variables dispersed in memory. And, more difficult to
>> ensure catching a "consistent" snapshot.
>>
>> I.e., if *this* variable is changed, are there any others whose state
>> must be reconciled *as* it is being preserved?
>
> Usually in such cases, it is still easy enough to have everything in one
> structure. At its simplest, all those different state variables
> scattered around the program can be fields of the one state struct.
"Everything in one structure" means you have a global (as the scope in
C) struct definition that is accessed by every piece of code in the
project, even if they are very different section of the project.
In the past I used this approach with a global struct container:
/* In one .h file */
struct settings_s {
uint8_t backlight_level;
enum DisplayTheme theme;
uint16_t psu_output_voltage_calibration;
char password[7];
...
};
extern struct settings_s settings;
/* In one .c file */
struct settings_s settings;
/* In display module */
backligh_set(settings.backlight_level);
Every module that manages one or more persistent parameters should know
the presence of a global settings variable with an exposed type
definition (struct settings_s).
I think this is a bad approach that increase the coupling between
modules instead of decreasing it as it should be.
>> [It's unclear what the OP is addressing]
>
> Indeed.
Mainly I'm interested in saving configuration parameters/settings (color
theme, calibration data, backlight level, and so on).
They are parameters that are changed by the user not so frequent.
>>> Typically I have a statically allocated struct in ram, and two
copies in
>>> eeprom or flash. On startup, I check both non-volatile copies to see
>>> which is the latest version (highest serial number) that has a valid
>>> CRC, and copy that into RAM. If the parameter structure version number
>>> does not match the current firmware requirements, I upgrade the
>>> parameters.
>>
>> I've used a circular buffer into which "tagged" parameters are placed.
>> On restart, I "play back" the buffer to restore the latest versions of
>> the parameters encountered, there. This lets me mix snapshots and
>> incremental updates in the same mechanism.
>
> I've done something like that too (that's sort of what I meant be a log
> structure - though I didn't describe it in detail). It worked well for
> a flash based system - once one sector is getting a bit full, I ran a
> garbage collection pass by running through the buffer copying the latest
> parameters into a new sector, and then erased the old buffer with the
> outdated values.
>
>>
>> My current application is effectively a hybrid approach as I'm
>> effectively restoring "application state" and not "configuration data"
>> (as the system can be considered to be constantly in a state of
>> reconfiguration). So, I let the RDBMS do the "log playback" from
>> its WAL.
>>
>> In that way, I don't have to micromanage "what's important" *in*
>> the application(s) but, rather, leave that to the RDBMS.
>>
>> ("Is this datum something that should be preserved across reboots?")
>
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
What is your strategy to save non volatile data? pozz <pozzugno@gmail.com> - 2016-08-11 14:48 +0200
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-11 06:27 -0700
Re: What is your strategy to save non volatile data? David Brown <david.brown@hesbynett.no> - 2016-08-11 16:12 +0200
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-11 07:53 -0700
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-11 08:27 -0700
Re: What is your strategy to save non volatile data? bitrex <bitrex@de.lete.earthlink.net> - 2016-08-11 12:11 -0400
Re: What is your strategy to save non volatile data? bitrex <bitrex@de.lete.earthlink.net> - 2016-08-11 12:12 -0400
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-11 11:35 -0700
Re: What is your strategy to save non volatile data? bitrex <bitrex@de.lete.earthlink.net> - 2016-08-11 20:59 -0400
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-11 11:33 -0700
Re: What is your strategy to save non volatile data? pozz <pozzugno@gmail.com> - 2016-08-12 00:21 +0200
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-11 15:40 -0700
Re: What is your strategy to save non volatile data? David Brown <david.brown@hesbynett.no> - 2016-08-11 23:07 +0200
Re: What is your strategy to save non volatile data? pozz <pozzugno@gmail.com> - 2016-08-12 00:17 +0200
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-11 15:30 -0700
Re: What is your strategy to save non volatile data? pozz <pozzugno@gmail.com> - 2016-08-12 09:02 +0200
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-12 09:29 -0700
Re: What is your strategy to save non volatile data? David Brown <david.brown@hesbynett.no> - 2016-08-12 11:54 +0200
Re: What is your strategy to save non volatile data? John Devereux <john@devereux.me.uk> - 2016-08-12 13:14 +0100
Re: What is your strategy to save non volatile data? David Brown <david.brown@hesbynett.no> - 2016-08-12 15:22 +0200
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-12 09:40 -0700
Re: What is your strategy to save non volatile data? David Brown <david.brown@hesbynett.no> - 2016-08-12 22:40 +0200
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-13 09:44 -0700
Re: What is your strategy to save non volatile data? David Brown <david.brown@hesbynett.no> - 2016-08-14 23:01 +0200
Re: What is your strategy to save non volatile data? David Brown <david.brown@hesbynett.no> - 2016-08-12 09:52 +0200
Re: What is your strategy to save non volatile data? pozz <pozzugno@gmail.com> - 2016-08-12 16:30 +0200
Re: What is your strategy to save non volatile data? David Brown <david.brown@hesbynett.no> - 2016-08-12 17:09 +0200
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-11 15:36 -0700
Re: What is your strategy to save non volatile data? Paul <paul@pcserviceselectronics.co.uk> - 2016-08-12 03:21 +0100
Re: What is your strategy to save non volatile data? bitrex <bitrex@de.lete.earthlink.net> - 2016-08-11 12:19 -0400
Re: What is your strategy to save non volatile data? pozz <pozzugno@gmail.com> - 2016-08-11 23:49 +0200
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-11 15:37 -0700
Re: What is your strategy to save non volatile data? John Devereux <john@devereux.me.uk> - 2016-08-11 20:50 +0100
Re: What is your strategy to save non volatile data? pozz <pozzugno@gmail.com> - 2016-08-12 00:16 +0200
Re: What is your strategy to save non volatile data? Paul <paul@pcserviceselectronics.co.uk> - 2016-08-12 03:34 +0100
Re: What is your strategy to save non volatile data? David Brown <david.brown@hesbynett.no> - 2016-08-12 11:59 +0200
Re: What is your strategy to save non volatile data? Paul Rubin <no.email@nospam.invalid> - 2016-08-11 11:29 -0700
Re: What is your strategy to save non volatile data? Les Cargill <lcargill99@comcast.com> - 2016-08-12 12:15 -0500
Re: What is your strategy to save non volatile data? Joe Chisolm <jchisolm6@earthlink.net> - 2016-08-12 12:10 -0500
Re: What is your strategy to save non volatile data? Paul <paul@pcserviceselectronics.co.uk> - 2016-08-12 22:00 +0100
Re: What is your strategy to save non volatile data? Tim Wescott <tim@seemywebsite.com> - 2016-08-13 12:06 -0500
Re: What is your strategy to save non volatile data? pozz <pozzugno@gmail.com> - 2016-08-13 23:42 +0200
Re: What is your strategy to save non volatile data? Don Y <blockedofcourse@foo.invalid> - 2016-08-13 15:55 -0700
Re: What is your strategy to save non volatile data? Paul <paul@pcserviceselectronics.co.uk> - 2016-08-14 00:08 +0100
Re: What is your strategy to save non volatile data? Tim Wescott <tim@seemywebsite.com> - 2016-08-13 19:06 -0500
Re: What is your strategy to save non volatile data? pozz <pozzugno@gmail.com> - 2016-08-22 09:46 +0200
csiph-web