#65 Arduino EEPROM Basics - easy to do and useful to implement

Storing data into non-volatile EEPROM memory (that does not lose that information when the Arduino is switched off) can be very useful, whether that's for remembering some configuration settings or the high score of your latest game.

Best of all, it's so easy to do these days as you don't have to know how long the data is for the data-type you're trying to store (nor do you have to switch the high and low end bytes around either - see what I mean?)

So don't forget the last value you calculated; use the EEPROM instead of an SD card - you can write to the same cell 100,000 times so you might not need an SD card at all in certain data logging situations.

Knowing how to do this is all part of the Arduino learning experience and here I actually implement an improvement to one of my existing projects (in daily [well, nightly] use) to make using it just that tad easier.

The sketch I'm using builds upon an earlier sketch for the project I have now enhanced but it will be child's play to use those lines in your code.

I've included the sketch used in the video here just for completeness:

Background C# 'struct' information

Writing ANY data type to EEPROM background (now part of standard EEPROM library):

The standard EEPROM library functions:

For advanced users, the extended EEPROM library (includes bit writing)

If you like this video please give it a thumbs up, share it and if you're not already subscribed please do so :)

My channel is here:
------------------------------------------------------------------
------------------------------------------------------------------
How can I remember this? Memory tip: "See" Ralph Bacon, geddit?

[maxximumb]

I've salvaged so many EEPROMs from different old circuit boards, now I have a couple of ideas on projects to use them.

[chillzwinter]

So if you change the brightness from 0 to 255, you press the up button 255 times, and it writes to the eprom 255 times. Maybe only write to the eprom after the value has not changed for more than 20 seconds using the millis() command - will potentially extend the life of the eprom address by a couple hundred times. PS. Love the debugPrint() command - gonna use that.

[JonHeckendorf]

I'm needing to store and recall values for a project I'm working on and found this video about using the Arduino EEPROM (never needed until now) which prompted me to write this. I subbed your channel many years ago and liked this video many years ago as well. But, I never get tired of your presentations and detailed explanations. I hope you never stop. Thank you for being here for us, DIY experimenters.

[seditiousmonkeyart]

Hello Ralph, I'm just beginning my adventure into using the EEPROM feature on the Arduino, and of course, you were my first port of call. As always I was not disappointed.
I served in the Royal Australian Navy as a Stoker (engine and boiler room stuff). We also used red light when the ship went into action or damage control stations. Not only for the reason you gave that red light does not travel far, but also because it preserves your night vision should you need to venture out into the dark of outside the citadel (the closed of internal areas of the ship).
Thank you for the great introduction. I am about to send you an email anyway with the latest project.

[BerndFelsche]

Uninitialised, the get will set the fade value with 2 bytes of 255; i.e. 65535 as unsigned integer. this is easy to detect as uninitialised and you should put a default (factory) value into eeprom when detected.

I usually write a "magic" value to a fixed address and a firmware version, so that the firmware doesn't get confused when the data storage layout changes.

Factory-setting is done in a separate function that's called when appropriate by setup() or somewhere else as needed. Default values set by defines. If there's space, initialise a "buffer" using those defines (just takes compiler cycles) to simplicate the code for factory-set. Alternatively, store factory defaults elsewhere in eeprom, then use get and put to set run values.

avrdude, which programs onto the arduino, can also initialise eeprom with custom values. Very useful! And, depending on fuse settings, it can read eeprom.

[josip]

You are the best Ralph when it comes to this topics, thanks! Was amazed how many old EEPROMs one can find in old tech from 90-is and early 2000, in old monitors and TV's there is tons of useful stuff, good for first experiments :)

[gamedinnah]

7 years later… how’s the EEPROM? Excellent info, thank you 👊🏼

[mukageegee]

Thanks again Ralph. What a really easy way of linking remotes to Arduino. I have a 12 way remote set with keypad type control. Now...where is that Mega?😂

[willofirony]

A great presentation and very enlightening (sic). I heard you say that the eclipse with Arduino plug-in IDE was perhaps ott for the average hobbyist. Nevertheless, I have been meaning to ask you to do a presentation on your set up. I am used to the "intellisense" of Visual Studio and find the arduino somewhat basic (its aversion to true static libraries is a pain too, particularly in memory sensitive situations). I think many of your subscribers would find it educational to have the library code exposed in such a user friendly manner. Yes, I know there has been a recent release of a VS plugin for the Arduino family but, alas, I am moving my development environment over to Ubuntu, so no more VS or AVR Studio for me (sob!). Thanks for your presentations, they are a treat. Merry Christmas Ralph.

[geoffreyjbrown]

One idea for something to cover would be delving into how an Arduino Library works. One good example you could use is the EEPROM.h in the arduino/lib/EEPROM folder for the normal Arduino IDE. This would enable viewers to make the linkage between the use of an include in the code and how this is mapped out. It would help to demistify the complexity of the compiler and libraries.

[demetriosdemetriou]

