For some time now I have been looking at other ways to communicate between the controller and the LCD remote. A big part is that I now use a 2nd ATmega328 CPU on the remote LCD, and it now can do intelligent processing. The idea would be instead of the controller doing all the display rendering, it simply sends over status and the LCD figures out how to format and display it. So instead of sending "On line 2, column 4 put a '1', then a '4', then a '.' and finally a '3'" to update battery voltage, the controller will simply send "Battery voltage is now 14.3v".
In addition to distributing the work between the two controllers a bit, this also will allow more advanced options for the LCD display. Maybe adding a graphic, or some combination of key switches to select more modes of operation / configuration changes. And perhaps lower costs some as the P82B96's I2C extenders are getting more
costly every day, now at $3.10, and under $1.50 when I 1st started
An obvious approach is using ASCII strings much like the Arduino Alternator Regulator does. Sending and reciving via the serial port, likely using an RS-485 or RS-422 current loop to do the actual communications. Advantage is the ASCII is human readable, and easily connected to other devices ala PCs..
But I have also been looking into a CAN (Control Area Network) as a way to communicate. http://en.wikipedia.org/wiki/CAN_bus
This technology has been around a LONG time, is well developed, and parts are common as well as inexpensive. With 100's of CAN controllers in many automobiles, there are also a wide range of hardened components out there. It is what NMEA-2000 is built upon.
Using CAN would allow me to have one wire connected between the controller and the LCD remote. But it also would allow for things like moving all the battery senders off the controller and on to its own little board located at the battery and connected via one wire into the CAN bus. Vbat, Amps, and Temperate. More so, this same information could be shared with a CAN enabled Alternator regulator.
Though the low-level hardware stuff is standardize, how information is communicated is a different thing. There are several 'standards' out there for packaging up data to send over a CAN bus - NMEA2000 being one, but lots others as well. And beyond that, most deployments tend to define their own standards...
And one downside to CAN: it is NOT human readable, one needs a PC to receive the data and 'translate' it into something usable for people's eyes. But that is not that hard, CAN-USB adapters are available for under $10 - mostly by the auto guys who want to tap into cars CAN networks. And a small program is not that hard to write to convert... Once you know the 'standard' begin used to communicate over the hardware. And I think even if going to CAN bus, would need to retain the Service port / ASCII interface.
My head is spinning more then anything at this time, I welcome any comments from people about the CAN bus and its usability...