Forums

Need to construct the logical reverse of a 7448 - perhaps using a GAL

Started by John Robertson October 8, 2018
On 09-Oct-18 1:20 AM, John Robertson wrote:
> I am looking for a way to take the TTL level outputs (treating them as > inputs) of a 7448 and convert them back to the original BCD TTL input > levels (but as outputs) and I figured a simple socketed GAL would do the > trick for the least cost. However I don't have the skill set to build > the GAL logic table for this. Any suggestions? And no, I can't simply > remove the 7448 from the circuit. > > Go easy on me here, I can unscrew hardware, but Boolean has never been > my forte... > > Thanks! > > John :-#)#
Use a single chip micro and a bit of software....But that might not be your 'thing' ... --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 2018/10/09 9:15 AM, Jeff Liebermann wrote:
> On Tue, 9 Oct 2018 00:26:06 -0700, John Robertson <spam@flippers.com> > wrote: > >> Easy, but too big for my application. I guess I could use a tiny EPROM, >> should have looked for that I guess. Got caught up in elegant solutions... > > Swell. Now you want it small. Perhaps something like a 28C16A: > <https://www.digchip.com/datasheets/download_datasheet.php?id=548714&part-number=M28C16A> >
Size isn't everything...(ducking) Other than being obsolete it would be fine. Perhaps you have a few dozen to sell? Otherwise I'll likely go with the overkill one: AT27C256R-70JU At $1.50 it is hard to beat. Thanks, John :-#)#
Jeff Liebermann <jeffl@cruzio.com> wrote:
> On Mon, 8 Oct 2018 17:20:35 -0700, John Robertson <spam@flippers.com> > wrote: > >>I am looking for a way to take the TTL level outputs (treating them as >>inputs) of a 7448 and convert them back to the original BCD TTL input >>levels (but as outputs) and I figured a simple socketed GAL would do the >>trick for the least cost. However I don't have the skill set to build >>the GAL logic table for this. Any suggestions? And no, I can't simply >>remove the 7448 from the circuit. >> >>Go easy on me here, I can unscrew hardware, but Boolean has never been >>my forte... > > Ok, a 7 segment display to BCD converter. > <http://slidegur.com/doc/1081821/7-segment-to-bcd-converter> > The truth table on Pg 5, logic on Pg 6, and schematic on Pg 8 should > be sufficient to produce a PLA or SSI implementation.
Funny that they did not notice you don't need all segments to decode the displayed digit, assuming only valid decimal numbers are displayed. E.g. the "c" segment is on for all digits except "2", and it can be omitted entirely from the decode as the "2" can still be recognized. Similar, the "d" does not have to be included in the decode and still all valid digits can be decoded. This leaves 5 logic bits to be tested instead of 7, reducing the logic.
In article <Z6adnSF0oIWjUSHGnZ2dnUU7-SfNnZ2d@giganews.com>,
John Robertson  <spam@flippers.com> wrote:

