On 10/5/2014 10:46 AM, edward.ming.lee@gmail.com wrote:> On Sunday, October 5, 2014 10:24:23 AM UTC-7, Don Y wrote: >> On 10/5/2014 9:19 AM, N_Cook 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.Talk about overkill...>> 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.And, this is the $160 solution?>> The basic approach is simple: just build some Karnaugh maps describing >> each segment's performance. Then, cover the most appropriate ones with >> minterms to get your *desired* outputs (subject to the above notes) > > Nope, don't need to optimize gates inside the GAL or for nano seconds. Just > decode the 1s and 0s. > > However, OP might need more than one digit. So, build the output as > cascadeable shift registers: > > ; A B C D E F G > ; D6 D5 D4 D3 D2 D1 D0 Q3 Q2 Q1 Q0 > ; 0: 1 1 1 1 1 1 1 0 0 0 0Your 0's look a helluva lot like 8's! <grin> Isn't this the SECOND time I've found errors in one of your GAL implementations? So, I won't bother checking your sums and products. Wanna bet this simplifies to a "few less-than-7-input gates" when you consider don't cares?? :> From CASUAL INSPECTION -- no effort to minimize (assumes tails on 6 and 9): 0 = F*/G 1 = /A*/F*/G 2 = /C 3 = C*/F*G 4 = /D*F 5 = /B*C*/E 6 = /B*C*E 7 = A*/F*/G 8 = B*D*E*F*G 9 = B*D*/E*F*G [The rest of this is a mess because you opted to post with long line lengths -- I have no desire to pretty-it-up]> ; 1: 0 1 1 0 0 0 0 0 0 0 1 ; > 2: 1 1 0 1 1 0 1 0 0 1 0 ; 3: 1 1 1 1 0 0 1 0 0 1 > 1 ; 4: 0 1 1 0 0 1 1 0 1 0 0 ; 5: 1 0 1 1 0 1 1 0 > 1 0 1 ; 6: 1 0 1 1 1 1 1 0 1 1 0 ; 7: 1 1 1 0 0 0 0 > 0 1 1 1 ; 8: 1 1 1 1 1 1 1 1 0 0 0 ; 9: 1 1 1 1 0 1 > 1 1 0 0 1 ; ; D7 = Load, D8 = Shift (rotate) > > Q3 = D8*Q2 + D7*D6*D5*D4*D3*D2*D1*D0 + D7*D6*D5*D4*D3*/D2*D1*D0 > > Q2 = D8*Q1 + D7*/D6*D5*D4*/D3*/D2*D1*D0 + D7*D6*/D5*D4*D3*/D2*D1*D0 + > D7*D6*/D5*D4*D3*D2*D1*D0 + D7*D6*D5*D4*/D3*/D2*/D1*/D0 > > Q1 = D8*Q0 + D7*D6*D5*/D4*D3*D2*/D1*D0 + D7*D6*D5*D4*D3*/D2*/D1*D0 + > D7*D6*/D5*D4*D3*D2*D1*D0 + D7*D6*D5*D4*/D3*/D2*/D1*/D0 > > Q0 = D8*Q3 + D7*/D6*D5*D4*/D3*/D2*/D1*/D0 + D7*D6*D5*D4*D3*/D2*/D1*D0 + > D7*D6*D5*D4*/D3*/D2*/D1*/D0 + D7*D6*D5*D4*/D3*/D2*/D1*/D0 + > D7*D6*D5*D4*D3*/D2*D1*D0 >
7-segment LCD to BCD decoder ?
Started by ●October 5, 2014
Reply by ●October 5, 20142014-10-05
Reply by ●October 5, 20142014-10-05
> >> Assuming one back-plane to consider , what would be most efficient com=ponent-count/least complex discrete/CMOS/74 route , ie not pic/Pi/uC to fir= stly 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>=20 > > First, you'd need to characterize the drive -- how much skew is there b=etween backplane drive and segment on/off drives (any skew will appear as p= otential glitches on a static, combinatorial logic decoder so you would hav= e to *sample* the decoded outputs at some epsilon after each BP clock edge)= .>=20 > > [epsilon can be large-ish if a MCU is "decoding in software". >=20 > > Also, consider temperature effects on the drive] >=20 > > You would also need to look at the particular "font" that is implemente=d: do 6's have tails? what about 9's? (sometimes 6 will have but 9 won'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 colli= de with some of the "don't cares" in your decoder logic.>=20 > > The basic approach is simple: just build some Karnaugh maps describing=each segment's performance. Then, cover the most appropriate ones with mi= nterms to get your *desired* outputs (subject to the above notes)>=20 > > Note that it is *really* important to understand how the display is act=ually being driven. You can play games with the visual characteristics of = LCD's by driving them in unconventional (yet "legal") ways.>=20 > The other consideration is often there is a contrast control which AFAIK =is variation of the fractional step change voltages, so more complication = unless you set for one contrast setting only No problem, as long as the output is above logic high level. Might be a goo= d idea to have Schmidt trigger on the GAL inputs. I am working on a progra= mmer. Perhaps if i got enough money, i can build a 16 macro-cell NGAL (New= Gen). Brother, can you spare a million? Anyway, need shift data D9 in: ----------------------- Definitions ----------------------------------- GAL22V10 ; Device definition ; Pin definition ;[24 [23] [22] [21] [20] [19] [18] [17] [16] [15] [14] [13] VCC Q0 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 NC ;[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] CLK D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 GND ; +- A -+ ; F B ; |- G -| ; E C ; +- D -+ ; ; A B C D E F G =20 ; D6 D5 D4 D3 D2 D1 D0 Q3 Q2 Q1 Q0 ; 0: 1 1 1 1 1 1 1 0 0 0 0 ; 1: 0 1 1 0 0 0 0 0 0 0 1 ; 2: 1 1 0 1 1 0 1 0 0 1 0 ; 3: 1 1 1 1 0 0 1 0 0 1 1 ; 4: 0 1 1 0 0 1 1 0 1 0 0 ; 5: 1 0 1 1 0 1 1 0 1 0 1 ; 6: 1 0 1 1 1 1 1 0 1 1 0 ; 7: 1 1 1 0 0 0 0 0 1 1 1 ; 8: 1 1 1 1 1 1 1 1 0 0 0 ; 9: 1 1 1 1 0 1 1 1 0 0 1 ; ; D7 =3D Load, D8 =3D Shift, D9 =3D SDI ; EQUATIONS Q3 =3D D8*Q2=20 + D7*D6*D5*D4*D3*D2*D1*D0=20 + D7*D6*D5*D4*D3*/D2*D1*D0=20 Q2 =3D D8*Q1=20 + D7*/D6*D5*D4*/D3*/D2*D1*D0=20 + D7*D6*/D5*D4*D3*/D2*D1*D0=20 + D7*D6*/D5*D4*D3*D2*D1*D0=20 + D7*D6*D5*D4*/D3*/D2*/D1*/D0 Q1 =3D D8*Q0=20 + D7*D6*D5*/D4*D3*D2*/D1*D0=20 + D7*D6*D5*D4*D3*/D2*/D1*D0=20 + D7*D6*/D5*D4*D3*D2*D1*D0=20 + D7*D6*D5*D4*/D3*/D2*/D1*/D0 Q0 =3D D8*D9=20 + D7*/D6*D5*D4*/D3*/D2*/D1*/D0=20 + D7*D6*D5*D4*D3*/D2*/D1*D0=20 + D7*D6*D5*D4*/D3*/D2*/D1*/D0=20 + D7*D6*D5*D4*/D3*/D2*/D1*/D0=20 + D7*D6*D5*D4*D3*/D2*D1*D0 --------------------JEDEC file -------------------------------- *F0 *G0 *QF5892 *L0044 11111111111111111111111111111111111111111111 *L0088 11111111111111111111111111111111111101110111 *L0132 11111011101110111011011101111011011111111111 *L0176 11110111101110110111011101110111011111111111 *L0220 11111011101110111011011101110111011111111111 *L0264 11111011101110111011011101110111011111111111 *L0308 11110111011110110111011101110111011111111111 *L0440 11111111111111111111111111111111111111111111 *L0484 11011111111111111111111111111111111101111111 *L0528 11110111101101110111101101110111011111111111 *L0572 11110111101110110111011101110111011111111111 *L0616 11110111011101110111011110110111011111111111 *L0660 11111011101110111011011101110111011111111111 *L0924 11111111111111111111111111111111111111111111 *L0968 11111101111111111111111111111111111101111111 *L1012 11110111011110111011011101111011011111111111 *L1056 11110111011110110111011110110111011111111111 *L1100 11110111011101110111011110110111011111111111 *L1144 11111011101110111011011101110111011111111111 *L1496 11111111111111111111111111111111111111111111 *L1540 11111111110111111111111111111111111101111111 *L1584 11110111011101110111011101110111011111111111 *L1628 11110111011110110111011101110111011111111111 *L5808 11111111000000000000 *L5828 0000000000000000000000000000000000000000000000000000000000000000 *C797e * =0310ee7
Reply by ●October 5, 20142014-10-05
> >>> Assuming one back-plane to consider , what would be most efficient co=mponent-count/least complex discrete/CMOS/74 route , ie not pic/Pi/uC to fi= rstly 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-th= e-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 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 ha= ve 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".>=20 > >> Also, consider temperature effects on the drive] >=20 > > GAL can handle it, perhaps even pll/sampling the microcontroller clock.=The GAL can run at 150MHz.>=20 > Talk about overkill... >=20 > >> You would also need to look at the particular "font" that is implement=ed: 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 collid= e with some of the "don't cares" in your decoder logic.>=20 > > Just details. GAL22V10 can handle any possible combinations of 7 input=s, or even up to 10 inputs.>=20 > And, this is the $160 solution?No, the 33 cents chip will do.> >> The basic approach is simple: just build some Karnaugh maps describin=g each segment's performance. Then, cover the most appropriate ones with m= interms to get your *desired* outputs (subject to the above notes)>=20 > > Nope, don't need to optimize gates inside the GAL or for nano seconds. =Just decode the 1s and 0s.>=20 > > However, OP might need more than one digit. So, build the output as ca=scadeable shift registers:>=20 > > ; A B C D E F G > > ; D6 D5 D4 D3 D2 D1 D0 Q3 Q2 Q1 Q0 > > ; 0: 1 1 1 1 1 1 1 0 0 0 0 >=20 > Your 0's look a helluva lot like 8's! <grin> Isn't this the SECOND time=I've found errors in one of your GAL implementations? So, I won't bother = checking your sums and products. Good catch. That's why we post in usenet, to check/catch mistakes. =20> Wanna bet this simplifies to a "few less-than-7-input gates" when you con=sider don't cares?? :> It still costs the same 33 cents.> From CASUAL INSPECTION -- no effort to minimize (assumes tails on 6 and =9):>=20 > 0 =3D F*/G > 1 =3D /A*/F*/G > 2 =3D /C > 3 =3D C*/F*G > 4 =3D /D*F > 5 =3D /B*C*/E > 6 =3D /B*C*E > 7 =3D A*/F*/G > 8 =3D B*D*E*F*G > 9 =3D B*D*/E*F*G >=20 > [The rest of this is a mess because you opted to post with long line leng=ths -- I have no desire to pretty-it-up] Blame Google or build another web based news group. I will be happy to swi= tch.
Reply by ●October 5, 20142014-10-05
On 10/5/2014 11:20 AM, N_Cook wrote:> just 0 to 9 digits, no alphamumerics, not even +/-How do you want to handle "space" (blanked)?
Reply by ●October 5, 20142014-10-05
On 10/5/2014 11:17 AM, N_Cook wrote:> On 05/10/2014 18:24, Don Y wrote: >> On 10/5/2014 9:19 AM, N_Cook 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] >> >> 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. >> >> The basic approach is simple: just build some Karnaugh maps >> describing each segment's performance. Then, cover the most >> appropriate ones with minterms to get your *desired* outputs >> (subject to the above notes) >> >> Note that it is *really* important to understand how the display >> is actually being driven. You can play games with the visual >> characteristics of LCD's by driving them in unconventional (yet >> "legal") ways. > > The other consideration is often there is a contrast control which AFAIK is > variation of the fractional step change voltages, so more complication unless > you set for one contrast setting onlyChances are (?), you will need some sort of level translation *somewhere*. You can accommodate some amount of variability *there*. (driving high impedance inputs menas you might even be able to just use some resistive dividers, etc.) IMO, the biggest issue will be knowing *when* to "look" at the data (segments and/or output of your "decoder") as you may not have RELIABLE data on how the data appears on the display pins wrt the backplane drive (phase). Nonmultiplexed displays have a lot of latitude in how they react (visibly) to often significant changes in drive. Your logic (or, whatever your circuit eventually feeds) may not expect that. Gotta run -- off to a "reception" (which most probably will NOT be "fun")
Reply by ●October 5, 20142014-10-05
On 10/5/2014 1:46 PM, edward.ming.lee@gmail.com wrote:> On Sunday, October 5, 2014 10:24:23 AM UTC-7, Don Y wrote: >> On 10/5/2014 9:19 AM, N_Cook 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 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.>> The basic approach is simple: just build some Karnaugh maps describing each segment's performance. Then, cover the most appropriate ones with minterms to get your *desired* outputs (subject to the above notes) > > Nope, don't need to optimize gates inside the GAL or for nano seconds. Just decode the 1s and 0s. > > However, OP might need more than one digit. So, build the output as cascadeable shift registers: > > ; A B C D E F G > ; D6 D5 D4 D3 D2 D1 D0 Q3 Q2 Q1 Q0 > ; 0: 1 1 1 1 1 1 1 0 0 0 0 > ; 1: 0 1 1 0 0 0 0 0 0 0 1 > ; 2: 1 1 0 1 1 0 1 0 0 1 0 > ; 3: 1 1 1 1 0 0 1 0 0 1 1 > ; 4: 0 1 1 0 0 1 1 0 1 0 0 > ; 5: 1 0 1 1 0 1 1 0 1 0 1 > ; 6: 1 0 1 1 1 1 1 0 1 1 0 > ; 7: 1 1 1 0 0 0 0 0 1 1 1 > ; 8: 1 1 1 1 1 1 1 1 0 0 0 > ; 9: 1 1 1 1 0 1 1 1 0 0 1 > ; > ; D7 = Load, D8 = Shift (rotate) > > Q3 = D8*Q2 > + D7*D6*D5*D4*D3*D2*D1*D0 > + D7*D6*D5*D4*D3*/D2*D1*D0 > > Q2 = D8*Q1 > + D7*/D6*D5*D4*/D3*/D2*D1*D0 > + D7*D6*/D5*D4*D3*/D2*D1*D0 > + D7*D6*/D5*D4*D3*D2*D1*D0 > + D7*D6*D5*D4*/D3*/D2*/D1*/D0 > > Q1 = D8*Q0 > + D7*D6*D5*/D4*D3*D2*/D1*D0 > + D7*D6*D5*D4*D3*/D2*/D1*D0 > + D7*D6*/D5*D4*D3*D2*D1*D0 > + D7*D6*D5*D4*/D3*/D2*/D1*/D0 > > Q0 = D8*Q3 > + D7*/D6*D5*D4*/D3*/D2*/D1*/D0 > + D7*D6*D5*D4*D3*/D2*/D1*D0 > + D7*D6*D5*D4*/D3*/D2*/D1*/D0 > + D7*D6*D5*D4*/D3*/D2*/D1*/D0 > + D7*D6*D5*D4*D3*/D2*D1*D0 >-- Rick
Reply by ●October 5, 20142014-10-05
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? -- Rick
Reply by ●October 5, 20142014-10-05
On 10/5/2014 12:17 PM, rickman wrote:> On 10/5/2014 1:46 PM, edward.ming.lee@gmail.com wrote: >> On Sunday, October 5, 2014 10:24:23 AM UTC-7, Don Y wrote: >>> On 10/5/2014 9:19 AM, N_Cook 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.Exactly. Fun experiment: drive backplane with Fo and feed the "segment drivers" with 2*Fo. Observe results (visually -- AND ON A 'SCOPE!)
Reply by ●October 5, 20142014-10-05
> >>> Assuming one back-plane to consider , what would be most efficient co=mponent-count/least complex discrete/CMOS/74 route , ie not pic/Pi/uC to fi= rstly 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-th= e-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 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 ha= ve 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, con= sider temperature effects on the drive]>=20 > > GAL can handle it, perhaps even pll/sampling the microcontroller clock.=The GAL can run at 150MHz.>=20 > You are missing the point. The display signals may not be 100% in lock s=tep. 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.>=20 > >> You would also need to look at the particular "font" that is implement=ed: do 6's have tails? what about 9's? (sometimes 6 will have but 9 won'= t).>=20 > >> And, any "other characters" that the display might present from time t=o time (e.g., 'A', 'o', 'P', 'H', 'h', 'e', 'L', 'E', etc.) that might coll= ide with some of the "don't cares" in your decoder logic.>=20 > > Just details. GAL22V10 can handle any possible combinations of 7 input=s, or even up to 10 inputs.>=20 > But there are limited product terms. How many product terms does each ou=tput have? You may need as many as 10 product terms. 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.> >> The basic approach is simple: just build some Karnaugh maps describin=g each segment's performance. Then, cover the most appropriate ones with m= interms to get your *desired* outputs (subject to the above notes)>=20 > > Nope, don't need to optimize gates inside the GAL or for nano seconds. =Just decode the 1s and 0s.>=20 > > However, OP might need more than one digit. So, build the output as ca=scadeable shift registers:>=20 > > ; A B C D E F G > > ; D6 D5 D4 D3 D2 D1 D0 Q3 Q2 Q1 Q0 > > ; 0: 1 1 1 1 1 1 1 0 0 0 0 > > ; 1: 0 1 1 0 0 0 0 0 0 0 1 > > ; 2: 1 1 0 1 1 0 1 0 0 1 0 > > ; 3: 1 1 1 1 0 0 1 0 0 1 1 > > ; 4: 0 1 1 0 0 1 1 0 1 0 0 > > ; 5: 1 0 1 1 0 1 1 0 1 0 1 > > ; 6: 1 0 1 1 1 1 1 0 1 1 0 > > ; 7: 1 1 1 0 0 0 0 0 1 1 1 > > ; 8: 1 1 1 1 1 1 1 1 0 0 0 > > ; 9: 1 1 1 1 0 1 1 1 0 0 1 >=20 > > ; D7 =3D Load, D8 =3D Shift, D9 =3D Serial Data In >=20 > > Q3 =3D D8*Q2 > > + D7*D6*D5*D4*D3*D2*D1*D0 > > + D7*D6*D5*D4*D3*/D2*D1*D0 >=20 > > Q2 =3D D8*Q1 > > + D7*/D6*D5*D4*/D3*/D2*D1*D0 > > + D7*D6*/D5*D4*D3*/D2*D1*D0 > > + D7*D6*/D5*D4*D3*D2*D1*D0 > > + D7*D6*D5*D4*/D3*/D2*/D1*/D0 >=20 > > Q1 =3D D8*Q0 > > + D7*D6*D5*/D4*D3*D2*/D1*D0 > > + D7*D6*D5*D4*D3*/D2*/D1*D0 > > + D7*D6*/D5*D4*D3*D2*D1*D0 > > + D7*D6*D5*D4*/D3*/D2*/D1*/D0 >=20 > > Q0 =3D D8*Q3 > > + D7*/D6*D5*D4*/D3*/D2*/D1*/D0 > > + D7*D6*D5*D4*D3*/D2*/D1*D0 > > + D7*D6*D5*D4*/D3*/D2*/D1*/D0 > > + D7*D6*D5*D4*/D3*/D2*/D1*/D0 > > + D7*D6*D5*D4*D3*/D2*D1*D0 >=20
Reply by ●October 5, 20142014-10-05
On 10/5/2014 3:16 PM, Don Y wrote:> On 10/5/2014 11:17 AM, N_Cook wrote: >> On 05/10/2014 18:24, Don Y wrote: >>> On 10/5/2014 9:19 AM, N_Cook 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] >>> >>> 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. >>> >>> The basic approach is simple: just build some Karnaugh maps >>> describing each segment's performance. Then, cover the most >>> appropriate ones with minterms to get your *desired* outputs >>> (subject to the above notes) >>> >>> Note that it is *really* important to understand how the display >>> is actually being driven. You can play games with the visual >>> characteristics of LCD's by driving them in unconventional (yet >>> "legal") ways. >> >> The other consideration is often there is a contrast control which >> AFAIK is >> variation of the fractional step change voltages, so more complication >> unless >> you set for one contrast setting only > > Chances are (?), you will need some sort of level translation *somewhere*. > You can accommodate some amount of variability *there*. (driving high > impedance inputs menas you might even be able to just use some resistive > dividers, etc.) > > IMO, the biggest issue will be knowing *when* to "look" at the data > (segments and/or output of your "decoder") as you may not have RELIABLE > data on how the data appears on the display pins wrt the backplane drive > (phase). Nonmultiplexed displays have a lot of latitude in how they > react (visibly) to often significant changes in drive. Your logic > (or, whatever your circuit eventually feeds) may not expect that. > > Gotta run -- off to a "reception" (which most probably will NOT be "fun")That is easy to handle. The OP has indicated he will be dealing with the XOR nature of the drive separately. That can be done with 4000 family parts. The outputs will be a fixed voltage level and can then drive the GAL/PAL. I'd be willing to bet that the backplane signal can be used as the clock for the PAL... if a clock is even needed. -- Rick
