7-segment LCD to BCD decoder ?

How are you expecting to get the "data" (in WHATEVER form) to your "remote display"?

Look at what you really *need* before settling on an implementation.

E.g., if the "display" was for a bathroom scale, chances are, the first digit will NOT be a '9' (as in 9XX).

You have the same problem -- WHEN do you look at the output of your "comparator"? When are the segment drives GUARANTEED to be "valid"? (you don't want to look at them until they *are*). You've just complicated this by oversampling with the free running counter...

You also have to consider how individual *digits* (digit positions) can change wrt each other. E.g., if the display said "99" and is now

*going* to say "100", is it possible for the digit drives to (for some brief interval -- like one BP cycle) say "199"? Or, "109", "190", "00", etc.

Again, you need to characterize your data source before you start trying to capture data from that source. The LC display is effectively a low-pass filter -- the human user doesn't notice if the display MAY have said "109" for 20 ms on its way between "99" and "100". But, your logic *will*.

yes, fair comment. For this use an update as infrequently as once per minute would be adequate, so plenty of room to put a monostable or something in there somewhere

Again, you still don't know *when* (in that "minute") to look at the data. Now? Or, maybe *now*? What about *NOW*??? :>

If you have something (MCU) with "smarts" that is looking at the data, then you can come up with *reasonably* safe estimates of "data stable". But, just looking at ~60-100Hz outputs (BP Hz) from your circuit will be hard to come to that sort of conclusion.

E.g., I had to design a "smart" interface to a scale, recently. The scale would provide me with it's instantaneous "estimates" of the mass present on its weighing platform. But, deciding when those "estimates" were representative of "actual" data isn't as simple as it should be (i.e., wait for them to damp down to some value that "doesn't vary much"?? for "some time interval"??).

"Ah, the value has been relatively stable for 2 seconds, now. This MUST be the actual weight!"

"Um, nope! The forklift operator hadn't fully disengaged the forks, yet. See the sudden 'disturbance' that's coming through, now? That's the change introduced by the forks FINALLY being withdrawn so the entire mass is resting on the weighing platform! Wait a little while longer..."

There is no H&S or safety-critical aspect, the input is always slowly varying over hours, anything wild of that , must be reading error , as long as it occurs less than say 10 percent of the time

to get involved with GAL programming .

So, you would rather solder several chips than one GAL.

digit. A free-running all states sequencing BCD source, until inhibited. Fe eding 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 coup le 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.

That's lots of chips involved, and it's not even going to work.

mparator"? When are the segment drives GUARANTEED to be "valid"? (you don' t want to look at them until they *are*). You've just complicated this by oversampling with the free running counter...

and forever free.

change wrt each other. E.g., if the display said "99" and is now*going* to say "100", is it possible for the digit drives to (for some brief interv al -- like one BP cycle) say "199"? Or, "109", "190", "00", etc.

g to capture data from that source. The LC display is effectively a low-pa ss filter -- the human user doesn't notice if the display MAY have said "10

9" for 20 ms on its way between "99" and "100". But, your logic *will*.

ute would be adequate, so plenty of room to put a monostable or something i n there somewhere

As someone pointed out, the LCD will be output alternating segment drives. My GAL code considers both normal and inverted codes. You would have to d ouble down on your chips, plus inverters. I don't even know how to handle your free running counter.

Z is common (backplane)

; Z A B C D E F G ; D7 D6 D5 D4 D3 D2 D1 D0 Q3 Q2 Q1 Q0 ; 0: 0 1 1 1 1 1 1 0 0 0 0 0 ; 1: 0 0 1 1 0 0 0 0 0 0 0 1 ; 2: 0 1 1 0 1 1 0 1 0 0 1 0 ; 3: 0 1 1 1 1 0 0 1 0 0 1 1 ; 4: 0 0 1 1 0 0 1 1 0 1 0 0 ; 5: 0 1 0 1 1 0 1 1 0 1 0 1 ; 6: 0 1 0 1 1 1 1 1 0 1 1 0 ; 7: 0 1 1 1 0 0 0 0 0 1 1 1 ; 8: 0 1 1 1 1 1 1 1 1 0 0 0 ; 9: 0 1 1 1 1 0 1 1 1 0 0 1 ; 0: 1 0 0 0 0 0 0 1 0 0 0 0

; 1: 1 1 0 0 1 1 1 1 0 0 0 1 ; 2: 1 0 0 1 0 0 1 0 0 0 1 0 ; 3: 1 0 0 0 0 1 1 0 0 0 1 1 ; 4: 1 1 0 0 1 1 0 0 0 1 0 0 ; 5: 1 0 1 0 0 1 0 0 0 1 0 1 ; 6: 1 0 1 0 0 0 0 0 0 1 1 0 ; 7: 1 0 0 0 1 1 1 1 0 1 1 1 ; 8: 1 0 0 0 0 0 0 0 1 0 0 0 ; 9: 1 0 0 0 0 1 0 0 1 0 0 1 ;

N_Cook wrote in news:m10g9t$le9$ snipped-for-privacy@dont-email.me:

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

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.

--

Rick

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.

--
Reinhardt

I was thinking of using a 4510

I'll add Heath Robinson = Rube Goldberg to my translator page

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

hmm... 16Kx8 14 address lines, 8 data lines, enough to decode 2 digits :)

--
umop apisdn

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

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.

I was not aware of 5 segment minimising, so rickman reduction rather than Quine McClusky reduction

You 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

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.

If you want serial use a 128Kx1 ROM and put a binary counter on the low order address lines,

--
umop apisdn

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! :>