Forums

7-segment LCD to BCD decoder ?

Started by N_Cook October 5, 2014
On 10/5/2014 3:31 PM, edward.ming.lee@gmail.com wrote:
>>>>> Assuming one back-plane to consider , what would be most efficient component-count/least complex discrete/CMOS/74 route , ie not pic/Pi/uC to firstly convert the ex-oring business to proper levels and then the "mapping", output could be linear per digit rather than bcd. Starting with an off-the-shelf commercial unit where the LCD display is driven off a uC, to give a remotely monitorable feed >> >>>> 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). [epsilon can be large-ish if a MCU is "decoding in software". Also, consider temperature effects on the drive] >> >>> GAL can handle it, perhaps even pll/sampling the microcontroller clock. The GAL can run at 150MHz. >> >> You are missing the point. The display signals may not be 100% in lock step. So there may be invalid states for a brief time. > > You can oversample it and filter out the invalid states, assuming that the counter output does not change too much and too fast.
Where is that going to happen? The OP is asking to do this in the minimum logic possible and a 22V10 was suggested.
>>>> You would also need to look at the particular "font" that is implemented: do 6's have tails? what about 9's? (sometimes 6 will have but 9 won't). >> >>>> And, any "other characters" that the display might present from time to time (e.g., 'A', 'o', 'P', 'H', 'h', 'e', 'L', 'E', etc.) that might collide with some of the "don't cares" in your decoder logic. >> >>> Just details. GAL22V10 can handle any possible combinations of 7 inputs, or even up to 10 inputs. >> >> But there are limited product terms. How many product terms does each output have? You may need as many as 10 product terms. > > Eight for GAL22V10. Sixteen for NGAL16. > > So far, i need only five for this decoder. Four bit BCD have a maximum of five 1s. Look at my tables and equations.
Assuming you don't need to detect the blank state. We haven't heard back from the OP on that. -- Rick
On Sunday, October 5, 2014 12:34:15 PM UTC-7, rickman wrote:
> On 10/5/2014 3:31 PM, edward.ming.lee@gmail.com wrote: >=20 > >>>>> Assuming one back-plane to consider , what would be most efficient =
component-count/least complex discrete/CMOS/74 route , ie not pic/Pi/uC to = firstly convert the ex-oring business to proper levels and then the "mappin= g", output could be linear per digit rather than bcd. Starting with an off-= the-shelf commercial unit where the LCD display is driven off a uC, to give= a remotely monitorable feed
>=20 > >>>> First, you'd need to characterize the drive -- how much skew is ther=
e between backplane drive and segment on/off drives (any skew will appear a= s potential glitches on a static, combinatorial logic decoder so you would = have to *sample* the decoded outputs at some epsilon after each BP clock ed= ge). [epsilon can be large-ish if a MCU is "decoding in software". Also, c= onsider temperature effects on the drive]
>=20 > >>> GAL can handle it, perhaps even pll/sampling the microcontroller cloc=
k. The GAL can run at 150MHz.
>=20 > >> You are missing the point. The display signals may not be 100% in loc=
k step. So there may be invalid states for a brief time.
>=20 > > You can oversample it and filter out the invalid states, assuming that =
the counter output does not change too much and too fast.
>=20 > Where is that going to happen? The OP is asking to do this in the minim=
um logic possible and a 22V10 was suggested. Yes, just one GAL22V10. Sample, Load and Shift into the micro at 10MHz or = at fast as the micro can handle. Then filter out the invalid entries by so= ftware.
> >>>> You would also need to look at the particular "font" that is impleme=
nted: do 6's have tails? what about 9's? (sometimes 6 will have but 9 wo= n't).
>=20 > >>>> And, any "other characters" that the display might present from time=
to time (e.g., 'A', 'o', 'P', 'H', 'h', 'e', 'L', 'E', etc.) that might co= llide with some of the "don't cares" in your decoder logic.
>=20 > >>> Just details. GAL22V10 can handle any possible combinations of 7 inp=
uts, or even up to 10 inputs.
>=20 > >> But there are limited product terms. How many product terms does each=
output have? You may need as many as 10 product terms.
>=20 > > Eight for GAL22V10. Sixteen for NGAL16. >=20 > > So far, i need only five for this decoder. Four bit BCD have a maximum=
of five 1s. Look at my tables and equations.
>=20 > Assuming you don't need to detect the blank state. We haven't heard back=
from the OP on that. Blank state are 0s. It won't affect the possible logic 1s.
On 05/10/2014 20:18, rickman wrote:
> On 10/5/2014 2:20 PM, N_Cook wrote: >> just 0 to 9 digits, no alphamumerics, not even +/- > > What about blank digits? Will the digit always be one of the 10 values > or can it be off? >
The on condition but no reading state of the display is 00.00 but I can ignore the "." , its fixed range
 
> >> just 0 to 9 digits, no alphamumerics, not even +/- > > > What about blank digits? Will the digit always be one of the 10 values or can it be off? > > The on condition but no reading state of the display is 00.00 but I can ignore the "." , its fixed range
OK, can do it with 4 GAL22V10. Total cost of $1.32. My last posting of the Jedec file will work, even with my mistake in table entry. It will decode 0b1000 if segment G is on and 0b0000 if G is off. Blank state (if any) is also 0b0000.
On 10/5/2014 3:41 PM, edward.ming.lee@gmail.com wrote:
> On Sunday, October 5, 2014 12:34:15 PM UTC-7, rickman wrote: >> On 10/5/2014 3:31 PM, edward.ming.lee@gmail.com wrote: >> >>>>>>> Assuming one back-plane to consider , what would be most efficient component-count/least complex discrete/CMOS/74 route , ie not pic/Pi/uC to firstly convert the ex-oring business to proper levels and then the "mapping", output could be linear per digit rather than bcd. Starting with an off-the-shelf commercial unit where the LCD display is driven off a uC, to give a remotely monitorable feed >> >>>>>> 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). [epsilon can be large-ish if a MCU is "decoding in software". Also, consider temperature effects on the drive] >> >>>>> GAL can handle it, perhaps even pll/sampling the microcontroller clock. The GAL can run at 150MHz. >> >>>> You are missing the point. The display signals may not be 100% in lock step. So there may be invalid states for a brief time. >> >>> You can oversample it and filter out the invalid states, assuming that the counter output does not change too much and too fast. >> >> Where is that going to happen? The OP is asking to do this in the minimum logic possible and a 22V10 was suggested. > > Yes, just one GAL22V10. Sample, Load and Shift into the micro at 10MHz or at fast as the micro can handle. Then filter out the invalid entries by software. > >>>>>> You would also need to look at the particular "font" that is implemented: do 6's have tails? what about 9's? (sometimes 6 will have but 9 won't). >> >>>>>> And, any "other characters" that the display might present from time to time (e.g., 'A', 'o', 'P', 'H', 'h', 'e', 'L', 'E', etc.) that might collide with some of the "don't cares" in your decoder logic. >> >>>>> Just details. GAL22V10 can handle any possible combinations of 7 inputs, or even up to 10 inputs. >> >>>> But there are limited product terms. How many product terms does each output have? You may need as many as 10 product terms. >> >>> Eight for GAL22V10. Sixteen for NGAL16. >> >>> So far, i need only five for this decoder. Four bit BCD have a maximum of five 1s. Look at my tables and equations. >> >> Assuming you don't need to detect the blank state. We haven't heard back from the OP on that. > > Blank state are 0s. It won't affect the possible logic 1s.
I think that depends on the format of the data. Interpreting a blank as a zero can be a problem if it is the ls digit. -- Rick
On 10/5/2014 4:17 PM, N_Cook wrote:
> On 05/10/2014 20:18, rickman wrote: >> On 10/5/2014 2:20 PM, N_Cook wrote: >>> just 0 to 9 digits, no alphamumerics, not even +/- >> >> What about blank digits? Will the digit always be one of the 10 values >> or can it be off? >> > > The on condition but no reading state of the display is 00.00 but I can > ignore the "." , its fixed range
Are your digits multiplexed? How will you get the four digits into the PAL? -- Rick
> But there are limited product terms. How many product terms does each ou=
tput have? You may need as many as 10 product terms. Correction, it's not fixed number of 8: The GAL22V10 has a variable number of product terms per OLMC. Of the ten av= ailable OLMCs, two OLMCs have access to eight product terms (pins 14 and 23= , DIP pinout), two have ten product terms (pins 15 and 22), two have twelve= product terms (pins 16 and 21), two have fourteen product terms (pins 17 a= nd 20), and two OLMCs have sixteen product terms (pins 18 and 19). In addit= ion to the product terms available for logic, each OLMC has an additional produ= ct-term dedicated to output enable control. No wonder the fuse table is variable length vs. fixed length for PAL. But = i would build the NGAL with fixed 16 product terms. Fuses and gates are ch= eap. 16K bits or 2K bytes EEPROM should do it. On newer process, it could= be build below $1. =20 So, bring back my GAL to me. Bring back. Bring back, Bring back my old GAL= to me.
On Sunday, October 5, 2014 4:19:41 PM UTC-7, rickman wrote:
> On 10/5/2014 4:17 PM, N_Cook wrote: > > On 05/10/2014 20:18, rickman wrote: > >> On 10/5/2014 2:20 PM, N_Cook wrote: > >>> just 0 to 9 digits, no alphamumerics, not even +/- > > >> What about blank digits? Will the digit always be one of the 10 values or can it be off? > > > The on condition but no reading state of the display is 00.00 but I can ignore the "." , its fixed range > > Are your digits multiplexed? How will you get the four digits into the PAL?
If not multiplexed, latch into 4 separate GAL and shift 16 bits into the micro. If multiplexed, latch 7 segment + 4 commons into 2 GAL and shift 11 bits into the micro. Then sort it out in software. Sample it at 100MHz clock, get around 6Msps (case 1) and 9Msps (case 2). Check for invalid state or soft "phase lock" into the signal's transition phase. After a while, you can drop it back to a more reasonable sample rate.
On 05/10/2014 17:19, N_Cook wrote:
> driven off a uC, to give a remotely monitorable feed
If you can transmit 4 bits of bcd to the remote location then just wondering if you could simply transmit all seven segment bits and have the translation done at the remote receiving end? piglet
On 05/10/2014 17:19, N_Cook wrote:
> "mapping", output could be linear per digit rather than bcd.
When you write "linear per digit" do you mean an analog voltage like 0-9V or one-of-ten digital lines or what exactly please? piglet