“When I cover your eyes, you will recall your past activiations . . . . “
EEPROM stands for Electronic Erasable Programmable Read Only Memory and is the place in chip memory where data can be stored in the Arduino/ATMega328 even after power down. This can be useful!
The Arduino site has specifics on the EEPROM commands, so I won’t repeat that information here. However, there are some things that I’ve learned that I haven’t seen belabored enough elsewhere. Hence, this blog entry.
1. Data has to converted to byte format before it can be saved.
Suppose that x is an integer type variable and equals 3. Easy enough, you create a new variable in byte format and use the conversion function, like so:
byte xee;
xee = byte(x);
EEPROM.write(100,xee);
Unfortunately the ‘byte’ type only goes from 0 to 255. What if your variable is 256, or -34, or even worse, what if it’s floating point? You can’t simply use the byte() conversion function, you have to figure a way to break your number down into positive integers between 0 and 255, and then load them sequentially into EEPROM memory.
Likewise, when you’re taking data out of EEPROM, you’ll have to use the reverse of those conversion routines to convert from a series of bytes into, say, a floating point.
2. EEPROM can store user configuration data.
Let’s say that you program your ATMega328 chip with the Arduino, then put it on its own circuit board inside a project. Is there some way that the user can configure the chip without having to pry it out of its socket, stick it on an Arduino prototyping board, and plug a USB cable into a computer while hoping that the ports synchronize?
Well, in order to accept user configuration data ‘in the field,’ the device could use photocells (like grisbot), or pushbuttons, or perhaps jumpers from one of the unused pins to ground or high (eg, 5v). You’ll need to program a way to get into configuration mode, a way to configure when in configuration mode, and then a way to retain the configuration data even when the device is switched off. EEPROM, of course, comes in handy for the latter step.
In the photo at the top, I show how to have Grisbot retrieve data from EEPROM.
Now, Grisbot automatically stores programmed data into EEPROM for multiple playback, but when you turn it on again, it won’t automatically go into playback mode. To make it go into playback mode, cover the photocells. The low light reading will trigger playback mode and grisbot will commence operations on data stored in EEPROM rather than having to re-read data flashed from the screen.
As another example of using EEPROM to help the user, say that you turn your Arduino into the heart and mind of a game. The user can save game data from one session to the next if you allow specific user commands to access EEPROM.
3. EEPROM burnout is not that big a problem.
EEPROM can be accessed a hundred thousand times before burnout. Now, that’s a hundred thousand times for each memory cell. EEPROM memory cell #0 can be accessed a hundred thousand times, EEPROM memory cell #1 can be accessed a hundred thousand times, and so on.
Even if Grisbot were to be programmed twenty times a day, it would take five thousand days to burn out EEPROM. Five thousand days is over thirteen years. So you see, EEPROM is not necessarily a big problem for me, and probably it won’t be for you either on your project.
4. EEPROM burnout can be a big problem if you don’t watch out.
Let’s say you have an EEPROM access command in an infinite loop, like so:
infinity:
EEPROM.write(50,mem_ee);
goto infinity;
It takes only 3 ms to access EEPROM, so in just three seconds this loop could access a specific EEPROM cell a thousand times. In five minutes, the specific EEPROM cell could be burned out even though we’re just stuffing the exact same value into it over and over again.
In other words, if you make the mistake of placing an EEPROM access command in an infinite loop, you could load a program (aka ‘sketch’) into the Arduino, go to the bathroom or make yourself a snack, and by the time you get back the EEPROM cell would be burned out.
Perhaps you’ll never use the goto command, but you still have to worry about the biggest infinite loop of all, which is the void loop() procedure itself. If you cycle through void loop() several times in a second — not at all uncommon in the Arduino programming world — an embedded access command can burn out an EEPROM cell in a matter of hours unless you impose some kind of rare conditional for using EEPROM in the loop.
5. Burning out EEPROM is not the end of the world.
ATMega328 chips with the Arduino bootloader cost a lot less than an Arduino, and if you burn out EEPROM, all you have to do is replace the chip. (Of course, I’m assuming you’re using the DIP package Uno rather than SMT Leonardo.)
Nor is the chip a total loss. Maybe you have ideas for a project that doesn’t use EEPROM, so the chip can be salvaged for that.
For that matter, just because you burned out a cell doesn’t mean the rest of EEPROM is a total loss. Suppose, for example, you were saving data in cells 5 through 10, and they burn out. Why not simply rewrite your program to save the data in cells 15 through 20?
* * *
Well, I’m still new at the EEPROM game myself, so I’ll stop there. If you have any tips/corrections of your own, don’t hesitate to post a comment.
Engineer Zero 