Re: Serial EEPROM or Serial Flash?

Subject	Re: Serial EEPROM or Serial Flash?
Newsgroups	comp.arch.embedded
References	(2 earlier) <pfvqei$9t7$1@dont-email.me> <pg00mh$cmj$1@dont-email.me> <pg0ds2$sal$1@dont-email.me> <pg0i0n$nlr$1@dont-email.me> <pg3jta$8oa$1@dont-email.me>
From	Richard Damon <Richard@Damon-Family.org>
Message-ID	<o2AVC.208842$mS3.44599@fx04.iad> (permalink)
Organization	Forte - www.forteinc.com
Date	2018-06-17 17:05 -0400

Show all headers | View raw

On 6/16/18 2:12 PM, pozz wrote:
> 
> 
> Third question, more complex (for me).
> Suppose I decided to split non-volatile data in two blocks, for example
> calibration data and user settings.
> What happens if user settings change when calibration settings are being
> written?  I think I should convert your writeTriggered in two updated
> flags: calibration_updated and settings_updated.
> In idle state I should check both flags and start writing the relative
> block.
> 
> 

I will typically divide my parameters into two groups. One group has the
data that the user sets, usage information, and other information that
is updated as the user works. This data gets saved shortly after the
user makes a setting change or enough time passes that the other
information is worth saving. I often also include a user option to reset
this to some 'factory default' for if the user totally messes up the
settings (this won't reset the usage data, just user settings). There is
a second block of factory calibration data. This will never be update by
the user (or only by very trusted users) and typically this block
doesn't have multiple copies (unless I need a backup for actual flash
corruption). To activate the save for this block requires giving the
device a special unlock sequence, which allow the adjustment of these
parameters and then a specific factory save command.

> Again another scenario.  Until now we talked about settings, a structure
> filled with parameters that can change when the user wants at any time.
> 
> How to manage a log, a list of events with timestamp and some data?
> Suppose one entry takes 8 bytes.  I reserve 4kB of memory for around 500
> entries organized in a FIFO.
> 
> Log isn't so critical as the settings, so I think I could avoid
> redundancy in non-volatile memory.  Maybe only the CRC that, when not
> valid, clears all the log.  It should be acceptable.
> 
> As usual we can talk about the opportunity to read the full log and put
> it in RAM, or read the entries when needed (because the user wants to
> read some entries, mostly the more recent).
> Reading 10 entries (80 bytes) from 10MHz SPI memory doesn't take too
> much (no more than 100usec). But here the problem is that reading can be
> needed during writing of settings.  And this is a big problem.
> 
> As usual, simplest solution is to have the full log in RAM... sigh!
> 
> What about writing of one or a few new entries in the log?  A writing
> operation (for example, settings) should be in process.  I should
> schedule and postpone the log update after writing of settings is finished.
> 
> Because you have much more experience than me (and you are so kind to
> share it with me and other lurkers), could you suggest a smart approach?
> 

For logs, I will define a log information block to store a single log
entry, back the number of them I can into a flash sector. The total log
then has a number of these sectors reserved for the log, forming a
circular list (so writing a new log entry overwrites the oldest log
record). I tend to have two sectors of these log entries 'cached', so I
can be creating one log entry at the end of one block and one at the
beginning of the next block. While I am filling a given log entry, it is
marked as 'invalid', and that is cleared when the entry is finished. A
given sector is written when it is full, or a sufficient time after a
block has been updated to minimize log data loses due to power loss.
This write uses the same flash buffer as the parameter flash buffer as I
can't be both writing a log sector and a parameter sector at the same
moment.

Thread

Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-14 12:20 +0200
  Re: Serial EEPROM or Serial Flash? David Brown <david.brown@hesbynett.no> - 2018-06-14 12:49 +0200
    Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-15 09:38 +0200
      Re: Serial EEPROM or Serial Flash? Jack <jack4747@gmail.com> - 2018-06-15 00:54 -0700
        Re: Serial EEPROM or Serial Flash? Reinhardt Behm <rbehm@hushmail.com> - 2018-06-15 16:26 +0800
          Re: Serial EEPROM or Serial Flash? Jack <jack4747@gmail.com> - 2018-06-15 01:31 -0700
          Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-15 10:50 +0200
            Re: Serial EEPROM or Serial Flash? Reinhardt Behm <rbehm@hushmail.com> - 2018-06-15 17:03 +0800
              Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-15 14:59 +0200
                Re: Serial EEPROM or Serial Flash? David Brown <david.brown@hesbynett.no> - 2018-06-15 15:51 +0200
        Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-15 10:47 +0200
          Re: Serial EEPROM or Serial Flash? Jack <jack4747@gmail.com> - 2018-06-15 02:20 -0700
            Re: Serial EEPROM or Serial Flash? Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2018-06-15 13:41 +0200
            Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-15 15:01 +0200
      Re: Serial EEPROM or Serial Flash? David Brown <david.brown@hesbynett.no> - 2018-06-15 11:25 +0200
        Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-15 15:10 +0200
          Re: Serial EEPROM or Serial Flash? Jack <jack4747@gmail.com> - 2018-06-15 06:51 -0700
          Re: Serial EEPROM or Serial Flash? David Brown <david.brown@hesbynett.no> - 2018-06-15 16:21 +0200
            Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-15 17:20 +0200
              Re: Serial EEPROM or Serial Flash? Richard Damon <Richard@Damon-Family.org> - 2018-06-15 13:11 -0400
                Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-15 22:54 +0200
                Re: Serial EEPROM or Serial Flash? Richard Damon <Richard@Damon-Family.org> - 2018-06-15 18:25 -0400
                Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-16 08:26 +0200
                Re: Serial EEPROM or Serial Flash? Richard Damon <Richard@Damon-Family.org> - 2018-06-16 09:20 -0400
                Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-16 19:38 +0200
                Re: Serial EEPROM or Serial Flash? Richard Damon <Richard@Damon-Family.org> - 2018-06-16 16:41 -0400
                Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-16 23:05 +0200
              Re: Serial EEPROM or Serial Flash? David Brown <david.brown@hesbynett.no> - 2018-06-17 18:41 +0200
            Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-16 20:12 +0200
              Re: Serial EEPROM or Serial Flash? David Brown <david.brown@hesbynett.no> - 2018-06-17 19:27 +0200
                Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-19 17:40 +0200
              Re: Serial EEPROM or Serial Flash? Richard Damon <Richard@Damon-Family.org> - 2018-06-17 17:05 -0400
                Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-19 17:44 +0200
                Re: Serial EEPROM or Serial Flash? Richard Damon <Richard@Damon-Family.org> - 2018-06-19 23:14 -0400
                Re: Serial EEPROM or Serial Flash? pozz <pozzugno@gmail.com> - 2018-06-20 11:03 +0200
                Re: Serial EEPROM or Serial Flash? Richard Damon <Richard@Damon-Family.org> - 2018-06-20 08:03 -0400
  Re: Serial EEPROM or Serial Flash? Michael Karas <mkaras@carousel-design.com> - 2018-06-23 09:43 -0700

csiph-web