RALF YOU ARE ALWAYS BUT ALWAYS FANTASTIC WELL SPOKEN AND EXPLAIN SO BRIGHT

[MyBigThing]

red light is used by military because it allows operation, equipment manipulation and map reading without disturbing the soldier's night vision that takes a while to develop (when your eyes adjust to the darkness) and it's easily destroyed by other wavelengths causing you to have to wait for your eyes to readjust to the dark so you can see properly again...it also doesn't spot your eyes when you blink...like when you look into the sun and then see a blackness when you blink where your field of vision was overloaded resulting in black dots for a while that are effectively blind spots. not good to have at night when your life is on the line...I hope that jiberish typing makes sense ..

[billglass]

Lots of good info, Ralph. Thanks! I avoided writing/reading from the same address by letting my home-brew library manage the addresses. The address increments in a circular mode every time I write/read a new string. For now, I'm only processing strings of any length from 1 to 255 bytes. Maybe I'll modify my library for structures too.

[AnimilesYT]

Well.. Thanks, I guess. Now I have even more to implement into my binary clock. All of these things I've been discovering along the way really add up to the amount of work I have to do. This might be one of the most useful discoveries I've made though xD
Thank you very much!

[squalazzo]

great video as always, keep on doing them! :)

[tonyeezi]

I think if you're concerned about the reliability of the internal EEPROM then a SD card and Arduino compatible reader can be bought for pennies, and should give much more reliability as the SD controller will tend to store data in different parts of the memory chip.

The EEPROM is great though for data that never changes throughout the life of the Arduino like reference data, etc, so memory cells are less likely to fail as they're only written once, but read many (WORM).

[hoppynaki]

Another great video to assist me to complete my projects. Thanks Ralph

[renezwart]

Really interesting, thanks! Would it be possible to comment at how to combine a few 'fields'? Like following a menu choise (0 to 9) you'd have the 'name' reflected in the menu, being the first field in the EEPROM address, but then you have 4 (or more) data fields attached to that choise, which are then used in functions. Something like 'Name'; up to 10 characters, 'Height'; numeral, 'Time'; numeral, 'Count'; numeral, "Comment'; up to 10 characters. I appreciate you could start the addresses with 10, 20, 30 etc. but wonder if there is a smart way to create this. Bit like an arrae structure I guess. Any comments appreciated, thanks! Cheers, Rene

[JasonMasters]

It occurred to me that for an application where you might realistically "wear out" a particular location by writing to it, you could program a work-around thus:

1. Have one 2-byte location initially programmed with a pointer to the location of the value you wish to store.
2. On each write to the pointed-to location, do a verify to be sure you saved what you intended to save.
3. If the verify fails, increment (or decrement if you're starting from the top of RAM) the value stored in the first location by the appropriate amount (2, in the case of 2-byte integers) to point to the next free location and save it, then re-try the write using the new location.

Logically, this would mean you can use the whole of an EEPROM, since the first location will never be written to 100k times because you'll run out of EEPROM locations well before that occurs, so you'll be able to write 100k times to each location multiplied by the number of locations.

For a 1024 byte EEPROM, using 2-byte integers, that means you'd be able to write 51199998 times before the whole of the EEPROM is worn out (I subtracted 2 because we'd be using one 2-byte location to keep track of where we're writing to). At 20 writes per day, that comes out to over 7000 years. That's some baby! ;)

Even writing once per second gives a total life of about 59 years using the above method.

This could of course be adjusted to work with any value which had a consistent size.

Realistically, you'd get more writes than I've calculated because the value of 100k writes is just a guaranteed minimum, not an absolute limit. Just how long do you expect to live for? :D

[mgga]

My aquarium controller project is racing along. I have developed my menu based IDE for the 20x4 LCD, where I can input the on and off times for controlling the relays for my lights and pumps and my real time clock is functioning and the time can be displayed and dismissed at will whilst the button scanning function is running in the background, and I can switch on and off several relays at given times based on the schedules I have input using the IDE with four buttons.
So far my sketch (or should I say landscape) contains over 2300 lines of code and I am far from finished, next I shall be using temperature sensors to switch on and off the heaters.

Seeing your video on EEPROM usage got me thinking! Whilst I am still developing my sketch it is becoming a pain having to input all the timing schedules over and over again each time I upload the sketch to the Mega. I am a little rusty from my Z80 programming days and in your tutorial you dealt with storing and retrieving a single value. You said that a memory address can store a value <= 255, so isn’t that two memory locations? The first one being memory address 0 to store the MSB (1111), and memory location 1 to store the LSB (1111). Assuming of course that we are accessing the first EEPROM address. Or are they stored the other way round, LSB first and MSB second, like I said I am a little rusty.

In my case I need to store many values of time data, so If for example I was to store the time 12:45 as two integers, ignoring the colon, would that be (12 in memory address 0), and (45 in memory address 2), so the next available address would be 4?

Thanks, and keep those videos coming.