7-segment LCD to BCD decoder ?

On 10/9/2014 11:01 AM, Don Y wrote:
> 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!

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

On 10/9/2014 11: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.  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.

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.


> A micro is probably required somewhere, but perhaps at the remote location.  The OP would need to serialize the data before sending the data.

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

On 10/9/2014 11:01 AM, Don Y wrote:
>
> 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!

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

> >>>> If you don't really care about the data coming out of the circuit, t=
hen simply hard-wire various outputs to arbitrary logic levels!
>=20
> >>> You sure can make a simple effort unduly difficult.
>=20
> >>> I have already posted how to deal with the timing issues.  The backpl=
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.
>=20
> >> 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 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.
>=20
> > 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.  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.
>=20
> 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.

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.

> Using the backplane as a clock greatly *reduces* the complexity of the ci=
rcuit since it gives you timing and means you only need to look at a  singl=
e phase.

> > A micro is probably required somewhere, but perhaps at the remote locat=
ion.  The OP would need to serialize the data before sending the data.
>=20
> 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.

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.

On 2014-10-09, edward.ming.lee@gmail.com <edward.ming.lee@gmail.com> wrote:
>
>> >> 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?

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 <jasen@xnet.co.nz> Gave us:

>On 2014-10-09, edward.ming.lee@gmail.com <edward.ming.lee@gmail.com> wrote:
>>

>> I am not aware of any 1 bit Flash or ROM, do you know any?
>
>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.



  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.

On Thu, 09 Oct 2014 06:34:52 -0400, rickman <gnuarm@gmail.com> wrote:

>You sure can make a simple effort unduly difficult.

+1

N_Cook <diverse@tcp.co.uk> wrote:
> Starting with an off-the-shelf commercial unit where the LCD display
> is driven off a uC, to give a remotely monitorable feed

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

> > Starting with an off-the-shelf commercial unit where the LCD display is driven off a uC, to give a remotely monitorable feed
> 
> Point a webcam at it.  Maybe add an LED or two to make sure the camera gets a good picture under all lighting conditions.

And drive/decode the webcam (likely USB) with 74XXX?  OP said no uC (micro) and/or mC (mini or max controller)

On Sat, 11 Oct 2014 11:41:28 -0700 (PDT), edward.ming.lee@gmail.com
wrote:

>
>> > Starting with an off-the-shelf commercial unit where the LCD display is driven off a uC, to give a remotely monitorable feed
>> 
>> Point a webcam at it.  Maybe add an LED or two to make sure the camera gets a good picture under all lighting conditions.
>
>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.