Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27830

Re: Serial EEPROM or Serial Flash?

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.arch.embedded
Subject Re: Serial EEPROM or Serial Flash?
Date 2018-06-17 19:27 +0200
Organization A noiseless patient Spider
Message-ID <pg65m3$4ml$1@dont-email.me> (permalink)
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>

Show all headers | View raw

(You emailed me a copy of this post too.  I guess that was a slip of the 
mouse - we all do that from time to time.  Anyway, I'm replying the 
newsgroup and ignoring the email version.  That way everyone can see it, 
and more people can join in the fun.  It's good to see an interesting 
thread here in c.a.e. - it's been a bit idle recently.)

On 16/06/18 20:12, pozz wrote:
> 
> Il 15/06/2018 16:21, David Brown ha scritto:
> 
>  > static enum { idle, writing, checking, erasing } writerState;
>  >
>  > void doWriter(void) {
>  >     switch (writerState) {
>  >         case idle :
>  >             if (writeTriggered) {
>  >                 writeTriggered = false;
>  >                 startWriting();
>  >                 writerState = writing;
>  >             }
>  >             break;
>  >         case writing :
>  >             bool stillWorking = pollNVMdevice();
>  >             if (stillWorking) return;
>  >             startChecking();
>  >             writerState = checking;
>  >             break;
>  >         case checking :
>  >             bool stillWorking = pollNVMdevice();
>  >             if (stillWorking) return;
>  >             startErasingNextBlock();
>  >             writerState = erasing;
>  >             break;
>  >         case erasing :
>  >             bool stillWorking = pollNVMdevice();
>  >             if (stillWorking) return;
>  >             writerState = idle;
>  >             break;
>  >     }
>  > }
>  >
>  > There - half your program is done
> 
> I was thinking on this "long-running" task that writes non-volatile data 
> to serial memory in the background, during normal execution of the  main 
> application.
> 
> First question. If I understood well your words, the checking state has 
> the goal of comparing data written (by reading them) against original 
> data in RAM.  If they differ, we should go back in writing state, maybe 
> changing the destination sector (because the write could be failed again 
> for physical damage of that sector).

Yes, basically.  It is up to you how you handle things if the ram copy 
can be changed underway.  You might use a second copy in ram for a 
check, you might ban changes during the write/check period, or you might 
simply run a checksum on the written data and check that it matches.

> 
> Another question is: what happens if saving is triggered again during 
> writing?  I think there isn't any big problem.  The writing task can be 
> started again from the beginning, even on the same destination sector.
> So during writing and checking states I should check for writeTriggered 
> flags again and prematurely stop the writing and start again from the 
> beginning.

Usually the most important thing is that the data stored is a consistent 
snapshot of the data structure, rather than the most recent version.  So 
you should continue saving what you are doing before triggering a new 
write.  But be very careful if you allow writing to the ram copy of the 
data while a write is in progress.

> 
> 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.
> 

Sure, have as many blocks as you like.

> 
> 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.

Have part of your NVM chip reserved for the logs.  Log in blocks, with a 
crc on each.  Don't bother holding more than two log blocks in ram (one 
being stored to NVM, and one for updating at the moment).

> 
> 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?
>

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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