I have a sketch with an unsigned long integer variable that remains unchanged for long periods of time, but which can be changed manually while the sketch is running. After a change, the new value for the variable must be used thereafter until another change is made. To keep track of the variable during power interruptions I save its value in EEPROM immediately after any change, and fetch it at the start of the loop function. The number of EEPROM writes is probably less than one per month or so, but since it reads the EEPROM every loop, that could amount to as many as a few hundred reads per day. I tried putting the EEPROM read instruction in the setup routine but that didn't seem to work. I have a feeling I have not handled this properly and that there may be a more elegant way.
The proper place for reading the EEPROM is in the setup() function but you have not shown the problem so it is impossible to help with that.
Too many writes to an EEPROM are bad. Many reads from an EEPROM are "so what?"
OLDokasional:
I tried putting the EEPROM read instruction in the setup routine but that didn't seem to work. I have a feeling I have not handled this properly and that there may be a more elegant way.
No, that is entirely the correct way.
Show your code, or ideally a minimal example which demonstrates how it is "not working".
Even though you only have 17 posts, we assume you are aware you need to show us your code when help is requested.
Use CTRL T to format your code.
Attach your ‘complete’ sketch between code tags, use the </> icon in the posting menu.
[code]Paste your sketch here[/code]
Thanks vaj4088 and pcbbc for your answers. I went back and tried setup again and it works perfectly. I must have screwed up somehow when I tried it the first time.
larryd, you are wrong when you say "you need to show us your code when help is requested" as proven by the excellent help from these two gentlemen. One reason I use the forum only as a last resort is the unreasonable and illogical demands placed on requests for help. For example, you say "Attach your 'complete" sketch ..." My sketch is over 1000 lines of code. Do you really think that would have helped answer my question?
OLDokasional:
larryd, you are wrong when you say "you need to show us your code when help is requested" as proven by the excellent help from these two gentlemen.
I would concur with @larryd completly.
I have used EEPROM (and FRAM) extensivly for storing variables and data that need to survive power downs or resets.
It matters not a jot where the read of the EEPROM data is, setup(), loop() or wherever, its an EEPROM read, it should work wherever it is.
So if your having problems, I cannot see how the problem could be reliably identified without seeing your code.
OLDokasional:
I tried putting the EEPROM read instruction in the setup routine but that didn't seem to work.
Did not 'seem' to work, it either does or it does not ?
If your EEPROM read does not work in setup, there is some fundamental issue with your code, so probably easy for someone to spot if you posted it ...........................................
If you have followed any thread on these forums, you surely are aware there are posting rules you need to follow.
Large sketches are requested to be reduced in size where the problem still exists.
It seems you are either refusing to follow posting rules or you have not taken the time to read them.
Yes you got your answer, this is as a result of the quality help and experience of volunteers here, not because you properly formatted your initial question or you supplied proper information.
Why don’t you want to help those who want to help you ?
Why not work with the rules rather than ignoring them.
If
larryd:
Large sketches are requested to be reduced in size where the problem still exists.
I can’t reinforce to the OP how useful a debugging technique this is. In a large proportion of cases you can usually find your own problem by following just this one simple step (which you have done - well done).
However if you hadn’t found the problem on your own we’d still have been at square one and asking you to post your code - wouldn’t we?
So sorry, but NOT sorry you received “short shrift” form other forum members for not doing so. When you help out here it is extremely frustrating if the very first thing you need to do is ask for code to be provided in 90% of cases.
In my book, if you are asking for free help, your first step is to help the people who are going to be helping you by following the basic “Posting rules”. Those are clearly laid out in the sticky post.
Usually, we need to see the problematic code and larryd is correct.
When the code is long, a short, simple, compilable example that demonstrates the problem would be sufficient.
I got lucky this time. It would be better in the future to read the three locked topics at the top of the forum (and anything that they link to) and follow the instructions.