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
I am not aware of any 1 bit Flash or ROM, do you know any?
Instead of us just guessing, perhaps the OP can disclose his secret. What's driving the LCD?
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.
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...
Sorry, too early in the day: s/former/latter/
n simply hard-wire various outputs to arbitrary logic levels!
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.
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.
E.g., in a software-driven implementation where a muxed LED drive algorithm was previously used.
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!).
+1
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!]
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.
ion.
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.
cares about the validity of the data that he will then be transporting.
Not even single chip (per digit) GAL.
egrated" solutions!]
He got lots of time and money to burn?
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]
Yes, you are being overly concerned. If the timing of the segments slips with respect to the backplane, the display will dim. A small difference in timing will not be noticable, but if it becomes a significant portion of the cycle time it will significantly dim the display. LCDs have poor contrast to begin with and there is no reason to have the segments significantly out of phase. Assuming the backplane and segments are not far out of phase is a pretty durn good assumption.
-- Rick
If the controller uses a "relaxation" state it will dim the display. That is one of the problems with multiplexed displays, they are dimmer than a direct driven display.
Using the backplane as a clock greatly *reduces* the complexity of the circuit since it gives you timing and means you only need to look at a single phase.
The OP has clearly said "no MCU". He has not said what he intends to do with the data but this part of the design is not to have an MCU.
-- Rick
Oh yeah, I forgot to mention that if the segment drive slips relative to the backplane drive in an asymmetrical way it will create a DC bias on the LCD which will quickly ruin it. So yes, there is a requirement that the drive timing be controlled in some ways. Once you achieve that goal you have likely synchronized the segments and the backplane pretty closely.
There are poor assumptions and there are good assumptions. This one is a better assumption.
-- Rick
hen simply hard-wire various outputs to arbitrary logic levels!
ane 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.
practice, it *may* be true. But, can also NOT be true! You are ASSUMING th at the data driving the segments changes synchronous with the BPHz signal. There is nothing inherent in the design of simplex LCD glass that REQUIRE S that! A designer can violate that ASSUMPTION and never damage the glass
*nor* present visible artifacts to the user.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. Using the common as clock would require a very co mplicated state machine. OTOH, you can sample/scan all segments/common and resolve it in software.
is one of the problems with multiplexed displays, they are dimmer than a direct driven display.
Relaxation only makes sense when one or more segments are changing. The LC D controller might want to completely discharge all segments before driving any. This will have a more uniform transitions. But relaxation might onl y be applied randomly, depends on whether the display is changing or not.
rcuit since it gives you timing and means you only need to look at a singl e phase.
ion. The OP would need to serialize the data before sending the data.
with the data but this part of the design is not to have an MCU.
We can only tell him that it is very difficult to do so. However, he said the data will be transmitted remotely, or perhaps logged. It is very possi ble to have a micro or computer at the remote link, and driving the acquisi tion serially.
I thought I saw some during a search, but don't see them now, I suspect I may have mistaken RAM chips or serial ROMs.
-- umop apisdn
On 11 Oct 2014 01:41:48 GMT, Jasen Betts Gave us:
Heheheh... I just thought of an old EEPROM style device sealed in with little quantum dot UV diodes over each cell to zero all the bits selectively.
It would have a very slow refresh rate. ;-) (and some strange applications)
Quantum dots could be a one bit device. Use it to "write" an image of Jimi on a 1 cm square target. One pixel at a time.
+1
Point a webcam at it. Maybe add an LED or two to make sure the camera gets a good picture under all lighting conditions.
Matt Roberds
And drive/decode the webcam (likely USB) with 74XXX? OP said no uC (micro) and/or mC (mini or max controller)
Why? Matt's solution meets the O/P spec of remotely monitorable. No decode required.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.