Atmega328p, eeprom burnout and interupts

Question

Dear Community I build myself an atmega328 based temperature controller to actuate relays in order to control beer fermentation temperature in a fridge. I am fairy happy with what I have so far. The control works well, 2 buttons are used to change the desired temperature and two buttons are used to change the allowable range in witch to keep the fermentation temperature. The temperature probe is a LM35 which is sealed with epoxy and heat shrink and is housed in a stainless steel probe submerged in the fermenting wort (you beer). It takes 10 temperature reading in 40 ms as as average (this is to avoid resonance with 50 Hz AC power, I might be a fool, comment welcome), it then adds these averaged readings into a array creating a rolling average. I have tested the temperature readings at our local electronics department (lucky to be in a university environment) and it is pretty close to truth. In void loop I don't use delay, I rather use this kind of settup: void loop() {
 //use millis for timing 
 unsigned long curMillis = millis();

if (curMillis - prevMillis >= sleep){
 prevMillis = curMillis;

bla bal bla sleep is set to 250 ms. I have found that this works well with the buttons. The problem: Due to my lack of knowledge I am writing 4 times a second to eeprom addresses in order to save setting in case of a power interruption. Just today I read about eeprom burnout. So if I understand it correnctly: 100 000 / 4 = 25 000 ms, thus if the eeprom address gets burned out after 100 000 write events, then that address will only last for about 25 seconds. So what happens now is that whenever there is power interruption the set range seems to be anything random, like 124.3 deg C, which is not ideal for making beer. I think a solution to this problem would be to only write to the eeprom if anything changes just by comparing the eeprom value to the current value in the loop, maybe also add timing - not sure. I found some code here: EEPROM advanced usage on Arduino Uno / ATMega328 | Michael Bouvy " Read / write operations on EEPROM should never be interrupted : you should always disable/clear interrupts ( cli() ) before any operation and re-enable/set interrupts after ( sei() ). " So in the link above it is suggested that one disables interrupts while writing. From this link: http://playground.arduino.cc/Main/AVR " Note that the millis timer, and serial communication will be affected by disabling interrupts. The delayMicroseconds() function disables interrupts while it is running. " What do you guys think? I am not sure how millis timer and serial will be affected and also do you think it is that important to disable interrupts during during read write? I know nothing about interrupts. What would be best practice? Thanks for reading.

bobcroft · Answer

Armand, I suggest you look at EEPROMex library which has the ability, I believe, to only write to the EEPROM if the data being written is different to that already stored in the EEPROM. The other way you could minimize EEPROM writes is to first read the value stored in your EEPROM and compare it to the current value it they are the same or within acceptable bounds, then you do not need to write the new value to the EEPROM. Otherwise I think you are sampling the temperature far too frequently as there is no way your process can respond in anything like a 40mSec period. Averaging the readings is an excellent idea but I would think that if you sample the temperature at a frequency of once a minute that would more than adequate and probably still too fast. A lot depends on the volume of liquid you are heating / cooling and the amount of energy available for heating / cooling. If for example you consider heating then too large a heater will cause the process to overshoot the target temperature whereas too little heat will make the process slow to respond. There is a cheap software package called Meguno Pro which is very cheap and available as a free trial. This package can log data and continuously graph the data. It would be very informative for you to log your process and see what sort of response in terms of temperature change over time you got. I hope that helps but if you need more help please come back. Bob

mcb1 · Answer

So what happens now is that whenever there is power interruption the set range seems to be anything random, like 124.3 deg C There is no reason why you can't write the set temperature to the eeprom and then read it during the start process. I'd be including in void setup(), and you can check to see if the range is valid, and if not either stop the process or set it to something suitable, and drive an output, etc. I do question whether your sensor will actually change at all during the 40mS period, as the thermal mass alone would suggest it won't respond that fast. If the power goes out, your process will stop, and depending on how long it is before it resumes, the stored temp may have no bearing on the current temperature, so how storing the temperature affects the 'set' temperature, I'm not sure. The 100,000 write cycles is a minimum guarantee by the chip maker. If you hunt in the Arduino.cc forums, there was some experiments several years ago and they found it to exceed that by a factor of 10 or more, and that wasn't even optimizing the writing across the whole eeprom. As an alternative why not write when it changes by 0.x degrees, or even every 40th read (10 seconds) It looks like an interesting project so I hope you share the compete thing when you've resolved it. Mark

mcb1 · Answer

Armand There is always a first time for everything. The arduino forums allow searching, which seems to work better than here IMO. If you are only writing the set and range to eeprom, I think you'll never wear it out. You can read as many times as you like, its just the write cycles that have a limit. Unless you add a real time clock (entirely possible and cheap), you cannot tell how much time has passed if it is depowered/reset as the Millis() starts at 1 at startup. You could write to eeprom the state you are in (0,1,2,3) and even how many minutes within that if you wanted to. ie Location 10 = 1 if you are in heat cycle, and Location 11 is the number of minutes you've been heating for (0-255), 20 =1 if you are cooling, 2 1 is the number of minutes you've been cooling for (0-255), etc. As far as I know each location has a finite number of write cycles, so yes the others should be fine. If you really wanted to get picky, you could write and then read it to ensure it works, and use the first locations as some pointer to where the data is. On the other hand just buy a new chip, and start fresh ... Mark

mcb1 · Answer

Personally I've never had an application that requires brown-out detection (yet but one is coming up), and hence never considered it. I prefer to use external watchdogs, regardless of the internal capabilities of the uP. Many of them include brown-out detection, and cost a few dollars. If it's that critical, then I'd suggest looking at using one. If you are really concerned, you could detect the incoming voltage, have a large capacitor across the uP supply, and act accordingly. You could also add a LiPo battery just to to hold the uP while you shut down. Some of the Arduino boards include the option for a LiPo and include the charging cct. Nick gammon has a good guide to power saving here. http://www.gammon.com.au/forum/?id=11497 and at 100nA you'd probably never have to worry about it EVER. I'm not sure what the process is when writing to the eeprom, and how its affected by a brown-out. As you can see there are several ways to overcome the problem, it's what suits you best. Mark

Atmega328p, eeprom burnout and interupts

Top Replies