Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27846
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Serial EEPROM or Serial Flash? |
| Date | 2018-06-19 17:40 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <pgb84l$6rj$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> <pg65m3$4ml$1@dont-email.me> |
Il 17/06/2018 19:27, David Brown ha scritto:
> (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.)
My Thunderbird has a Reply button that sends an email to the sender and
not to the groups. I have to right-click and choose "send to group"
explicitly. And it sometimes happen I forget.
> 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).
Good suggestion. Maybe I missed to explain that the user could want to
read the log. If I don't keep *all* the log in RAM, it is possible that
the application needs to read the log from the memory chip... this is
against our first assumption to read all the data at startup and keep it
in RAM to simplify writing without blocking.
The function that needs to return one or more entries should read from
the memory chip... however it can be busy in writing.
One possibility is to block while waiting for the end of writing, but
blocking tasks aren't good. Another is to change the function to be
asyncronous...
>> 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