There's been a persistent problem with my Arduino solar sufficiency controller since all the recent shell scripty enhancements, and for much of this morning I was convinced that it was resulting from stack overflows. Using the new shell script, I'd write an arbitary long word into an arbitrary spot in the EEPROM (okay, it was my old Los Angeles street address — 12121 — into the location 55). But then when I'd go to check it, the value I'd stored would be garbled. I tried other addresses and sometimes the values were garbled and sometimes they weren't. What was going on? So I put in some debugging code just before the firing of the "storelong" function, but there was nothing unusual about the way it was being called by my parsing function. Code within storelong itself revealed it was being called multiple times immediately after I made my change, but why? It seemed like the command to call the function was being put back on the stack by a memory overflow, but why would it always specifically be the storelong function? Was it because of where I declared it? Was it because of its call to my homemade pow function?
I was about to post my code to the Arduino forum in search of überhelp when I decided to try my code on an Arduino not attached to my solar controller circuitry, which is what a helpful person in the forum would do. But I found that in a detached Arduino, the mysterious behavior I'd been observing in the solar controller Arduino wasn't happening. However, the storelong function was firing numerous times seemingly randomly. I quickly realized that this was the logging of extremes of temperatures on the sensors, which, unconnected, were generating scads of random readings, some more extreme than others. Wait a minute, I thought, and I looked at where those extreme data records were being logged. It turned out that location 55 was the location of a byte representation of the record temperature for the pipe coming from the solar panel when it arrives in the boiler room. Since I'd been experimentally storing a long at this location, I'd been overwriting the temperature and the lowest three significant bytes of the longword representing the time of that record (the longword representing the time of the record temperature was the four bytes following the byte of the record temperature itself). It made sense that the Arduino would immediately overwrite that data if it happened to represent a temperature lower than one currently indicated by the boiler room sensor. The fact that I had such difficulty figuring this simple problem out is one of the many difficulties of debugging code with lots of quasi-asynchronous things going on.
At various points today, as physical relief from computer-centered work, I went down to my greenhouse site and continued digging out the basement. I filmed the start of one of these diversions for the readers who prefer not to read. You can hear the voice I use when I'm talking to the dogs and cats (though the voice is actually a little different for every individual critter):
