First off, some background about what I'm trying to do:
I'm using an arduino mega 1280 to drive a set of stepper motors and two external PID controllers, which in turn operate a couple of heaters. I'm using external PID controllers instead of making it part of the ardunio program in order to off-load that burden and increase the performance of both my motor control and temperature control in the proccess.
When my PC software says "change target temperature to 100 degrees", the arduino needs to know what temperature the PID controllers are set to in order to know that "I'm set at 150 degrees now, I have to trigger 50 decrement button presses to get to 100". It's overly complicated, but my PID controllers don't support RS232 or anything like that, so I have to electrically hijack the buttons on the front panel of my controllers in order to interact with them via program. The time it takes to make these temperature adjustments is not a huge issue because the system has to pause in order to let the temperature level out after a change anyhow. Once things are up and running, I only need to bump it up/down by 10 degrees which takes less than a couple of seconds anyhow.
Programatically adjusting the temperature settings via electrical pulses to the keypad works well enough. However, the setup routine required in order to know what temperature setting we are starting from is rather inconvenient. It adds about a minute to the "warmup" time which already takes about 5 minutes. If I could save the last programmed temperature value to non-volatile memory, that would help shave off some time. Eeprom has a relatively limited read/write lifespan though, which means I don't want to be writing to it every 100ms while my temperature adjustment loop runs.
Now then, to my actual question:
Is there a good way to write to eeprom just before the arduino is switched off or reset? Ideally I could just record the last known temperature setting in the moments before that information is lost. Then when I start it up again I just need my program to pull that value out of memory. Right now I have to set my PID controlers to -200 (the lowest allowable setting which makes it a predictable starting point) then bringing them back up to 230
Is there a good way to write to eeprom just before the arduino is switched off or reset?
No.
The best you can do is to have a circuit that warns when the power is going off and keeps the arduino powered for the 100mS or so it takes to write to EEPROM. Then have that output trigger an interrupt.
The reset is another matter and that will require hacking the boot loader to make sure your values are written. It will need to see if your sketch is actually in place and also decide if this is a warm reset or a cold one. A cold reset is one from no power, a warm one is an interruption of the processor while it is running.
Is there a good way to write to eeprom just before the arduino is switched off or reset? Ideally I could just record the last known temperature setting in the moments before that information is lost.
This kind of desired feature comes up frequently. It's certainly possible to monitor input voltage and generate some kind of interrupt to save variables to eeprom. It's certainly not a trivial effort as details have to be known, such as what is the source of power to the Arduino, etc.
However I've never heard of a request to save data to eeprom prior to a hardware reset. What would be causing or initiating the reset? With power, there is usually some decay time to do some quick software function given a proper detection method, but detecting a reset before it actually occurs? Once the reset occurs that stops the program in it's spot and will cause all variable values to be lost when the reset goes away and the sketch starts with reinitated SRAM values.
Dazed_dnc:
When my PC software says "change target temperature to 100 degrees", the arduino needs to know what temperature the PID controllers are set to in order to know that "I'm set at 150 degrees now, I have to trigger 50 decrement button presses to get to 100". Once things are up and running, I only need to bump it up/down by 10 degrees which takes less than a couple of seconds anyhow.
What I would do:
When the command comes from the PC to change temperature.
Set the EEPROM to indicate UNKNOWN SETPOINT (just in case a power failure happens during this adjustment)
Send the pulses to change the setpoint.
Write the EEPROM with the new setpoint.
On startup:
If the EEPROM says UNKNOWN SETPOINT, go through the re-calibration (via -200)
otherwise read the current setpoint from EEPROM.
Unless your PC is trying to change setpoint thousands of times per day you should be OK on EEPROM life.
I don't know enough about burning/hacking a boot loader to try that. I would probably just mess something up and brick it. I like the idea of monitoring the incoming power for a voltage drop and triggering an event based on that, but my electrical engineering knowledge is not yet advanced enough to design a circuit for that purpose. Or, could it be done via programming somehow?
johnwasser: That sounds like the most practical solution. The temperature should only need changed 5 or so times per 4 hours on aveage. In the most extreme case that might go up to 20. I think I will take your approach unless someone has a solution that completely eliminates the need for calibration.
Would it be possible to use other eeprom addresses as a workaround for worn out bits or does every write operation require accessing entire blocks of memory - thus causing the entire chip (or at least large sections of it) to fail at the same rate?
The datasheet says the EEPROM is good for at least 100,000 write/erase cycles. The EEPROM page size is four bytes. I suspect that EEPROM.write(), which can only write a single byte, will do four erase/write cycles if you write four consecutive bytes, even if those four bytes are in the same "page".
It also says that writing to EEPROM when Vcc is low is a good way to get corrupted EEPROM data.
johnwasser:
The datasheet says the EEPROM is good for at least 100,000 write/erase cycles. The EEPROM page size is four bytes. I suspect that EEPROM.write(), which can only write a single byte, will do four erase/write cycles if you write four consecutive bytes, even if those four bytes are in the same "page".
100000 cycles seems unnervingly sort by comparison to typical transistors, etc but I guess that still gives me at least 10 years given my expected usage. Technology changes so fast I can't picture still using this after even 5 years. At the end of the day I guess its a moot point then.
johnwasser:
It also says that writing to EEPROM when Vcc is low is a good way to get corrupted EEPROM data.
Did not know that. Thanks for pointing it out. I have a couple of different power supplies to work with in my application, so maybe I can finagle things in a way that the 5v supply stays stable. Really I would only need to detect decay at the 12V supply so that the ardunio stops trying to change the temperature during an emergency shutdown or failure of some type.
I may not be able to use this exact technique given the above comment, but the circuit still interests me. This strikes me as one of those basic building block circuits that every half-baked EE would know by heart. It could be handy for other projects, so I would like to understand it more.
Why do you need a resistor to "limit the charging current"? It makes sense to me that you would want to use a resistor to restrict output current thus slowing down the charge drain, but why would you want to slow down charging it? Also, why use the diode? Unless I've got it backwards, that diode seems to bypass the resistor when the circuit is supplying voltage - which would run counter intuitive to my assumption about limiting the output current.
you need a resistor to "limit the charging current"?
Because that cap will be seen as a dead short to GND (or whatever voltage it is at) if it's not fully charged, the resistor limits the current flowing into it so you don't kill the 5V regulator.
Also, why use the diode? Unless I've got it backwards, that diode seems to bypass the resistor when the circuit is supplying voltage - which would run counter intuitive to my assumption about limiting the output current.
You don't need to limit the output current, the circuit being driven will take what it needs and no more. If you limit that current flow you will drop the voltage and that is not good. If the circuit does draw too much and you need more time then you either have to use a larger cap or change the circuit to draw less power.
Dazed_dnc:
If I could save the last programmed temperature value to non-volatile memory, that would help shave off some time. Eeprom has a relatively limited read/write lifespan though, which means I don't want to be writing to it every 100ms while my temperature adjustment loop runs.
Here's a wacky idea...
The DS1307 clock chip includes "56 bytes of battery-backed SRAM". And I believe that with the attached button battery its life (the battery's life) is good for 10 years.
You want to save a couple of bytes of information, frequently, in case the power goes off, and you need to re-establish what it was doing? Apart from the super-capacitor idea, which will probably work, how about this:
Connect up a DS1307 chip via I2C. Save what you need to its 56-byte SRAM memory (every time it changes). Being SRAM it won't wear out. Then after a reboot, just read it back.
This is an old Thread, but regardless, this information can used as a reference
Writing to a Battery backed up SRAM or an FRAM will not solve all the issues found with an EEPROM.
Power fault detection must still be present, as a power failure during a write will most certainly corrupt the data.
Avoiding an EEPROM can be advantageous in the sense that there are faster memories that require less power to write and therefore the chances of a brownout during write are limited. But this is the only real advantage, and to be fair it is questionable if it is worth the extra effort and hardware required (with the DUE being an exception).
johnwasser:
The datasheet says the EEPROM is good for at least 100,000 write/erase cycles. The EEPROM page size is four bytes. I suspect that EEPROM.write(), which can only write a single byte, will do four erase/write cycles if you write four consecutive bytes, even if those four bytes are in the same "page".
It also says that writing to EEPROM when Vcc is low is a good way to get corrupted EEPROM data.
I just stumbled over this old thread. Where does it say that EEPROM page size is four bytes?
olf2012:
I just stumbled over this old thread. Where does it say that EEPROM page size is four bytes?
In my datasheet, which is probably not current, on page 299 (section 27.5 "Page Size") it says that for the Atmega328P the EEPROM page size is 4 bytes.
Page size is only relevant when programming (e.g. ISP).
The EEPROM is byte-wise. Failures occur on single bytes. I'm too lazy to find the reference but it was confirmed by Atmel; I believe I found the details on avrfreaks.
