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-20 11:03 +0200
Organization	A noiseless patient Spider
Message-ID	<pgd584$lfq$1@dont-email.me> (permalink)
References	(5 earlier) <pg0i0n$nlr$1@dont-email.me> <pg3jta$8oa$1@dont-email.me> <o2AVC.208842$mS3.44599@fx04.iad> <pgb8c1$9bd$1@dont-email.me> <iEjWC.253888$T14.120742@fx44.iad>

Show all headers | View raw

Il 20/06/2018 05:14, Richard Damon ha scritto:
> On 6/19/18 11:44 AM, pozz wrote:
>> 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?
> 
> If it is an external flash (or an internal flash that a write blocks
> reading), then when the application asks for the block it will block on
> the Mutex guarding the device. 

In my cooperative kernel, I have two choices:
   - block the entire application waiting for serial memory availability
     * for 24LC64, maximum the page-write time, max 5ms
     * for a serial Flash, maximum the sectore-erase time that is too
       much
   - convert the code in a state-machine, sigh... :-(


> One big reason to use a pre-emption based
> system. Normally, reading of log entries is only done in response to an
> external command

I usually work on a bare-metal system.

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