This is the relevant code in my UNO temperature controller:
if (solartempC >= minT && solartempC >= systemtempC + deltaT)
solarState = true;
else
solarState = false;
if (solarState == true) //solar collector must be enabled
{ digitalWrite (solarvalvePin, LOW);
lcd.print ("S");
if (heaterState == false)//start pump when heating = off
{ delay(2000); //wait for solarvalve to open
digitalWrite (pumpPin, LOW);
lcd.setCursor (16, 3);
lcd.print ("P");
pumpState = true;
}}
minT and deltaT are INT fields with default values of 30 and 5. They can be altered in small increments with up/down buttons only.
The code has been running for over a year now, until a few days ago when the controller allowed the solar collector temperature to reach boiling point without taking any action.
This is only possible if one of these INT values has been corrupted.
In the declaration section, the next field is an unsigned long timer.
Is it possible that an overflow in the timer can corrupt the adjacent INT field?
An Overflow of one field will normally have no effect on adjacent fields. The space required for one variable is reserved.
I disagree that this can ONLY happen if ... It could also happen if the Arduino, for whatever reason, stops running at all, if a sensor malfunctions, etc. This is why Systems often have a "heartbeat" Signal, for example an LED that is flashed on/off WITHIN the running program. If the program stops running, the LED stops flashing and the Thing can be fixed/rebooted/whatever.
The sketch is long, annoying and not relevant.
My question concerns just the theoretical possibility of a data field being currupted by an adjacent field where millis() after several months cause an overflow.
This is something I've seen frequently in Cobol programs when fields declarations are too short. How C++ handles an overflow I do not know.
JaBa:
An Overflow of one field will normally have no effect on adjacent fields. The space required for one variable is reserved.
I disagree that this can ONLY happen if ... It could also happen if the Arduino, for whatever reason, stops running at all, if a sensor malfunctions, etc. This is why Systems often have a "heartbeat" Signal, for example an LED that is flashed on/off WITHIN the running program. If the program stops running, the LED stops flashing and the Thing can be fixed/rebooted/whatever.
The Arduino kept on running, my heartbeat signal is the last character on the LCD where "+" and "X" are written at the start and end of the loop. Also the temperatures are continuously updated.
After a reboot the controller resumed normal operation.
The only way for one object to stomp on another object's memory space is for you to do it, usually with a wild pointer or index. (Or thinking that if you create a 5 element array, the element at index 5 is part of it.)
