|
|
|
goad dog
Monday, April 11 2011
The weather forecast for today was that temperatures would reach into the upper 70s or low 80s, but well into the morning temperatures remained in the 50s. At some point in the early afternoon, Gretchen hopefully went out to the chaise lounge in the parking area saying she wanted to be "hot." The sun was coming and going and at first this didn't seem possible. But as the afternoon progressed, temperatures climbed through the 70s and eventually into the 80s.
At some point I drove into town to drop Tim's ties in the mail (he'd left them in our guest room), stop at the veterinarian to get a different antibiotic and fancy cat food in a last-ditch effort to cure Marie's (aka "the Baby's") diarrhea, which is now so uncontrolled and unstoppable that our entire upstairs smells like the Dutchess County SPCA. Unfortunately, the new cat food prescribed by our vet had to be made of either ground-up deer meat or ground-up rabbits. It's hard to live a vegan lifestyle when you surround yourself with carnivores. (Figuring it would result in fewer actual deaths, Gretchen opted for the ground-up venison.) While I was out, I also got a new axle and constant-velocity joint for the Honda Civic, which has been needing a replacement for over a year.
This evening I decided to run some tests on the Arduino-based solar controller to see how it would respond to a crash or other form of system freeze, the sort of event from which the watchdog timer should automatically be saving it. I have a number of commands I can issue to the controller in a telnet-style command line via the serial link, and I added a new one called "gd," which stands for "goad dog" (as in, goad the watchdog timer). I wanted to have a way to make the watchdog go unpetted to see what happened when it was triggered. My gd command simply initiated a 20 second cessation of all activity, well beyond the eight second maximum allowed by the watchdog timer. But when I goaded the dog, I found the controller got hung up during startup and couldn't be brought to life without me having to intervene (by cycling the power). The problem turned out to be the result of two unhelpful design choices: one in the Arduino bootloader and the other in the Atmel watchdog circuitry. It seems that when the watchdog timer triggers a reset, the Atmel chip goes into 35 millisecond watchdog mode, which is enabled for its next reboot. If you don't turn off the watchdog timer (or pet that dog) within 35 milliseconds of its next reboot, it reboots again. And again. And again. Until you turn it off. 35 milliseconds is not much time, but it should be possible to put some code in the init procedure to turn off the watchdog, pet the dog, or change it to the 8 second timeout I prefer. But that's where the Arduino bootloader gets in the way; it always takes a certain amount of time to do stuff before any of your own code runs, and that amount of time is longer than 35 seconds. Happily, there was a solution available. Someone in the Arduino community had generously written an improved Arduino bootloader called OptiBoot, and it either has code within it to turn off any watchdog settings or else it wakes the Arduino fast enough for your code to turn off the watchdog. Once I had OptiBoot in place, my goading of the watchdog resulted in flawless reboots and a quick return to normal functioning. Additionally, the IDE was now reflashing the microcontroller at a much higher baud rate, making reprogramming more effortless and giving me more interactivity. The elimination of annoying little delays does much for the comfort of working in an environment, and comfort is precisely what you need to fully articulate a programming vision.
For linking purposes this article's URL is:
http://asecular.com/blog.php?110411 feedback
previous | next |
