Peter,

Character LCD's have a resident controller that scans a dot-matrix array of elements and turns them "on" or "off" as needed.

The reason for the 40 microsecond delay on the shortest command is that it takes time for the device that's doing all that to figure out what it's been told to do and how to do it, then complete the operation. Driving the dots in a dot-matrix array means switching each of quite a number of elements on and off at regular intervals, along with the underlying operations required for the scanning task. CMOS devices dissipate power in switching from one state to another as well as by sourcing or sinking current. They clearly don't have deal with much current in this case, but they do have to switch quite frequetly, and that uses power, what's more, it uses power all the time.

With a "normal" 7-segment, 4-digit + colon display, there are only 29 segments that have to be switched. Those have to be switched quite infreuently, typically 30 Hz and the switching involves only those 29 segments and the backplane. If you simply xor the segments to be turned "on" with the backplane potential, which you toggle every 60th or 30th of a second, they'll remain "on." That's not complicated, though, if you're using a 40 pin dil package, you may run out of pins. You need 29 of them to drive the displays, and you'll need two such displays. There are more complex ways of driving such displays, however, and those might offer opportunities to multiplex and save on pins. If you can find the old 1988 Hitachi LSI databook, #U74, which I have in my lap right now, it may provide you with some guidance as to how you might do that despite the fact that it doesn't address that type of display.

Perhaps it would be easy enough, and inexpensive enough, to use two MCU's, one for each display. They can share a common timebase if you use an external but shared oscillator, though I wonder if that wouldn't increase the power consumption as opposed to a crystal. The amount of switching per segment per second is a good indicator of the power usage, though the MCU will use a fair amount as well. However, I suspect it will be significantly less than what's used by the dot-matrix scanning done in the character LCD.

That HD44780 has to go through each and every dot at essentially the same rate as you'd have to scan your segments. If you drive the segments with a byte, there are only 10 values you'd have to store in a lookup table. I think it would be much less complex than what the MCU core in the HD44780 has to do, hence, would probably use quite a bit less power, and, of course, operate at a much lower rate. Just don't lose sight of the fact that, no matter what you choose to do, nothing is "free." Some things can become "free" if you eliminate waste, however, and the self-scanning dod matrix display that the character LCD provides may turn out to be mostly waste, since you don't need most of the rather convenient features it has to offer. You only need eight digits and two colons, not the entire character set, and the programmable character set, etc. Moreover, if you're actually going to develop a chess clock, some LCD makers might be willing to provide you not only samples, but recommendations with respect to driving techniques, mounting techniques, sources for suitable bezels, etc. Even if you have to pay for samples, which is seldom the case, it will be asier if not cheaper, and it will use less power than a character display. You may find that you can use a low-frequency resonator rather than a higher frequency crystal oscillator. The relative precision is not terribly critical, so long as you are under, say, 100 milliseconds per hour. Only you, of course, can determine what your precision requirement is.

I'm not saying you have to do any of these things, but considering them might help you find the optimal way in which to do what you need to do. I suspect that battery life will be a large factor in your design. Slower means lower-power.

RE