Egg vs Hen (or about PC-to-Theremin interaction)

I am developing a Windows application for adjustment/customization a digital theremin and a bit puzzled by
some aspect.

As well known, the modern devices store their settings in FLASH memory which has limited writing cycles
(about 10000). So the suitable scenario is to write all the edited parameters once, at the end of session (not on every changing).

Concerning the theremin this means that the user makes all the desirable tunings/adjustments and finally
pushes the "Save" button in application (or will be prompted on application exit).

This scenario works well when the communication and power are ok. But unexpected user's actions like
physical disconnecting, powering off, etc. will cause that the new setting will be lost. Fortunately the application (while not closed) stores the last values and can restore them when the theremin will be powered again. 

The question is: what is a best scenario on new connection/powering?

1-st: application reads old (unchanged) parameters from theremin.
Minus: The result of previous tuning will be broken.
Advantages: It is intuitively clear (?) and easy to implement.

2-nd: application keeps current parameters and continues use them on new connection.
Plus: It's useful, say, on power drops.
Disadvantage: Huge data array which is sent to theremin every time when reconnected.

There is also a 3-rd way, to ask every time what to do further (whether to use old parameters or continue
with new) but users will be puzzled, I'm afraid.

Any thoughts are appreciated.

Instead of Flash, why not use a tiny serial EEPROM for user settings?  Write/erase cycles two orders of magnitude greater means you can save on every change.  They are inexpensive and made exactly for this kind of thing.

Also: flash data retention time is reduced every time you write to it.

"Instead of Flash, why not use a tiny serial EEPROM"

Just for elegance. Full functionality on single chip (excluding VC amplifier).

3 pins and $1?  I think Flash writes should be limited to firmware updates and the like, not presets so much.  Though I have seen systems where embedded Linux treats Flash like a hard drive (eek!).

It seems like you are making something like a MIDI editor / librarian?  And the Theremin will have preset slots?

Or is this more of a factory tuning tool that will be used infrequently to set operating points, temperature compensation curves, and the like?  That stuff could go in Flash I suppose.

Putting settings in EEPROM lets them survive a firmware update, which is good/bad.  Good if the new load uses the same settings in the same locations, bad otherwise.  Putting settings in Flash places you at risk of overwriting firmware when saving settings (bricking).

"There is also a 3-rd way, to ask every time what to do further (whether to use old parameters or continue with new) but users will be puzzled, I'm afraid." - Ilya

If the saving process gets confirmation that the data has been downloaded ok, could this not be saved as a flag somewhere.. then, next time connection is established, the librarian or whatever would be able to read this flag..

As in, the application keeps the data, and clear the flag at start of download, set the flag when download is verified.. If flag is ever found to be clear, one knows download has been interupted and then initiates repeat  downloading of the data.

The "flag" could even be more sophisticated - a checksum perhaps. I certainly wouldnt give the user the choice - perhaps enable advanced users to access this option if they specifically choose to, but otherwise the user should, IMO, not be aware of the processes.

I agree with Dewster on this matter though , the use of flash for this sort of function fills me with horror! - IMO, there are times its borderline ok for infrequently changed parameters updated on the instrument - but IMO as soon as one allows external interface to alter data / parameters, writing to flash is too risky.

Fred.

"...And the Theremin will have preset slots? Or is this more of a factory tuning tool..." -- dewster

Both of.

"Putting settings in Flash places you at risk of overwriting firmware when saving settings (bricking)."  -- dewster
"writing to flash is too risky"  -- FredM

That is absolutely safe because FLASH has the paged structure and each page can be erased/written separately. And vice versa, the paged organization allows settings survive firmware update. 

 "otherwise the user should, IMO, not be aware of the processes" -- FredM

100% agree so the scenario 3 is disliked me.

I have already provided the flag on power reset so I can recognize a reason of disconnect. If power was ok, I can assume that content of theremin and application is the same and nothing is required. 

"If the saving process gets confirmation" -- FredM

Fred, I worry not about data integrity but about data synchronization.

"That is absolutely safe because FLASH has the paged structure and each page can be erased/written separately." - Ilya

Its entirely in the hands of the designer / developer to decide what they deem "safe" or "unsafe" WRT to flash (or other matters)

All I know is that this issue came up at a design meeting for an electric wheel-chair, and the one developer there who proposed storing user data in flash was rounded on by the other 4 developers - and as the hardware engineer I was left to add the required EEPROM ;-)

There was a strong feeling that even though paged, Flash was not nearly safe enough for that application...

I dont know! - its not my area, I simply passed on what I heard and believed to be true... Perhaps in less critical applications than what I (or probably Dewster) have been used to, its safe enough... I am reasonably certain though that it cannot be "absolutely safe" - just as even writing to EEPROM cannot be "absolutely safe".. and I suspect it comes down to flashing being less safe than EEPROM.

"Fred, I worry not about data integrity but about data synchronization."

I understand this - which is why I suggest a "flag" which is cleared when data transfer starts, and set when data transfer has completed, and for this flag to be in the remote device and not in the PC application..

There are all sorts of ways loss of synchronisation can occur - PC power down or other system problem, cable dissconection, remote device power-down... This is why I suggest a check-sum.. One can read this from the remote, compare it to that held in the app, if they are the same then fine.. If the remote returns an error flag, then you dump the apps last data to it.. If the remotes flag says data is ok, but checksums dont tally, then either upload the remote's data or download the apps data - defaulting to using the data (either in the remote or app) that is least likely to have been corrupted.. With a PC, this is probably going to be the data in the remote...

But in all cases the best route is always application specific - only you know the full system and only you can calculate the failure probabilities and derive the optimum solution.

Fred.