# Methods to drive a multiplexed LCD with logic-level signals?

I've used such a technique in a couple of the products I've designed, but I've never seen anyone else do so. It's possible to drive a 3-way multiplexed LCD using a bunch of 74HC595's to generate an 8-way pattern that gives each "on" segment an RMS excitation of 0.866VDD, and each "off" segment an RMS excitation of 0.5VDD, an RMS excitation ratio of 1.73:1. By comparison, driving a conventional display with 1/2 bias (requiring that idle rows be driven to half-rail, but active rows and all columns be driven to the rails) yields an RMS "on" voltage of .707VDD and an "off" voltage of 0.408VDD--the same 1.73:1 drive ratio. Using a 1/3 bias would result in a somewhat better drive ratio, but require all row and column drivers to support four output voltage levels.

How have you used purely logic-level signals to drive a multiplexed LCD?

-
This is too strange a LCD. Please provide a link to a data sheet or expect it to be closed. –  Brian Carlton Mar 8 '11 at 1:50
@Brian Carlton: My first prototype drove an off-the-shelf 4.5-digit LCD from Digi-Key with 15 pins: 3 common wires, and four groups of three segment wires controlling nine segments each. In each group of nine segments, seven segments formed a digit, one was the left-side decimal point, and the other was either a leading minus, a leading "1", "BATTERY", or "CONTINUITY". I drove the LCD using a PIC 16C84 and two 74HC595 shift registers. The drive technique is one I invented back around 1996 or 1997. My question is whether anyone else has ever done anything similar. –  supercat Mar 8 '11 at 14:43
@Brian Carlton - actually this is the "normal" interface for a bare LCD of the segmented variety without an on-board controller as you would find in a cheap calculator or clock. –  Chris Stratton Nov 10 '11 at 16:58

The technique I use is to drive the common wires through all eight combinations of high and low (I think I used the sequence 000 001 010 100 111 110 101 011, though I don't think it really matters) and, for each common wire phase, drive the segment wires in such a way as to make at least two of the three segments correct. Which is to say, if C2..C0 are the common wires, and S2..S0 are the desired values of three segments which connect a particular segment wire to C2..C0, the output value should be high if (C2 xor S2)+(C1 xor S1)+(C0 xor S0) is at least 2.

As an example, suppose that one wants S0 to be dark and S1 and S2 to be light (so S2..S0 == 001). The eight phases, drive state of the segment wires, and the resulting states of S2..S0, are as follows (for each segment, Y/N indicates whether it's energized; an asterisk will indicate whether it's the correct state):

Com Drv S2 S1 S0
000  0  N* N* N
001  0  N* N* Y*
010  1  Y  N  Y*
100  1  N* Y  Y*
111  1  N* N* N
110  1  N* N* Y*
101  0  Y  N  Y*
011  0  N* Y  Y*


Notice that each segment will be in the correct state 3/4 of the time. The logic to generate the correct states is a little irksome, but to avoid bogging down my interrupt handler I compute the first four four output patterns when setting the display content, so my interrupt handler just has to output one of the four patterns, in regular or complemented form.

The only annoyance I've observed with this method is that at slower scan rates, changing the display content will sometimes cause 'ghosting' on segments which should be transparent in both the old and new values. This occurs because the segment may have gone from being incorrectly energized on the fourth 'beat' one frame, to being incorrectly energized on the first beat of the next frame'; the two consecutive energized 'beats' cause the segment to momentarily become visibly opaque. Avoiding this problem requires using a scan rate twice as fast as would otherwise be necessary to avoid flicker; to minimize power consumption, my application switches to a faster scan rate during active use, or a lower rate when it's showing a static screen.

-