Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27802
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Serial EEPROM or Serial Flash? |
| Date | 2018-06-15 09:38 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <pfvqei$9t7$1@dont-email.me> (permalink) |
| References | <pftfgp$l3j$1@dont-email.me> <pfth8a$vpp$1@dont-email.me> |
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. > 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. >> 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. >> 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. > 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). 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? >> 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. 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