>This is for very slow logic - a few hertz - so settling time is not an >issue.
At those speeds, and at that amount of capacity, any jellybean microcontroller with enough I/O pins and an onboard oscillator ought to do the job. Read port A, mask off top bit, indexed read to a table, write the resulting bits to port B. Lather, rinse, repeat.
On 9.10.18 20:01, John Robertson wrote:
> On 2018/10/09 9:15 AM, Jeff Liebermann wrote: >> On Tue, 9 Oct 2018 00:26:06 -0700, John Robertson <spam@flippers.com> >> wrote: >> >>> Easy, but too big for my application. I guess I could use a tiny EPROM, >>> should have looked for that I guess. Got caught up in elegant >>> solutions... >> >> Swell.&nbsp; Now you want it small.&nbsp; Perhaps something like a 28C16A: >> <https://www.digchip.com/datasheets/download_datasheet.php?id=548714&part-number=M28C16A> >> >> > > Size isn't everything...(ducking) > > Other than being obsolete it would be fine. Perhaps you have a few dozen > to sell? > > Otherwise I'll likely go with the overkill one: AT27C256R-70JU > > At $1.50 it is hard to beat. > > Thanks, > > John :-#)#
IIRC, there are ARMs (Cortex-M0) which cost less than a dollar. The same applies to the tiny AVR. -- -TV
On 2018/10/09 11:01 AM, Tauno Voipio wrote:
> On 9.10.18 20:01, John Robertson wrote: >> On 2018/10/09 9:15 AM, Jeff Liebermann wrote: >>> On Tue, 9 Oct 2018 00:26:06 -0700, John Robertson <spam@flippers.com> >>> wrote: >>> >>>> Easy, but too big for my application. I guess I could use a tiny EPROM, >>>> should have looked for that I guess. Got caught up in elegant >>>> solutions... >>> >>> Swell.&nbsp; Now you want it small.&nbsp; Perhaps something like a 28C16A: >>> <https://www.digchip.com/datasheets/download_datasheet.php?id=548714&part-number=M28C16A> >>> >>> >> >> Size isn't everything...(ducking) >> >> Other than being obsolete it would be fine. Perhaps you have a few >> dozen to sell? >> >> Otherwise I'll likely go with the overkill one: AT27C256R-70JU >> >> At $1.50 it is hard to beat. >> >> Thanks, >> >> John :-#)# > > IIRC, there are ARMs (Cortex-M0) which cost less than a dollar. > The same applies to the tiny AVR. >
Ah, yes, but while I know how to code and program EEPROMs, I am not yet proficient at ARMs/AVRs software development - although if I do many more of these projects I will need to be! Only done a couple of simple project designs with Teensy/Arduino devices... I am forced to get into FPGAs for solving another project, which for me is a steep learning curve! Considering that I bought a Spartan 3 development kit back in 2005 (or so) it seems about time I use it... So many projects, so little free time! John :-#)# -- (Please post followups or tech inquiries to the USENET newsgroup) John's Jukes Ltd. MOVED to #7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3 (604)872-5757 (Pinballs, Jukes, Video Games) www.flippers.com "Old pinballers never die, they just flip out."
On 10/09/2018 12:51 PM, TTman wrote:
> On 09-Oct-18 1:20 AM, John Robertson wrote: >> I am looking for a way to take the TTL level outputs (treating them as >> inputs) of a 7448 and convert them back to the original BCD TTL input >> levels (but as outputs) and I figured a simple socketed GAL would do >> the trick for the least cost. However I don't have the skill set to >> build the GAL logic table for this. Any suggestions? And no, I can't >> simply remove the 7448 from the circuit. >> >> Go easy on me here, I can unscrew hardware, but Boolean has never been >> my forte... >> >> Thanks! >> >> John :-#)# > Use a single chip micro and a bit of software....But that might not be > your 'thing' ...
it took me about seven minutes to write the sketch of the code for that above, this thread will probably run on for weeks tho Oh Well -
> This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus >
On 10/09/2018 02:13 PM, John Robertson wrote:
> On 2018/10/09 11:01 AM, Tauno Voipio wrote: >> On 9.10.18 20:01, John Robertson wrote: >>> On 2018/10/09 9:15 AM, Jeff Liebermann wrote: >>>> On Tue, 9 Oct 2018 00:26:06 -0700, John Robertson <spam@flippers.com> >>>> wrote: >>>> >>>>> Easy, but too big for my application. I guess I could use a tiny >>>>> EPROM, >>>>> should have looked for that I guess. Got caught up in elegant >>>>> solutions... >>>> >>>> Swell.&nbsp; Now you want it small.&nbsp; Perhaps something like a 28C16A: >>>> <https://www.digchip.com/datasheets/download_datasheet.php?id=548714&part-number=M28C16A> >>>> >>>> >>> >>> Size isn't everything...(ducking) >>> >>> Other than being obsolete it would be fine. Perhaps you have a few >>> dozen to sell? >>> >>> Otherwise I'll likely go with the overkill one: AT27C256R-70JU >>> >>> At $1.50 it is hard to beat. >>> >>> Thanks, >>> >>> John :-#)# >> >> IIRC, there are ARMs (Cortex-M0) which cost less than a dollar. >> The same applies to the tiny AVR. >> > > Ah, yes, but while I know how to code and program EEPROMs, I am not yet > proficient at ARMs/AVRs software development - although if I do many > more of these projects I will need to be! Only done a couple of simple > project designs with Teensy/Arduino devices... > > I am forced to get into FPGAs for solving another project, which for me > is a steep learning curve! Considering that I bought a Spartan 3 > development kit back in 2005 (or so) it seems about time I use it... > > So many projects, so little free time! > > John :-#)# >
This should fit fine in an AVR 8 bit with 2k or greater of program memory, compiles with the Arduino IDE, you'll have to edit the if-else if chain in "decode_state" to be appropriate for the various segment numbers I don't know them off the top of my head, and the #defines for the appropriate pin numbers for your device of choice: /* 7 segment to BCD code sketch */ #define IN_PIN_1 (1) #define IN_PIN_2 (2) #define IN_PIN_3 (3) #define IN_PIN_4 (4) #define IN_PIN_5 (5) #define IN_PIN_6 (6) #define IN_PIN_7 (7) #define OUT_PIN_0 (8) #define OUT_PIN_1 (9) #define OUT_PIN_2 (10) #define OUT_PIN_3 (11) struct State { bool seg_1 = false; bool seg_2 = false; bool seg_3 = false; bool seg_4 = false; bool seg_5 = false; bool seg_6 = false; bool seg_7 = false; }; void read_state(State* state) { state->seg_1 = digitalRead(IN_PIN_1); state->seg_2 = digitalRead(IN_PIN_2); state->seg_3 = digitalRead(IN_PIN_3); state->seg_4 = digitalRead(IN_PIN_4); state->seg_5 = digitalRead(IN_PIN_5); state->seg_6 = digitalRead(IN_PIN_6); state->seg_7 = digitalRead(IN_PIN_7); } int decode_state(const State* state) { if (!state->seg_1 && !state->seg_2 && !state->seg_3 && !state->seg_4 && !state->seg_5 && !state->seg_6 && !state->seg_7) { return 0; } else if (state->seg_1 && state->seg_2) { return 1; } else if (state->seg_1 && state->seg_2 && state->seg_3) { return 2; // .... etc .... } else { return -1; } } void write_values(int value) { switch (value) { case 0: digitalWrite(OUT_PIN_0, 0); digitalWrite(OUT_PIN_1, 0); digitalWrite(OUT_PIN_2, 0); digitalWrite(OUT_PIN_3, 0); break; case 1: digitalWrite(OUT_PIN_0, 1); digitalWrite(OUT_PIN_1, 0); digitalWrite(OUT_PIN_2, 0); digitalWrite(OUT_PIN_3, 0); break; case 2: digitalWrite(OUT_PIN_0, 0); digitalWrite(OUT_PIN_1, 1); digitalWrite(OUT_PIN_2, 0); digitalWrite(OUT_PIN_3, 0); break; case 3: digitalWrite(OUT_PIN_0, 1); digitalWrite(OUT_PIN_1, 1); digitalWrite(OUT_PIN_2, 0); digitalWrite(OUT_PIN_3, 0); case 4: digitalWrite(OUT_PIN_0, 0); digitalWrite(OUT_PIN_1, 0); digitalWrite(OUT_PIN_2, 1); digitalWrite(OUT_PIN_3, 0); case 5: digitalWrite(OUT_PIN_0, 1); digitalWrite(OUT_PIN_1, 0); digitalWrite(OUT_PIN_2, 1); digitalWrite(OUT_PIN_3, 0); case 6: digitalWrite(OUT_PIN_0, 0); digitalWrite(OUT_PIN_1, 1); digitalWrite(OUT_PIN_2, 1); digitalWrite(OUT_PIN_3, 0); case 7: digitalWrite(OUT_PIN_0, 1); digitalWrite(OUT_PIN_1, 1); digitalWrite(OUT_PIN_2, 1); digitalWrite(OUT_PIN_3, 0); case 8: digitalWrite(OUT_PIN_0, 0); digitalWrite(OUT_PIN_1, 0); digitalWrite(OUT_PIN_2, 0); digitalWrite(OUT_PIN_3, 1); case 9: digitalWrite(OUT_PIN_0, 0); digitalWrite(OUT_PIN_1, 1); digitalWrite(OUT_PIN_2, 0); digitalWrite(OUT_PIN_3, 1); default: // do something if "decode_state" returns -1 = invalid state break; } } State* state; void setup() { // put your setup code here, to run once: pinMode(IN_PIN_1, INPUT_PULLUP); pinMode(IN_PIN_2, INPUT_PULLUP); pinMode(IN_PIN_3, INPUT_PULLUP); pinMode(IN_PIN_4, INPUT_PULLUP); pinMode(IN_PIN_5, INPUT_PULLUP); pinMode(IN_PIN_6, INPUT_PULLUP); pinMode(IN_PIN_7, INPUT_PULLUP); pinMode(OUT_PIN_0, OUTPUT); pinMode(OUT_PIN_1, OUTPUT); pinMode(OUT_PIN_2, OUTPUT); pinMode(OUT_PIN_3, OUTPUT); state = new State{}; } void loop() { read_state(state); write_values(decode_state(state)); }
> > &nbsp; pinMode(IN_PIN_1, INPUT_PULLUP); > &nbsp; pinMode(IN_PIN_2, INPUT_PULLUP); > &nbsp; pinMode(IN_PIN_3, INPUT_PULLUP); > &nbsp; pinMode(IN_PIN_4, INPUT_PULLUP); > &nbsp; pinMode(IN_PIN_5, INPUT_PULLUP); > &nbsp; pinMode(IN_PIN_6, INPUT_PULLUP); > &nbsp; pinMode(IN_PIN_7, INPUT_PULLUP); > > &nbsp; pinMode(OUT_PIN_0, OUTPUT); > &nbsp; pinMode(OUT_PIN_1, OUTPUT); > &nbsp; pinMode(OUT_PIN_2, OUTPUT); > &nbsp; pinMode(OUT_PIN_3, OUTPUT); > > &nbsp; state = new State{}; > } > > void loop() { > &nbsp; read_state(state); > &nbsp; write_values(decode_state(state)); > } > > >
Nice, but probaly less code lines in assembler..... but if you can't code, you can't code so each will stick with what they know and complete.... --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 10/09/2018 06:43 PM, TTman wrote:
> >> >> &nbsp;&nbsp; pinMode(IN_PIN_1, INPUT_PULLUP); >> &nbsp;&nbsp; pinMode(IN_PIN_2, INPUT_PULLUP); >> &nbsp;&nbsp; pinMode(IN_PIN_3, INPUT_PULLUP); >> &nbsp;&nbsp; pinMode(IN_PIN_4, INPUT_PULLUP); >> &nbsp;&nbsp; pinMode(IN_PIN_5, INPUT_PULLUP); >> &nbsp;&nbsp; pinMode(IN_PIN_6, INPUT_PULLUP); >> &nbsp;&nbsp; pinMode(IN_PIN_7, INPUT_PULLUP); >> >> &nbsp;&nbsp; pinMode(OUT_PIN_0, OUTPUT); >> &nbsp;&nbsp; pinMode(OUT_PIN_1, OUTPUT); >> &nbsp;&nbsp; pinMode(OUT_PIN_2, OUTPUT); >> &nbsp;&nbsp; pinMode(OUT_PIN_3, OUTPUT); >> >> &nbsp;&nbsp; state = new State{}; >> } >> >> void loop() { >> &nbsp;&nbsp; read_state(state); >> &nbsp;&nbsp; write_values(decode_state(state)); >> } >> >> >> > Nice, but probaly less code lines in assembler..... but if you can't > code, you can't code so each will stick with what they know and > complete....
They don't sell devices with sufficient pins with memory spaces less than around 2k so it's irrelevant what size the binary is for a requirement like this one. writing it in assembly to reduce binary size for an irrelevant specification on what appears to be a one-off job, even, is called "premature optimization" it's just a waste of time
> --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus >