On 08/10/2014 04:04, rickman wrote:> On 10/7/2014 6:46 AM, N_Cook wrote: >> As no fast response is required , would this work? I really don't want >> to get involved with GAL programming . >> Plus perhaps some level shifting or inversions and just considering 1 >> digit. >> A free-running all states sequencing BCD source, until inhibited. >> Feeding a CMOS 4543 (BCD to 7 seg LCD) , the backplane feeding the PH >> pin of the 4543. Then compare LCD 7seg pins and matching 4543 o/p pins >> with a couple of 4081 quad-AND packs ANDed together to provide an >> inhibit back to the BCD source. Taking overall output as the BCD source >> lines when inhibited. > > This seems rather Rube Goldburgesque. If you don't want to program a > PAL, there are plenty of other logic devices which can be programmed a > bit more easily. Unfortunately none of them come in low pin count > packages unless you want to work with fine pitch BGA type packages. So > the best approach really would be an MCU. > > But your idea is not without merit. You just need a little imagination > to get it to work. > > There are two problems people seem to complain about. The first is the > problem with the skew of the backplane and segments signals timing. The > other is the issue of clocking the circuit asynchronously. Clocking > seems to be the solution to both problems. Your LCD drive signals will > likely have slow edge rates compared to the logic you want to connect > anyway, so you need to deal with that too. > > The segments will be changing at the same time as the backplane relative > to the cycle rate which is in the ball park of 30 Hz to 100 Hz normally. > The ideal time to sample the LCD drive signals is a couple of > milliseconds after the backplane falls from high to low. Then the > segment drive signals will be positive logic making the rest much easier. > > So use an RC with a time constant of say 2 ms to drive an unbuffered > inverter such as the CD4049. The output of this buffer will provide a > delayed clock edge for registers to grab the state of the segment lines. > There may be a noise issue with the slowly changing input from the RC. > You can mitigate this by using a non-inverting buffer, the CD4050 with > a large value resistor (at least 10x the resistor in the RC) feeding > back from the output to the input. This will turn the input into a > Schmitt trigger and should solve any noise issues on the input. The > 4050 should be followed by an inverter so the clock registers the data > when the segments are in their high true state, or omitting the inverter > will require the logic to work with the low true state. > > This will update the values many times a second and always at a valid > time, so the outputs will always be valid. > > I don't know if anyone has mentioned this before, but you only need to > look at 5 segments to distinguish the 10 digits. > > a b c d e f g a b e f g > 0 : 1 1 1 1 1 1 - 1 1 1 1 0 1E > 1 : - 1 1 - - - - 0 1 0 0 0 08 > 2 : 1 1 - 1 1 - 1 1 1 1 0 1 1D > 3 : 1 1 1 1 - - 1 1 1 0 0 1 19 > 4 : - 1 1 - - 1 1 0 1 0 1 1 0B > 5 : 1 - 1 1 - 1 1 1 0 0 1 1 13 > 6 : 1 - 1 1 1 1 1 1 0 1 1 1 17 > 7 : 1 1 1 - - - - 1 1 0 0 0 18 > 8 : 1 1 1 1 1 1 1 1 1 1 1 1 1F > 9 : 1 1 1 1 - 1 1 1 1 0 1 1 1B > > So unless you need to this info as binary you can save the encoding > logic and ship/store five bits. Even if you encode the info, the logic > only needs to look at 5 inputs. > > If you want to encode the digits into four bits you may be able to find > some simple logic to change the 5 bits to 4 that you can implement using > CD4000 series logic. But... looking at the above table, maybe not. > > So your counter idea might work. It will require a 4 bit counter, the > BCD to 7 segment decoder and then something to compare with. I see they > still sell CD4063 chips. This will compare 4 bits, two will compare up > to 8 bits with a high true A=B output. You can use a CD4510 for the > counter and the CI- input will act as a low true enable resulting in the > counting stopping when the segment values match. This match indicator > can be sent along with the data to clearly show when you have valid > outputs. >I was thinking of using a 4510 I'll add Heath Robinson = Rube Goldberg to my translator page http://www.divdev.fsnet.co.uk/tool_terms.htm
7-segment LCD to BCD decoder ?
Started by ●October 5, 2014
Reply by ●October 8, 20142014-10-08
Reply by ●October 8, 20142014-10-08
On 08/10/2014 00:46, petrus bitbyter wrote:> N_Cook <diverse@tcp.co.uk> wrote in news:m10g9t$le9$1@dont-email.me: > >> As no fast response is required , would this work? I really don't want >> to get involved with GAL programming . >> Plus perhaps some level shifting or inversions and just considering 1 >> digit. A free-running all states sequencing BCD source, until >> inhibited. Feeding a CMOS 4543 (BCD to 7 seg LCD) , the backplane >> feeding the PH pin of the 4543. Then compare LCD 7seg pins and >> matching 4543 o/p pins with a couple of 4081 quad-AND packs ANDed >> together to provide an inhibit back to the BCD source. Taking overall >> output as the BCD source lines when inhibited. > > You'r asking for a decoder but it seems that you miss the real problems. > > FAIK you have a four digit, seven segment, one plain, static driven LCD > display. So I expect you to have twenty eight segment lines and one > common. Among the things you need to know are the frame rate and the > signal levels. The latter may depend on the contrast setting of the > display. * Now the first thing to decide is how to get the data from > those twenty nine signal lines into the decoder.* > > The decoder itself may by build with a micro, a programmable device like > the GAL22V10 mentioned, (E)PROMS, a huge box of logic gates with some > square feet PCB or a bucket of diodes with some more PCB to make diode > matrices. Off course the design of the decoder will have direct > influenze on the interface. But there is more. > > What do you want to do with the data that comes out of the decoder? Send > it to a remote place but I don't expect you to use a seventeen plus wire > cable so what is your transmitter? * So the second problem is how to get > the data from the decoder into the transmitter.* This has direct impact > on the first problem mentioned and vice versa. > > Straight forward, knowing the signal levels, you can take the level > shifting electronics required and connect the outputs directly to the > decoder. Asuming you choose a tranmitter that can handle the sixteen > bits, connect the output of the decoder to the tranmitter a let it send > the sixteen bits of data continuously. Of course you will need some kind > of protocol to make sure that the bits are interpreted correctly at the > receiving side. Every now and then some nonsense will arrive as there > will be glitches on every edge of the frame clock but that will be > corrected by the next reception. *If you can live with this, both > interfacing problems are solved.* > > ... But only if you have that sixteen bits transmitter. If not you will > need some extra logic like buffers depending on the transmitter. > > As for the decoder itself, as you do not want to use a micro you will > fall back on programmable devices like the GAL22V10s or EPROMS. As you > have an EPROM programmer, EPROM seems the way to go. Every 27xx can > decode a digit. From 27128 upward you can even do two digits with it. > Using simple gates requires a big and expensive design and diode > matrices are just a joke (though it can be done). > > For myself I'd prefer a more robust design. I'd look at the common line > waiting for the rising edge of the frame clock. Then wait about a > quarter of a frame time and then put the sixteen bits in the > transmitter. Not util all bits are sent I'd start looking at the common > line again. > > petrus bitbyter >A lot of useful ideas there, I'll have to test out the preliminary stage, with 1 digit, if that works , then onwards. With luck there will be something useful as a clock source on the uC of the off-the-shelf device. Even the professional 1500 GBP kit has the odd glitch in the output. 15 GBP for a commonly available near equivalent for the sensing and display device, plus a bit of my time , for a useable device is well worth trying
Reply by ●October 8, 20142014-10-08
On 2014-10-08, Reinhardt Behm <rbehm@hushmail.com> wrote:> How about using an old style EPROM for decoding? Would be a waste of storage > space but easy to program and they still come in DIP packages.hmm... 16Kx8 14 address lines, 8 data lines, enough to decode 2 digits :) -- umop apisdn
Reply by ●October 8, 20142014-10-08
> I don't know if anyone has mentioned this before, but you only need to look at 5 segments to distinguish the 10 digits. > > a b c d e f g a b e f g > 0 : 1 1 1 1 1 1 - 1 1 1 1 0 1E > 1 : - 1 1 - - - - 0 1 0 0 0 08 > 2 : 1 1 - 1 1 - 1 1 1 1 0 1 1D > 3 : 1 1 1 1 - - 1 1 1 0 0 1 19 > 4 : - 1 1 - - 1 1 0 1 0 1 1 0B > 5 : 1 - 1 1 - 1 1 1 0 0 1 1 13 > 6 : 1 - 1 1 1 1 1 1 0 1 1 1 17 > 7 : 1 1 1 - - - - 1 1 0 0 0 18 > 8 : 1 1 1 1 1 1 1 1 1 1 1 1 1F > 9 : 1 1 1 1 - 1 1 1 1 0 1 1 1B > > So unless you need to this info as binary you can save the encoding logic and ship/store five bits. Even if you encode the info, the logic only needs to look at 5 inputs.You also have to look at inversed output; otherwise, it would be incorrect half of the time. Notice that '1' and '6' are indistinguishable without checking the common. a b c d e f g a b e f g a b e f g 0 : 1 1 1 1 1 1 - 1 1 1 1 0 1E 01 0 0 0 0 1 1 : - 1 1 - - - - 0 1 0 0 0 08 17 1 0 1 1 1 2 : 1 1 - 1 1 - 1 1 1 1 0 1 1D 02 0 0 0 1 0 3 : 1 1 1 1 - - 1 1 1 0 0 1 19 06 0 0 1 1 0 4 : - 1 1 - - 1 1 0 1 0 1 1 0B 14 1 0 1 0 0 5 : 1 - 1 1 - 1 1 1 0 0 1 1 13 0c 0 1 1 0 0 6 : 1 - 1 1 1 1 1 1 0 1 1 1 17 08 0 1 0 0 0 7 : 1 1 1 - - - - 1 1 0 0 0 18 07 0 0 1 1 1 8 : 1 1 1 1 1 1 1 1 1 1 1 1 1F 00 0 0 0 0 0 9 : 1 1 1 1 - 1 1 1 1 0 1 1 1B 04 0 0 1 0 0
Reply by ●October 8, 20142014-10-08
On Wednesday, October 8, 2014 4:26:43 AM UTC-7, Jasen Betts wrote:> On 2014-10-08, Reinhardt Behm <rbehm@hushmail.com> wrote: > > > How about using an old style EPROM for decoding? Would be a waste of storage space but easy to program and they still come in DIP packages. > > hmm... 16Kx8 14 address lines, 8 data lines, enough to decode 2 digits :)But you can't serialize the data like the GAL. If you can program high voltage EPROM, you can program GAL22V10. If not, there are 5V or 3V programmable ATF22V10 from Atmel. OP's choices are PAL/GAL, micro and FPGA.
Reply by ●October 8, 20142014-10-08
On 08/10/2014 04:04, rickman wrote:> On 10/7/2014 6:46 AM, N_Cook wrote: >> As no fast response is required , would this work? I really don't want >> to get involved with GAL programming . >> Plus perhaps some level shifting or inversions and just considering 1 >> digit. >> A free-running all states sequencing BCD source, until inhibited. >> Feeding a CMOS 4543 (BCD to 7 seg LCD) , the backplane feeding the PH >> pin of the 4543. Then compare LCD 7seg pins and matching 4543 o/p pins >> with a couple of 4081 quad-AND packs ANDed together to provide an >> inhibit back to the BCD source. Taking overall output as the BCD source >> lines when inhibited. > > This seems rather Rube Goldburgesque. If you don't want to program a > PAL, there are plenty of other logic devices which can be programmed a > bit more easily. Unfortunately none of them come in low pin count > packages unless you want to work with fine pitch BGA type packages. So > the best approach really would be an MCU. > > But your idea is not without merit. You just need a little imagination > to get it to work. > > There are two problems people seem to complain about. The first is the > problem with the skew of the backplane and segments signals timing. The > other is the issue of clocking the circuit asynchronously. Clocking > seems to be the solution to both problems. Your LCD drive signals will > likely have slow edge rates compared to the logic you want to connect > anyway, so you need to deal with that too. > > The segments will be changing at the same time as the backplane relative > to the cycle rate which is in the ball park of 30 Hz to 100 Hz normally. > The ideal time to sample the LCD drive signals is a couple of > milliseconds after the backplane falls from high to low. Then the > segment drive signals will be positive logic making the rest much easier. > > So use an RC with a time constant of say 2 ms to drive an unbuffered > inverter such as the CD4049. The output of this buffer will provide a > delayed clock edge for registers to grab the state of the segment lines. > There may be a noise issue with the slowly changing input from the RC. > You can mitigate this by using a non-inverting buffer, the CD4050 with > a large value resistor (at least 10x the resistor in the RC) feeding > back from the output to the input. This will turn the input into a > Schmitt trigger and should solve any noise issues on the input. The > 4050 should be followed by an inverter so the clock registers the data > when the segments are in their high true state, or omitting the inverter > will require the logic to work with the low true state. > > This will update the values many times a second and always at a valid > time, so the outputs will always be valid. > > I don't know if anyone has mentioned this before, but you only need to > look at 5 segments to distinguish the 10 digits. > > a b c d e f g a b e f g > 0 : 1 1 1 1 1 1 - 1 1 1 1 0 1E > 1 : - 1 1 - - - - 0 1 0 0 0 08 > 2 : 1 1 - 1 1 - 1 1 1 1 0 1 1D > 3 : 1 1 1 1 - - 1 1 1 0 0 1 19 > 4 : - 1 1 - - 1 1 0 1 0 1 1 0B > 5 : 1 - 1 1 - 1 1 1 0 0 1 1 13 > 6 : 1 - 1 1 1 1 1 1 0 1 1 1 17 > 7 : 1 1 1 - - - - 1 1 0 0 0 18 > 8 : 1 1 1 1 1 1 1 1 1 1 1 1 1F > 9 : 1 1 1 1 - 1 1 1 1 0 1 1 1B > > So unless you need to this info as binary you can save the encoding > logic and ship/store five bits. Even if you encode the info, the logic > only needs to look at 5 inputs. > > If you want to encode the digits into four bits you may be able to find > some simple logic to change the 5 bits to 4 that you can implement using > CD4000 series logic. But... looking at the above table, maybe not. > > So your counter idea might work. It will require a 4 bit counter, the > BCD to 7 segment decoder and then something to compare with. I see they > still sell CD4063 chips. This will compare 4 bits, two will compare up > to 8 bits with a high true A=B output. You can use a CD4510 for the > counter and the CI- input will act as a low true enable resulting in the > counting stopping when the segment values match. This match indicator > can be sent along with the data to clearly show when you have valid > outputs. >I was not aware of 5 segment minimising, so rickman reduction rather than Quine McClusky reduction
Reply by ●October 8, 20142014-10-08
On 10/8/2014 9:54 AM, edward.ming.lee@gmail.com wrote:> >> I don't know if anyone has mentioned this before, but you only need to look at 5 segments to distinguish the 10 digits. >> >> a b c d e f g a b e f g >> 0 : 1 1 1 1 1 1 - 1 1 1 1 0 1E >> 1 : - 1 1 - - - - 0 1 0 0 0 08 >> 2 : 1 1 - 1 1 - 1 1 1 1 0 1 1D >> 3 : 1 1 1 1 - - 1 1 1 0 0 1 19 >> 4 : - 1 1 - - 1 1 0 1 0 1 1 0B >> 5 : 1 - 1 1 - 1 1 1 0 0 1 1 13 >> 6 : 1 - 1 1 1 1 1 1 0 1 1 1 17 >> 7 : 1 1 1 - - - - 1 1 0 0 0 18 >> 8 : 1 1 1 1 1 1 1 1 1 1 1 1 1F >> 9 : 1 1 1 1 - 1 1 1 1 0 1 1 1B >> >> So unless you need to this info as binary you can save the encoding logic and ship/store five bits. Even if you encode the info, the logic only needs to look at 5 inputs. > > You also have to look at inversed output; otherwise, it would be incorrect half > of the time. Notice that '1' and '6' are indistinguishable without checking the > common. > > a b c d e f g a b e f g a b e f g > 0 : 1 1 1 1 1 1 - 1 1 1 1 0 1E 01 0 0 0 0 1 > 1 : - 1 1 - - - - 0 1 0 0 0 08 17 1 0 1 1 1 > 2 : 1 1 - 1 1 - 1 1 1 1 0 1 1D 02 0 0 0 1 0 > 3 : 1 1 1 1 - - 1 1 1 0 0 1 19 06 0 0 1 1 0 > 4 : - 1 1 - - 1 1 0 1 0 1 1 0B 14 1 0 1 0 0 > 5 : 1 - 1 1 - 1 1 1 0 0 1 1 13 0c 0 1 1 0 0 > 6 : 1 - 1 1 1 1 1 1 0 1 1 1 17 08 0 1 0 0 0 > 7 : 1 1 1 - - - - 1 1 0 0 0 18 07 0 0 1 1 1 > 8 : 1 1 1 1 1 1 1 1 1 1 1 1 1F 00 0 0 0 0 0 > 9 : 1 1 1 1 - 1 1 1 1 0 1 1 1B 04 0 0 1 0 0You need to read my post again. I am proposing using the backplane signal as a clock which means you only see one phase of the segment drive. -- Rick
Reply by ●October 9, 20142014-10-09
On Tue, 07 Oct 2014 05:05:35 -0700, Don Y <this@is.not.me.com> wrote:>On 10/6/2014 10:48 PM, pedro wrote: >> On Mon, 06 Oct 2014 21:47:52 +0100, piglet <erichpwagner@hotmail.com> >> wrote: >> >>> On the simpler LCDs - I guess like this one the OP has, all segments are >>> driven with AC all the time (so the suggestion of rectifying would not >>> be much help) but the "unlit" segment will be in-phase with the >>> backplane and "lit" segments will be out-of-phase. The OP could recover >>> segment data by xoring with the backplane or just latch segment data on >>> the appropriate backplane state. >> >> Exactly. No rocket science required. > >No. As I said, upthread: > "First, you'd need to characterize the drive -- how much skew is > there between backplane drive and segment on/off drives (any skew > will appear as potential glitches on a static, combinatorial > logic decoder so you would have to *sample* the decoded outputs > at some epsilon after each BP clock edge)." >You have no guarantee that the phase of the backplane has any fixed >relationship to the phase of the segment drive signals. It could >precede them -- or follow them -- or both (precede some, yet follow >others) -- or vary (temperature, value being displayed, etc.) > >Per OP: "off-the-shelf commercial unit where the LCD display is >driven *off* a uC" (also note that the OP conditions the request >with "not pic/Pi/uC" to capture the display data) > >[If you've got an MCU lying around, let it watch ALL segments >and trigger/sample BP drive from which it can derive an appropriate >segment sample time appropriately SKEWED from the BP to ensure >the segments are stable at their INTENDED levels] > >Nonmultiplexed displays have a great deal of tolerance as to what >is required to "illuminate" segments. As the outputs from the >"driver" (which is probably a programmed MCU and/or LSI) are >expecting to "see" an LCD, there, its unlikely that you will find a >formal specification (timing diagram) that indicates a fixed, >causal relationship between BP signal and segment drives. > >OTOH, any *logic* that you have hanging on those signals will be >very intolerant of phase differences between what you *thought* >(when the circuit was implemented) and what is actually happening >*now*.Generally, non-muxed LCD displays will have the drivers clocked by the backplane clock signal (a) in-phase - if the drivers invert active segments, or (b) anti-phase otherwise. Either way, a CRO on a segment and the BP will show the relative phase and display any lag/skew. A similar approach with muxed displays will again show any lag/skew. In either case, use that info to decide how to sample the segment data.
Reply by ●October 9, 20142014-10-09
On 2014-10-08, edward.ming.lee@gmail.com <edward.ming.lee@gmail.com> wrote:> On Wednesday, October 8, 2014 4:26:43 AM UTC-7, Jasen Betts wrote: >> On 2014-10-08, Reinhardt Behm <rbehm@hushmail.com> wrote: >> >> > How about using an old style EPROM for decoding? Would be a waste of storage space but easy to program and they still come in DIP packages. >> >> hmm... 16Kx8 14 address lines, 8 data lines, enough to decode 2 digits :) > > But you can't serialize the data like the GAL. If you can program high voltage EPROM, you can program GAL22V10. If not, there are 5V or 3V programmable ATF22V10 from Atmel. OP's choices are PAL/GAL, micro and FPGA.If you want serial use a 128Kx1 ROM and put a binary counter on the low order address lines, -- umop apisdn
Reply by ●October 9, 20142014-10-09
On 10/8/2014 10:40 PM, pedro wrote:> On Tue, 07 Oct 2014 05:05:35 -0700, Don Y <this@is.not.me.com> wrote: >> On 10/6/2014 10:48 PM, pedro wrote: >>> On Mon, 06 Oct 2014 21:47:52 +0100, piglet <erichpwagner@hotmail.com> >>> wrote: >>> >>>> On the simpler LCDs - I guess like this one the OP has, all segments are >>>> driven with AC all the time (so the suggestion of rectifying would not >>>> be much help) but the "unlit" segment will be in-phase with the >>>> backplane and "lit" segments will be out-of-phase. The OP could recover >>>> segment data by xoring with the backplane or just latch segment data on >>>> the appropriate backplane state. >>> >>> Exactly. No rocket science required. >> >> No. As I said, upthread: >> "First, you'd need to characterize the drive -- how much skew is >> there between backplane drive and segment on/off drives (any skew >> will appear as potential glitches on a static, combinatorial >> logic decoder so you would have to *sample* the decoded outputs >> at some epsilon after each BP clock edge)." >> You have no guarantee that the phase of the backplane has any fixed >> relationship to the phase of the segment drive signals. It could >> precede them -- or follow them -- or both (precede some, yet follow >> others) -- or vary (temperature, value being displayed, etc.) >> >> Per OP: "off-the-shelf commercial unit where the LCD display is >> driven *off* a uC" (also note that the OP conditions the request >> with "not pic/Pi/uC" to capture the display data) >> >> [If you've got an MCU lying around, let it watch ALL segments >> and trigger/sample BP drive from which it can derive an appropriate >> segment sample time appropriately SKEWED from the BP to ensure >> the segments are stable at their INTENDED levels] >> >> Nonmultiplexed displays have a great deal of tolerance as to what >> is required to "illuminate" segments. As the outputs from the >> "driver" (which is probably a programmed MCU and/or LSI) are >> expecting to "see" an LCD, there, its unlikely that you will find a >> formal specification (timing diagram) that indicates a fixed, >> causal relationship between BP signal and segment drives. >> >> OTOH, any *logic* that you have hanging on those signals will be >> very intolerant of phase differences between what you *thought* >> (when the circuit was implemented) and what is actually happening >> *now*. > > Generally, non-muxed LCD displays will have the drivers clocked by the > backplane clock signal (a) in-phase - if the drivers invert active > segments, or (b) anti-phase otherwise. Either way, a CRO on a segment > and the BP will show the relative phase and display any lag/skew. > > A similar approach with muxed displays will again show any lag/skew. > > In either case, use that info to decide how to sample the segment > data.As I said, LCD's have a great deal of leeway in how you can drive them and get *visible* results. If the drive frequency is buffered by one (internal) device as it feeds the backplane... and, *another* (e.g., an XOR) as it feeds each segment, you can't predict what the relationship of these two signals will be wrt each other without also knowing the characteristics of the buffers and the loads (C's) that each drive. And, that assumes the circuitry connected to the glass was actually *designed* to drive an LCD! OTOH, wiring a bunch of GPIO's to an LCD can give you the same drive capability (with appropriate software twiddling those bits) and highly variable drive characteristics! E.g., the software *could* opt to update segments 1, 9, 23 and 28. Then, toggle the backplane output. Then, update the remaining segments. If all of these actions happen at "processor speed" (i.e., within microseconds of each other), then the display will *never* exhibit any visual artifacts that could be correlated with this non "ideal" drive. Yet, any logic attached to those outputs EXPECTING them to behave "ideally" (or, at least, predictably) would be wonky. Likewise, there is no guarantee that the data that is being displayed is updated synchronously with the "display update cycle" (however you want to define *that*). Again, a human would never notice if digits 1 and 2 were updated to reflect their new values on the RISING edge of "BPHz" while digits 3 and 4 were updated on the FALLING edge of that same BPHz signal. Or, if this varied over time. You can *assume* whatever you want. And, *never* be assured that you've assumed correctly! ("Well, it works NOW so it will work ALWAYS!" ?? ) Years ago, you would drive simple glass with a multivibrator (e.g., a 555 or a periodic output from a processor). You would feed this *same* signal to an LCD 7 segment decoder (e.g., MC14543). So, you knew that the signal to the BP always preceded the signal available from the decoder(s) -- as it had to pass through additional gates in the decoder to reach the driven segments. Put a buffer in the signal to the BP -- but NOT in the path of the BPHz signal feeding the decoders -- and now you're looking at differences in propagation delays through different buffers (the one driving the BP and those driving the segments). [Imagine all this INSIDE an LSI!] Hang your logic on those pins (of the LCD!) and *wonder* what the phase relationship of those signals will ACTUALLY be... in ALL operating conditions! (Do you want it to work "once"? Or, *always*?? "Gee, it was working yesterday...") If you don't really care about the data coming out of the circuit, then simply hard-wire various outputs to arbitrary logic levels! :>
