Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27826
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Serial EEPROM or Serial Flash? |
| Date | 2018-06-16 20:12 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <pg3jta$8oa$1@dont-email.me> (permalink) |
| References | (1 earlier) <pfth8a$vpp$1@dont-email.me> <pfvqei$9t7$1@dont-email.me> <pg00mh$cmj$1@dont-email.me> <pg0ds2$sal$1@dont-email.me> <pg0i0n$nlr$1@dont-email.me> |
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).
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.
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.
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?
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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