Store /save sketch changes without Editing Program even during power off.?

I know the subject is confusing. This is what I am trying to do. I am basically monitoring an analog sensor using an UNO and a GSM shield. I am using it to send me text alerts if this sensor I am reading goes out of bounds ie if analog.Read is less than 200 or greater than 500 alert me via text. This is fine I can make this happen without any trouble. What I want to know is say I wanted to change the bounds to 210 and 490 via text and have those changes be saved even after the UNO loses power and restarts. Is this possible and if so how?

Thanks,
Jake

It is possible and you need to save these values to EEPROM. There is an EEPROM library that you can use for this purpose.

marco_c:
It is possible and you need to have these value to EEPROM. There is an EEPROM library that you can use for this purpose.

Cool I looked at the EEPROM tutorial. To see if I am understanding this correctly I can store a byte in any of the 512 "addresses" and simply recall and or edit it when ever I want. (so it's kind of like an array?? (Probably a dumb question but I am a Mechanical Engineer not a programmer sorry))

Are there other parts of the standard sketch that use this memory? The real question is am going to mess something up if I simply use bytes 1-10 to store stuff?

EEPROM is an Electrically Eraseable Programmable Read Only Memory. It is designed to be written (very) infrequently and read much more frequently, so it is ideal for the application of storing run time parameters like you are looking for. Writes are relatively slow as we are setting hardware links, reads are much faster. There is a limit to the reprogramming that you can do with these addresses (something like 100,00 cycles - read the spec sheet), so don't rewrite them in a loop or you will fail the memory rather quickly.

EEPROM is just memory, which in the end are an array of bytes (actually bits) in the hardware. So essentially like an array of bytes, but not in RAM. It is separate from the RAM space the program runs in, so you can use it for what you want without conflict with your program code or variables.

marco_c:
EEPROM is an Electrically Eraseable Programmable Read Only Memory. It is designed to be written (very) infrequently and read much more frequently, so it is ideal for the application of storing run time parameters like you are looking for. Writes are relatively slow as we are setting hardware links, reads are much faster. There is a limit to the reprogramming that you can do with these addresses (something like 100,00 cycles - read the spec sheet), so don't rewrite then in a loop or you will fail the memory rather quickly.

EEPROM is just memory, which in the end are an array of bytes (actually bits) in the hardware. So essentially like an array of bytes, but not in RAM. It is separate from the RAM space the program runs in, so you can use it for what you want without conflict with your program code or variables.

Well with that information this seems to be exactly what I want I figure I'll be writing to it maybe once every couple months so cycle life isn't a problem. Yes I will be reading from it nearly constantly but that doesn't seem to be a problem. I will play with this new information and get back here if there is something that really gets me stuck. Thanks marco_c your information is great.

I just wanted to make sure before I destroyed my UNO, It is not okay to write to the EEPROM a lot. (That is fine for me) It is also okay if I read from EEPROM a lot. ?

I kind of have a choice. I can read from EEPROM during power up and as soon as I change something or I can put the read in a loop and just have it read it everytime through the loop. Reading it through the main loop will be easier and make my code look nicer so I would like to do that but if I find that I might end up with a problem I can do the other option.

What do you think?

Reading a lot has no effect other than it is (relatively) slow memory compared to RAM. In my code I generally load a copy of EEPROM parameters as part of initialisation and then work off those. Changes are carried out in RAM and then written all at once. If I found I was short of memory I would probably switch to reading the parameters from EEPROM (the usual speed vs memory trade off).

I would also recommend reading from EEPROM only once in setup().

Write two functions, one is parameter_save() that saves all parameters (easy, no need to save one that got the change), another is parameter_read() that reads all parameters from EEPROM.

Caution to using EEPROM to save and read parameters: I do this in most of my projects. I also put a "KEY" in a fixed EEPROM location, such as at 1023 address location I save a character. Every time I roll out a new code version, I change this key to a different character. In setup(), I first read this key and see if the value read back is the same as the one the program has. If yes, then this program has run at least once and proceed to parameter_read(). If the key from EEPROM doesn't match the one the program has, it knows this is the first time it is running and proceeds to parameter_save(). This is to prevent a newer version code to read in saved values formatted by a previous version code, which will screw up the new version code royally. :wink:

liudr makes a good point. You may also want to consider being able to start the system with 'factory defaults'.

I have done this in the past by designating an input (which is already used by something else like a user input switch) and if the systems starts up the input is 'active' then the defaults are loaded rather than the EEPROM values. This also helps to get around any problems in case your EEPROM values are corrupted or from a different version.