Forums

7-segment LCD to BCD decoder ?

Started by N_Cook October 5, 2014
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*.
On 10/7/2014 2:52 AM, N_Cook wrote:
> I'll have to check out that potential snag-pit first, before moving on to > sorting out how to program PAL/GAL. Somewhere I have an EPROM blower/copier > ,whether GAL capable, no idea
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).
On 10/7/2014 3: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.
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*.
On 07/10/2014 13:14, Don Y wrote:
> On 10/7/2014 3: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. > > 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
On 10/7/2014 6:01 AM, N_Cook wrote:
> On 07/10/2014 13:14, Don Y wrote:
>> 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..."
On 07/10/2014 14:11, Don Y wrote:
> On 10/7/2014 6:01 AM, N_Cook wrote: >> On 07/10/2014 13:14, Don Y wrote: > >>> 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
On Tuesday, October 7, 2014 6:01:13 AM UTC-7, N_Cook wrote:
> On 07/10/2014 13:14, Don Y wrote: > > On 10/7/2014 3: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 . So, you would rather solder several chips than one GAL.
> >> Plus perhaps some level shifting or inversions and just considering 1 =
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.
> > You have the same problem -- WHEN do you look at the output of your "co=
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.
> > 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 interv= al -- like one BP cycle) say "199"? Or, "109", "190", "00", etc.
>=20 > > Again, you need to characterize your data source before you start tryin=
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*.
>=20 > yes, fair comment. For this use an update as infrequently as once per min=
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 =20 ; 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 <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
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. -- Rick
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. >
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