Re: Serial EEPROM or Serial Flash?

From	pozz <pozzugno@gmail.com>
Newsgroups	comp.arch.embedded
Subject	Re: Serial EEPROM or Serial Flash?
Date	2018-06-19 17:44 +0200
Organization	A noiseless patient Spider
Message-ID	<pgb8c1$9bd$1@dont-email.me> (permalink)
References	(3 earlier) <pg00mh$cmj$1@dont-email.me> <pg0ds2$sal$1@dont-email.me> <pg0i0n$nlr$1@dont-email.me> <pg3jta$8oa$1@dont-email.me> <o2AVC.208842$mS3.44599@fx04.iad>

Show all headers | View raw

Il 17/06/2018 23:05, Richard Damon ha scritto:
> 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.
> 

Do your application read log entries?  What do you do to avoid reading 
when the memory chip is busy in writing?

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