Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27814
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Serial EEPROM or Serial Flash? |
| Date | 2018-06-15 15:10 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <pg0ds2$sal$1@dont-email.me> (permalink) |
| References | <pftfgp$l3j$1@dont-email.me> <pfth8a$vpp$1@dont-email.me> <pfvqei$9t7$1@dont-email.me> <pg00mh$cmj$1@dont-email.me> |
Il 15/06/2018 11:25, David Brown ha scritto: > On 15/06/18 09:38, pozz wrote: >> Il 14/06/2018 12:49, David Brown ha scritto: >>> On 14/06/18 12:20, pozz wrote: >>>> I need to save some data on a non-volatile memory. They are some >>>> parameters that the user could change infrequently, for example 10 times >>>> per day at a maximum. In the range 100-2kB. >>>> >>>> As usually occurs, the parameters that changes more frequently (10 times >>>> per day) are fewer than parameters that changes very rarely (10-100 >>>> times in the device lifetime). >>>> >>>> How to save those data? After discarding the internal MCU Flash (because >>>> of interrupts block during programming), I'm deciding if it's better a >>>> serial EEPROM or serial Flash. >>>> >>>> First of all, I think SPI is better than I2C. SPI seems much faster: >>>> 10-20MHz against 400kHz-1MHz. At least for reading. Erasing/writing >>>> time is identical between I2C and SPI. >>> >>> Read time for this sort of thing is usually irrelevant. Assuming you >>> are not badly constrained for ram, you read the NVM structure into >>> memory at startup and use it from there. >> >> In my actual project I have 2kB of non volatile data and a MCU with 32kB >> of RAM. I think I can load all in RAM at startup... even if it's silly, >> because there's an array of 100 users that I don't usually need. I only >> need to search for a valid user when one login attempt happens. >> > > It makes the code much easier. It is particularly helpful if you have > some sort of log structure in your flash for wear levelling and erase > block handling. Just read through the flash at startup, reading each > log block. If the checksum matches and the counter is higher than the > current block in ram, overwrite the ram block with the new data. It is > a lot easier to spend a few seconds doing that at startup, than to spend > a couple of seconds scanning the flash when someone wants to log in. > >> >>> This makes it far easier to >>> use, and to handle things like duplicate structures in the NVM with >>> timestamps, checksums, etc. >> >> Why? I think it is easier because, if you have all data in RAM, you >> need to only write during normal execution (the reading is performed >> only at startup). In this case, you don't mix reading/writing during >> execution. >> > > Yes. > > Writing - in particular, erasing - takes time. But it is not an action > that people need to wait for, and it can be run in the background. What > you need to avoid is that foreground tasks - user intervention or timing > critical jobs - have to wait to read data from the flash because you > happen to be in the middle of an erase cycle. > >> >>>> EEPROM or Flash? I know EEPROM can be written one byte at a time without >>>> erasing an entire block, against Flash that needs a sector erase before >>>> writing even a single byte. >>> >>> Roughly correct. It is not an exact difference - there are devices >>> marketed as E²PROM which are written in, say, 32-byte blocks. >> >> Anyway you can change only one byte of a 32-byte pages. >> >> >>> And there >>> are "flash" devices where you can write a single byte, and the device >>> handles reading the old page into a buffer, updating the byte, erasing >>> the page and re-writing. >> >> Hmm... strange chip. > > There are many variants around. Anyway, the point is that the > distinction is fuzzy. > >> >> >>>> The firmware would be simpler with EEPROMs, because I don't need to save >>>> the entire sector before erasing and restoring it during programming, >>>> when writing a single byte. With EEPROMs I can write a byte. Stop. >>>> >>>> However I don't think this simple approach can be used in a real >>>> production. Suppose I have 10 bytes to write. What happens if the >>>> writing process is stopped at the middle, maybe after 5 bytes? How to >>>> protect the system against those events? I think one solution is to >>>> have at least two copies of data in the memory and switch to the other >>>> bank after all data is completely written, with an "atomic" write >>>> operation. >>> >>> Multiple copies (at least 2) are key, along with timestamps or counters >> >> Two should be sufficient to prevent corruption caused by interruption >> during the writing of a block of data. >> Maybe three (or more) are needed to face memory *physical* corruption >> (maybe for many writings). >> I think I can ignore this event in my actual project. >> > > You use more for wear levelling. Often your flash chip is /way/ bigger > than you need - perhaps by a factor of 1000 simply because that's what > you have on stock, or that's the cheapest device in the package you > want. Spread your writes over 1000 blocks instead of 2, and you have > 500 times the endurance. Use a good checksum and accept that sometimes > a block will be worn out and move onto the next one, and you have > perhaps a million times the endurance (because most blocks last a lot > longer than the guaranteed minimum). So the writing process should be: 1. write the data at block i+1 (where i is the block of the current data in RAM) 2. read back the block i+1 and check if checksum is ok 3. if ok, writing process is finished 4. if not, go to block i+2 and start again from 1. >>> and checksums. >> >> This is interesting. Why do I need a checksum? My approach is to use >> only a magic number plus a counter... and two memory areas. >> At first startup magic number isn't found on any areas, so the device >> starts with default and write data on Area1 (magic/0, where 0 is the >> counter). > > You use checksums to ensure that you haven't had a power-out or reset in > the middle of writing, Only for this thing, you can write the counter as the last byte. If the writing is interrupted in the middle, counter hasn't written yet, so the block is not valid (because considered too old or empty). > and that the flash has not worn out. > >> >> When the configuration is changed, Area2 is written with magic/1, being >> careful to save magic/1 only at the end of area writing. >> >> At startup magics and counters from both area are loaded, and one area >> is chosen (magic should be valid and counter should be the maximum). >> >> I think this approach works, even when the area writing is interrupted >> at the middle. >> >> Why do I need checksum? The only thing that comes in mind is to prevent >> writing errors: for example, I want to write 0x00 but the value really >> written is 0x01, maybe for a noise on the serial bus. >> >> To solve this situation, I need checksum... but also I need to re-read >> and re-calculate the checksum at *every* area writing... and start a new >> writing if something was wrong. >> >> Do you have a better strategy? > > You calculate the checksum for a block before writing it, and you check > it when reading it. Simple. Do you calc the checksum of all the data block in RAM, including padding bytes? >>>> This means I need to copy&paste an entire block everytime, even for a >>>> single byte change. And this is similar to Flash approach, where I >>>> *need* a sector erase before changing a single byte. >>> >>> Yes. >>> >>> Of course, it is possible to have multiple smaller blocks rather than >>> just one big one. >> >> This is good to reduce writing time of a block of data. >> In my case I have 2kB of data, around 62 32-bytes EEPROM pages, that is >> 5*62=300ms. I don't like to block a task (in a cooperative OS) for so >> long time. > > Your writing should be done in the background. The background writer > task is blocked - the system is not. Are you thinking of a preemption OS? I'm using a cooperative OS. >> So I could thing to split data in smaller blocks. Maybe I can accept a >> task that blocks for 50ms maximum. This means 10 pages, 320 bytes. So >> my data should be splitted in 6 areas. >> >> I think they are too much. >> >> >>> And you don't have to erase the old blocks until you >>> need to re-claim the space. >> >> Surely... however at steady-state I have only messed areas that should >> be erased at every writing. >> >> >>>> What about the time? EEPROM write cycle is about 5ms for a 32-bytes >>>> page. For 128 bytes/4 pages, 20 ms. >>>> Flash sector erase time is 18 ms, plus 14us for each byte. The overall >>>> write cycle time is similar between EEPROM and Flash. >>>> >>>> If the data are bigger, for example 1kB, the Flash technology wins. The >>>> sector size in Flash memories are usually bigger than 1kB. So I need to >>>> erase only one time (18m + 14u*1024=32ms). In EEPROM I have 32 32-bytes >>>> pages, so 5m*32=160ms. 5 times more than Flash. >>>> >>>> I'm not considering endurance. EEPROMs are better (1000k write cycles) >>>> than Flash (100k write cycles), but I don't need so much write cycles in >>>> the entire device lifetime. >>>> >>>> >>>> After those considerations, I think I will choose a serial SPI Flash, >>>> maybe 512kbit. The price is similar to serial EEPROM of only 64kbit. >>>> I see only one difficulty: how to write a good device driver to manage >>>> serial Flash: copy the content of a sector in another sector, making the >>>> changes on-the-fly, and switch from one sector to the other in one >>>> "atomic" operation. Could you suggest some code to study? >>>> >>>> I missed something other? Please share your considerations. >>> >> >
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