When I was originally designed (in my head) the device I'm working on, I thought an SD card would be a better idea, since EEPROMs wear out. (This was also before I knew about external EEPROMs.) However, after realizing that writing files to the SD card is going to require more work than I originally thought (swapping out the card from my device would be extremely clunky and not user friend), I'm reconsidering using an EEPROM.
The 24LC512 appears to have 64Kb. This is more than enough room for my immediate needs. The only thing I'm concerned about is life expectancy.
Every time a user clicks a button, I write a single byte to save the last selection. Let's say a user does this 100 times a day.
I will also allow the user to create macros (up to 400) that will be at minimum 3 bytes each, and we can assume a maximum of 100 bytes. These won't be created/modified very often.
When a datasheet says endurance of 1 million, is that 1 million writes? 1 million read/writes? Is that per byte?
Can someone help decipher (talk to me like I'm 6 years old) the life of an EEPROM and if 100 times for a single byte is acceptable?
Endurance 1mil means 1mil erase/writes cycles.
Erase/write cycle means usually erasing a "block of memory" (a page) and then a write the bytes within the page. Thus erasing a page and writing data to the page is one cycle.
For details you have to consult the datasheet (ie the erase page size).
Example: if you want write 1000 bytes per day, the above memory will last for 65.5*1000 days. That is for the entire operational range of the memory (voltages, temperatures). When using it under ambient temperature and standard voltages it may survive few times more cycles
You may read it as many times as you want.
The other parameter is Data Retention >200years. That is also for entire guaranteed operational range, so under ambient it will be higher.
But - while still below endurance limit in the year 10000 (ambient 80degC), the data written in the year 9800 might be lost
PS: if you are concerned with endurance, you may try FRAM or MRAM memories, they are nonvolatile and got unlimited endurance. Consult datasheet for data retention.
"When doing a write of less than 128 bytes the data in the rest of the page is refreshed along with the data bytes being written. This will force the entire page to endure a write cycle, for this reason endurance is specified per page."
So, 1 million writes per page (128 bytes), right? If I write a single byte, I may as well write 128 bytes. However, trying to keep a full page in memory starts to eat away at my Arduino's SRAM (trying to keep a 128 byte buffer!!).
However, since this EEPROM has 512 pages, each of my macros could have its own page.
I saw pito recommend that earlier, but I had no idea what it was. Your DigiKey link made a world of difference in helping me investigate.
Let's run with the FRAM idea for a minute and tie back into my USB question from another thread. (I know this is a bit OT from the original post.) While I prefer I2C because of the simplicity, SPI is not out of the question.
Is there a single (maybe two?) IC that could let me inexpensively communicate with the FRAM over USB? Since I'm working on my own software (in C#), as long as the PC/Mac sees the device and I can use I2C or SPI to write/read the FRAM, we may have found my solution.
Adafruit makes a breakout board with the FT232H and they make it sound like you can communicate directly with I2C devices (I even heard the girl in the video say "without needing an Arduino.")
But there looks to be nasty downside to it: driver installation. If you want to use the I2C/SPI/GPIO part of the FT232H, the serial UART is disabled, and now you have to tweak your computer's drivers. YUCK! That doesn't work for users, either.
OK, throw the FT232H out the window. What can we use with an ATTiny85 to get USB to SPI or I2C?
The FT232 will work, the Attiny is programmed just like an Uno to receive whatever and write it out.
Maybe come up with simple protocol - start byte (to ensure a synced up message, maybe indicate read or write as well), start address, # of bytes to transfer, maybe a checksum if you're concerned about data integrity.
Attiny 84 & 85 don't have USART tho, I just looked. I'd go ATtiny 2313/4313 for more memory
Data and Non-volatile Program and Data Memories
– 2/4K Bytes of In-System Self Programmable Flash
• Endurance 10,000 Write/Erase Cycles
– 128/256 Bytes In-System Programmable EEPROM
• Endurance: 100,000 Write/Erase Cycles
– 128/256 Bytes Internal SRAM
and a full hardware USART for data transfer to/from the FT232.
So more like a 168/328, in a 20 pin DIP package vs 28.
Looks like SPI and I2C share the same pins, that's another advantage of the 28 pin package, Serial/SPI/I2C are all separate pins so you do less fooling around both in hardware & software to use them.
If space is a concern, then TQFP and leadless packages are available. Here's one I did up that's like a simplified Promini (no onboard regulator, but with a crystal vs resonator) but with more power/Gnd connections:
Chips alone cost me more than an inexpensive Chinese-made Promini. can't compete with cheap world-wide volume/distribution & gov't subsidized (it seems) free shipping.
Crystal and Rs, Cs are on the bottom of the board.
You can see one here, soldered down on a board. The FT232 pins are too close for us to reliably place & reflow, the module with FT232 & connecter and the Rs & Cs I figure works out to about a wash for material & loss of time trying to work chips to get them to work. Hazard of hand assembly that we eliminated.
So, 1 million writes per page (128 bytes), right? If I write a single byte, I may as well write 128 bytes.
Yes. When you erase a page and then write 128 new bytes into the 128 bytes large page it is 1 cycle (out of 1mil).
If you want to write a single byte into page[4] (fifth byte within the page) and the page has not been erased before you have to erase it - that is 1 cycle.
So writing a single byte repeatedly on the same place within the page is always 1 cycle.
Writing 128 bytes into the 128 bytes within the page is 1 cycle.
I would not deal too much with the endurance for your application - just do it
I'm thinking it may be possible to simplify life by using an MCP2221. I'm digging into that more as we speak. It seems to be similar to the FT232H in that it offers I2C or SPI, but it seems that support for that is baked into their drivers.
pito, thanks, man! This info has given me more excitement. I was getting bummed about coming up with a USB solution.
All that EEPROM page writing takes time - the internal EEPROM takes 3.3mS.
FRAM is just like accessing SRAM, mere microseconds for a byte or two.
I don't see SPI there. I2C and UART. Let us know how it works out.
Maybe that and an FRAM or two would make a good storage option for someone's project.
