On 10/9/2014 4:01 AM, Don Y wrote:> 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! :>You sure can make a simple effort unduly difficult. I have already posted how to deal with the timing issues. The backplane signal typically runs at 30 to 100 Hz and can be used as a clock if it is delayed by a millisecond or two. This is well slow enough that all the segments will be in their proper state and is fast enough to not be getting too close to the next transition for any segmented LCD display. -- Rick
7-segment LCD to BCD decoder ?
Started by ●October 5, 2014
Reply by ●October 9, 20142014-10-09
Reply by ●October 9, 20142014-10-09
> >> 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,I am not aware of any 1 bit Flash or ROM, do you know any?
Reply by ●October 9, 20142014-10-09
> > As I said, LCD's have a great deal of leeway in how you can drive them and get *visible* results. > > ...> I have already posted how to deal with the timing issues. > ...Instead of us just guessing, perhaps the OP can disclose his secret. What's driving the LCD?
Reply by ●October 9, 20142014-10-09
On 10/9/2014 3:34 AM, rickman wrote:> On 10/9/2014 4:01 AM, Don Y wrote:>> If you don't really care about the data coming out of the circuit, then >> simply hard-wire various outputs to arbitrary logic levels! :> > > You sure can make a simple effort unduly difficult. > > I have already posted how to deal with the timing issues. The backplane signal > typically runs at 30 to 100 Hz and can be used as a clock if it is delayed by a > millisecond or two. This is well slow enough that all the segments will be in > their proper state and is fast enough to not be getting too close to the next > transition for any segmented LCD display.No! You have no guarantee that ANYTHING of the sort will be true! In practice, it *may* be true. But, can also NOT be true! You are ASSUMING that the data driving the segments changes synchronous with the BPHz signal. There is nothing inherent in the design of simplex LCD glass that REQUIRES that! A designer can violate that ASSUMPTION and never damage the glass *nor* present visible artifacts to the user. If you don't care for the validity of the data coming out of your circuit, then naively "do whatever". And, don't fret when your assumptions fail. GUESSING at a design is not engineering. My first words on this subject: "First, you'd need to CHARACTERIZE THE DRIVE..." Come up with a "simple effort" and worry about the "unduly difficult" consequences! Bye.
Reply by ●October 9, 20142014-10-09
On 10/9/2014 7:29 AM, edward.ming.lee@gmail.com wrote:> >>> As I said, LCD's have a great deal of leeway in how you can drive them >>> and get *visible* results. ... > >> I have already posted how to deal with the timing issues. ... > > Instead of us just guessing, perhaps the OP can disclose his secret. What's > driving the LCD?From his original post (some of us read it): "off-the-shelf commercial unit where the LCD display is driven off a uC" What it doesn't say is whether the uC has a dedicated "LCD drive" subsystem or if the LCD is driven from GPIO's on the uC. In the former case, you can (conceivably) get data regarding the structure of the drive circuitry: when data is LATCHED, how the BPHz signal is propagated through to the segments and BP, etc. In the former case, all bets are off -- unless you can review the source code. As the display itself won't noticeably "misbehave" if it is driven in a "non-ideal" manner (e.g., data changing asynchronously wrt BPHz) a human user (which is who the display is INTENDED for -- not some piece of bolt-on electronics) would never notice if the data was changing at a "non-ideal" time (the glass has no explicit requirements that are being violated -- just keep DC off the glass). As I mentioned elsewhere: apply BPHz to the backplane and 2*BPHz (or BPHz/2) to the "segment drivers". Hold the data constant (or not). Then, with a 'scope, tell me what you *think* the "data" should be...
Reply by ●October 9, 20142014-10-09
On 10/9/2014 8:10 AM, Don Y wrote:> In the former case, all bets are off -- unless you can review the sourceSorry, too early in the day: s/former/latter/> code. As the display itself won't noticeably "misbehave" if it is > driven in a "non-ideal" manner (e.g., data changing asynchronously wrt > BPHz) a human user (which is who the display is INTENDED for -- not > some piece of bolt-on electronics) would never notice if the data was > changing at a "non-ideal" time (the glass has no explicit requirements > that are being violated -- just keep DC off the glass).
Reply by ●October 9, 20142014-10-09
> >> If you don't really care about the data coming out of the circuit, the=n simply hard-wire various outputs to arbitrary logic levels! =20>=20 > > You sure can make a simple effort unduly difficult. >=20 > > I have already posted how to deal with the timing issues. The backplan=e signal typically runs at 30 to 100 Hz and can be used as a clock if it is= delayed by a millisecond or two. This is well slow enough that all the se= gments will be in their proper state and is fast enough to not be getting t= oo close to the next transition for any segmented LCD display.>=20 > No! You have no guarantee that ANYTHING of the sort will be true! In pra=ctice, it *may* be true. But, can also NOT be true! You are ASSUMING that = the data driving the segments changes synchronous with the BPHz signal. Th= ere is nothing inherent in the design of simplex LCD glass that REQUIRES t= hat! A designer can violate that ASSUMPTION and never damage the glass *no= r* present visible artifacts to the user. For example, the LCD controller can hold the common/backplane constant and = drives the segments above and below the common. Furthermore, it could intr= oduce relaxation state where the segments and commons are equal, before dri= ving the next state. Using the common as clock would require a very compli= cated state machine. OTOH, you can sample/scan all segments/common and res= olve it in software. A micro is probably required somewhere, but perhaps at the remote location.= The OP would need to serialize the data before sending the data.
Reply by ●October 9, 20142014-10-09
On 10/9/2014 8:16 AM, edward.ming.lee@gmail.com wrote:> >>>> If you don't really care about the data coming out of the circuit, >>>> then simply hard-wire various outputs to arbitrary logic levels! >> >>> You sure can make a simple effort unduly difficult. >> >>> I have already posted how to deal with the timing issues. The backplane >>> signal typically runs at 30 to 100 Hz and can be used as a clock if it >>> is delayed by a millisecond or two. This is well slow enough that all >>> the segments will be in their proper state and is fast enough to not be >>> getting too close to the next transition for any segmented LCD display. >> >> No! You have no guarantee that ANYTHING of the sort will be true! In >> practice, it *may* be true. But, can also NOT be true! You are ASSUMING >> that the data driving the segments changes synchronous with the BPHz >> signal. There is nothing inherent in the design of simplex LCD glass >> that REQUIRES that! A designer can violate that ASSUMPTION and never >> damage the glass *nor* present visible artifacts to the user. > > For example, the LCD controller can hold the common/backplane constant and > drives the segments above and below the common. Furthermore, it could > introduce relaxation state where the segments and commons are equal, before > driving the next state.E.g., in a software-driven implementation where a muxed LED drive algorithm was previously used.> Using the common as clock would require a very > complicated state machine. OTOH, you can sample/scan all segments/common > and resolve it in software.At the very least, you can see if your "observations" make sense! "Hmmm... presumably, only the 10 valid digits will ever be displayed. Yet, the data that I just captured sure looks like a P! WTF??" "Hmmm... the display is supposed to be monotonically increasing. I recently saw a 99, then a 199, then a 190, then a 100... WTF??" Even if you can "reliably" capture the "intent" of the data (i.e., resolve any skew between BPHz and segment drive), you still have to know when wrt the BPHz signal itself the data is actually UPDATED (i.e., fed to the "output circuitry"). And, beyond "just a single digit", when AND HOW the "reading" is presented to the "display subsystem". (esp true for a software implementation). E.g., if you present the entire reading to the display system in an atomic fashion (so no "partial results" are visible -- even at 'scope speeds), then you have to create a lockable object... something that the "application" can lock, update and unlock and PREVENT the software (interrupt routine, most commonly) from accessing while it is locked (because portions of it may not yet be completely updated when the interrupt comes along to access them). OTOH, you can realize that only one process is altering the data (the "application") while the other is only *accessing* the data (the ISR). And, given that the display itself -- and the user viewing it -- don't really care when particular digits/segments are updated, why bother locking at all? If "partial results" get displayed, they'll only be visible "in transition" (and, the glass is "slow" anyway!).> A micro is probably required somewhere, but perhaps at the remote location.+1> The OP would need to serialize the data before sending the data.Put microcontroller at the device, acquire the display data, filter it as required (to accommodate the above issues) and ship "clean" data to the remote. Of course, the OP is still obligated to "characterize the drive" -- if he cares about the validity of the data that he will then be transporting. Unfortunately, the OP discounted this approach: "...discrete/CMOS/74 route , ie not pic/Pi/uC..." [For the life of me, I don't understand why folks shy away from more "integrated" solutions!]
Reply by ●October 9, 20142014-10-09
> E.g., if you present the entire reading to the display system in an atomi=c fashion (so no "partial results" are visible -- even at 'scope speeds), t= hen you have to create a lockable object... something that the "application= " can lock, update and unlock and PREVENT the software (interrupt routine, = most commonly) from accessing while it is locked (because portions of it ma= y not yet be completely updated when the interrupt comes along to access th= em). That's only a problem with slow uC based sampler. My GAL solution is essentially a digital scope. It can cascade and latch a= ll 28 segments and common at once, up to 250MHz (I got the 80MHz chips only= ). During the high speed hunt mode, the remote processor can control and s= ample the data, looking for phase transitions. Once locked, it can sample = at lower and more predictable sample rate. The GAL can run faster than the= LCD uC, to reliably phase locked to the uC clock.=20>=20 > > A micro is probably required somewhere, but perhaps at the remote locat=ion.>=20 > > The OP would need to serialize the data before sending the data. >=20 > Put microcontroller at the device, acquire the display data, filter it as=required (to accommodate the above issues) and ship "clean" data to the re= mote. You would need a micro several times faster than the LCD uC, and all I/O mu= st be in a single port. Even a PIC32MX won't work, since I/Os are 16 bits = in two ports.> Of course, the OP is still obligated to "characterize the drive" -- if he=cares about the validity of the data that he will then be transporting.>=20 > Unfortunately, the OP discounted this approach: >=20 > "...discrete/CMOS/74 route , ie not pic/Pi/uC..."Not even single chip (per digit) GAL. =20> [For the life of me, I don't understand why folks shy away from more "int=egrated" solutions!] He got lots of time and money to burn?
Reply by ●October 9, 20142014-10-09
On 10/9/2014 9:08 AM, edward.ming.lee@gmail.com wrote:>> [For the life of me, I don't understand why folks shy away from more >> "integrated" solutions!] > > He got lots of time and money to burn?<shrug> A device for "Reading a set of 7 segment displays on an electronic appliance" has been a common plea from the visually impaired community for *ages*! This is one of those delightfully simple APPEARING problems that takes on a whole new dimension when you actually try to tackle it! [Admittedly, this is considerably more than the OP has requested.] It underscores how much leeway there is in implementations of "displays and indicators" from a human perception point of view -- you can get away with a LOT in your display implementation and still end up with a viewable product! I've used that problem as a casual way of probing the strengths of job candidates, over the years. Spring it on them as a "personal pet project" over a lunch and see how tenacious they are in their solutions... how well they adapt to various "problems" that I present (differences in potential display implementations). How long they will volunteer solutions before they realize (*if* they realize!) the nature of the problem! When *I* first approached the problem (also thinking it to be "relatively simple"), I had amassed a pretty substantial sampling of "display implementations" that I had "observed" in that effort ('scope traces, logic analyzer dumps, etc.). It was disheartening to see how much variety there was -- yet how *easily* our brains comprehend what we are presented with, visually! The same is true of perceptions brought to us by our other senses. Humbling to see how much "processing" happens in the brain at a completely subconscious level! Making a machine interface to something designed for humans is usually a problem/bug waiting to materialize! The needs of machines and humans are significantly different. Mapping one domain onto the other is a poor approach. [e.g., like "screen readers" for blind users: screens aren't designed with the intent of being "read" -- which is a serial activity]