Very good information on the data sheets, your explanation was very helpful to understanding what is printed.
With constructive criticism I have learned a LOT here, not because the information was always spoon fed, but because more often than not Ive been given just enough information to steer me in a more correct direction.
I like to help people learn how to figure things out themselves rather than just providing whatever answer might solve the particular problem of the day. Better that you learn how to figure something out so that the next time the issue comes up, you won't have to ask about it again.
I guess part of this comes from my college professor Steven Robel (RIP). Some of the yelling about not memorizing equations - figure out what the equations mean - got through to at least one of his students. If you understand the concept, you don't need to remember a different equation for every case.
In the case of information in the data sheet, it would be a lot easier for me just to post an answer to the question. "42" is a lot easier than explaining which section to look in. Of course, sometimes information in data sheets isn't always clear or is just wrong so asking for help understanding some parameter or exactly what some section means is always ok. But if the question is "What is the minimum operating voltage for a PIC18Fxxx?", you should be able to look that up just as easily as anybody else...and sometimes you find interesting information in the process
Re: EEPROM, writing and reading..
8 years 2 months ago #8517
To expand a little more on something Jon mentioned, some non-volatile memory specs are often misunderstood. There are two numbers given in the programming specs... a 'Byte Endurance' parameter and a 'Total Erase/Write Cycles before Refresh' parameter.
EEPROM memory works by storing charge on a cell. In order to update a cell location, it must first be erased. With most EEPROMs, this erase step is totally automatic and transparent... usually all you have to do is write to the byte. An individual location has a limit to the number of these erase/write cycles before it wears out and can no longer hold a charge. That's the 'Byte Endurance' number and it's shown as a minimum of 100K in that datasheet example. Usually, the real numbers are higher than that, but that's what is guaranteed.
The second parameter is the 'Total Erase/Write Cycles before Refresh' number, and that bears a little explaining. Every time a location is erased and rewritten (let's say the byte at location 10), a little bit of charge bleeds off some of the OTHER locations around it, and if that's done often enough you'll find that bytes that you weren't even reprogramming can have their contents change as all the charge bleeds off. That's the 1M-10M number shown in that table. What that says is that every 1M write cycles (to ANY/all locations combined) you need to refresh the contents of the entire array. In the 25K22 datasheet (rev D), this is talked about in section 7.8 "Using the Data EEPROM".
You need to pay attention to how you're using the device. If you're only going to update stuff perhaps a few thousand times over it's life, then you really don't have much to worry about. If you're going to mix frequently changing data with data like setup information that's changed less often, then that might be an issue.
Many times, you can take care of both these issues with a bit of software to do some wear-leveling and extend the useful life, but it's a tad more complicated than just "writing to byte 10" all the time.
And Burt's right... you can easily wear it out in a week if you're constantly writing data.
5.8 Using the Data EEPROM
The data EEPROM is a high-endurance, byte
addressable array that has been optimized for the
storage of frequently changing information (e.g.,
program variables or other data that are updated often).
When variables in one section change frequently, while
variables in another section do not change, it is possible
to exceed the total number of write cycles to the
EEPROM without exceeding the total number of write
cycles to a single byte. If this is the case, then an array
refresh must be performed. For this reason, variables
that change infrequently (such as constants, IDs,
calibration, etc.) should be stored in Flash program
Jon this is wrong
This still shouldn't be a problem to store constants as long as you don't write them every cycle through a loop or something like that.
Please read part in red
If you want to log something I'm sure you don't want to end up with unusable junk
That why people use SD cards and add-on cards to hold logged data