I spent nearly the entire day implementing the new menu system in my dual-Atmega-based Solar controller system. The new menu system doesn't provide all that much additional functionality; everything it can do I could also do remotely from the comfort of my computer. But sometimes it's more convenient to be able to make changes while down in the basement, and using menus I can manipulate on an LCD using a multifunction television remote, that's something I can now do. It also makes it easier to tell someone over the phone how to make a necessary change should I happen to be away during an unforeseen solar energy collection crisis. For me, though, the perhaps the biggest reason to implement an remote-controllable menu system was as a proof of concept and to develop a framework for other future projects. LCD-based menus are very important configurators for otherwise-faceless devices.
Last night I'd made a minor breakthrough on the menu system that permitted me to accurately edit temperature values (what I refer to in the code as "non-delimited values," as opposed to time and and date, which contain colons and dashes, respectively).
To get the menu system working, I would have to do a lot of switching between developing code for the slave and the master, and the trouble of having to run down to the basement every time I switched from one to the other was too much, so I just brought the controller upstairs and plugged it into a short serial port.
As previously mentioned, the behavior of the entire system had been controllable by commands sent to the master via a serial terminal window. I'd type in something like "sx 156" and the controller would know that now it should switch from heating hot water to heating the slab should the hot water in the household hot water tank reached 156 degrees. Since this system worked well, I wanted the menu system to patch into it. The goal was to get the results of various menu manipulations on the LCD to be some sort of command sent to the master. To make this work, though, I'd have to add a number of commands allowing me to change dates, times, and days of the week (because the only time-altering command I had was one that altered all time and date values at once).
So after implementing three different real-time-clock-altering commands and breaking out the command-processing code into a separate function, I had to work out the details of passing commands back to the master from the slave. For this, I chose a mail-like system. The slave cannot tell the master to do anything, but it can make messages for the master to pick up when it polls the slave for information. So I made a way for the slave to assemble commands from the menu system for the master to pick up every time it polled the slave for commands. One of those commands was to tell the master to update all the defaults for the menu system (should, for example, a menu session be abandoned without an explicit call to implement the changes that were made). To send such defaults, I expanded an existing system allowing the master to set EEPROM values and toggle output pin states in the slave.
Up until today, I'd only tested the menu system as serially-sent data strings, and getting it to work in the LCD display wasn't difficult at all. The main thing I needed to add was a facility for clearing the screen so random bits from previous screens wouldn't be displayed in the parts not overwritten.
By the end of the day, the interface was working nearly as well as the kind you find on a laser printer, a cellphone, or other device that provides a multi-line text-based menu system.
See it in action here:
I'll be keeping updates to the solar project on its own solar project page. That's where you can go to see diagrams and download the latest source code.
