Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.electronics.design > #518768 > unrolled thread

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

Back to article view | Back to sci.electronics.design

Contents

  Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-08 17:20 -0700
    Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Jeff Liebermann <jeffl@cruzio.com> - 2018-10-08 18:57 -0700
      Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-08 19:08 -0700
      Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-08 19:13 -0700
        Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-08 19:27 -0700
          Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Jeff Liebermann <jeffl@cruzio.com> - 2018-10-08 21:06 -0700
            Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Jeff Liebermann <jeffl@cruzio.com> - 2018-10-08 21:36 -0700
      Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL gnuarm.deletethisbit@gmail.com - 2018-10-08 20:27 -0700
        Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-08 21:19 -0700
          Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Jeff Liebermann <jeffl@cruzio.com> - 2018-10-08 21:40 -0700
            Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-09 00:20 -0700
              Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL gnuarm.deletethisbit@gmail.com - 2018-10-10 15:43 -0700
                Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-10 18:46 -0700
          Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL gnuarm.deletethisbit@gmail.com - 2018-10-08 22:11 -0700
            Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-09 00:27 -0700
      Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Rob <nomail@example.com> - 2018-10-09 17:08 +0000
    Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL "tom" <tmiller11147@verizon.net> - 2018-10-09 00:15 -0400
      Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-09 00:26 -0700
        Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2018-10-09 14:23 +0200
          Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL jrwalliker@gmail.com - 2018-10-09 06:43 -0700
            Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-09 08:41 -0700
              Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL dplatt@coop.radagast.org (Dave Platt) - 2018-10-09 10:50 -0700
        Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Jeff Liebermann <jeffl@cruzio.com> - 2018-10-09 09:15 -0700
          Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-09 10:01 -0700
            Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-10-09 21:01 +0300
              Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-09 11:13 -0700
                Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL bitrex <user@example.net> - 2018-10-09 18:35 -0400
                  Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL TTman <kraken.sankey@gmail.com> - 2018-10-09 23:43 +0100
                    Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL bitrex <user@example.net> - 2018-10-09 19:49 -0400
                      Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL bitrex <user@example.net> - 2018-10-09 19:50 -0400
            Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Jeff Liebermann <jeffl@cruzio.com> - 2018-10-09 17:25 -0700
              Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-09 19:15 -0700
            Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL gnuarm.deletethisbit@gmail.com - 2018-10-10 16:46 -0700
              Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2018-10-11 02:08 +0200
                Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL gnuarm.deletethisbit@gmail.com - 2018-10-10 18:37 -0700
                  Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2018-10-11 13:35 +0200
        Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL gnuarm.deletethisbit@gmail.com - 2018-10-10 15:45 -0700
          Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-10 18:50 -0700
            Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL Jasen Betts <jasen@xnet.co.nz> - 2018-10-11 05:39 +0000
    Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL bitrex <user@example.net> - 2018-10-09 02:18 -0400
    Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL TTman <kraken.sankey@gmail.com> - 2018-10-09 17:51 +0100
      Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL bitrex <user@example.net> - 2018-10-09 17:38 -0400
    Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Larkin <jjlarkin@highland_snip_technology.com> - 2018-10-09 17:52 -0700
      Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL John Robertson <spam@flippers.com> - 2018-10-09 19:16 -0700
      Re: Need to construct the logical reverse of a 7448 - perhaps using a GAL bitrex <user@example.net> - 2018-10-09 22:48 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#518826

On 2018/10/09 6:43 AM, jrwalliker@gmail.com wrote:
> On Tuesday, 9 October 2018 13:23:50 UTC+1, Gerhard Hoffmann  wrote:
>> Am 09.10.2018 um 09:26 schrieb John Robertson:
>>> On 2018/10/08 9:15 PM, tom wrote:
>>
>>>> One way to do it is to use an EPROM.  Connect the seven segments to
>>>> AD0 to
>>>> AD6. Use the first four data outputs (D0 to D3) for the BCD code. Make
>>>> up a
>>>> table with the correct memory locations to put 1s in for the decoder. Tie
>>>> /CE and /CS to the appropriate levels. A 2716 would work fine, just
>>>> ignore
>>>> the unwanted outputs and tie AD7 to ground.
>>>>
>>>>
>>>> Regards
>>>>
>>>>
>>>
>>> Was looking for tiny, I have lots of Eproms, but space, eh? An Eprom
>>> would be simple too. The look up table would only take 15 bytes, you
>>> would use the Address lines A0-A3 with the Data lines being the outputs.
>>> 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...
>>
>> Someone I knew got bitten by that. He had an EPROM that contained
>> dynamic logic. It would present the correct data, but after some
>> time the data turned wrong. Hold time was not eternal.
>>
>> Perfectly OK for a processor, but not for character mapping of a
>> mechanical teletype.
>>
>> :-) Gerhard
> 
> EPROMs can be nice for this sort of thing, but there are likely to be
> some glitches before the outputs settle to the values you are
> expecting.  This may or may not matter, depending on what comes next
> in your system. If one of the outputs is being used to generate a clock
> for a peripheral it really matters!
> 
> As mentioned above, a small processor will probably give you the
> smallest solution.
> 
> John
> 
> 
> John
>   
> 

This is for very slow logic - a few hertz - so settling time is not an 
issue. Basically I am taking the output of a still available obsolete 
CPU that originally fed a 7-segment display directly through a driver 
and using it to replace an unobtanium obsolete CPU array that drove a 
7448 - want the circuit to be simple from the end users perspective - 
rip the 3 old chips out and plug in a replacement sub-board with no 
added work required. An $1.50USD EPROM is just fine and saves me a bunch 
of time in the design stage. Production is expected to be low, under 
50/year, but keeps those customers happy!

Thanks for all the suggestions!

John :-#)#

[toc] | [prev] | [next] | [standalone]

#518835

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.

[toc] | [prev] | [next] | [standalone]

#518828

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>

-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

[toc] | [prev] | [next] | [standalone]

#518831

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 :-#)#

[toc] | [prev] | [next] | [standalone]

#518837

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.  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 :-#)#

IIRC, there are ARMs (Cortex-M0) which cost less than a dollar.
The same applies to the tiny AVR.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#518838

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.  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 :-#)#
> 
> 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."

[toc] | [prev] | [next] | [standalone]

#518844

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.  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 :-#)#
>>
>> 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));
}

[toc] | [prev] | [next] | [standalone]

#518845

> 
>    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));
> }
> 
> 
> 
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

[toc] | [prev] | [next] | [standalone]

#518849

On 10/09/2018 06:43 PM, TTman wrote:
> 
>>
>>    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));
>> }
>>
>>
>>
> 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
> 

[toc] | [prev] | [next] | [standalone]

#518850

On 10/09/2018 07:49 PM, bitrex wrote:
> On 10/09/2018 06:43 PM, TTman wrote:
>>
>>>
>>>    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));
>>> }
>>>
>>>
>>>
>> 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

Also more error-prone

[toc] | [prev] | [next] | [standalone]

#518851

On Tue, 9 Oct 2018 10:01:05 -0700, John Robertson <spam@flippers.com>
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.  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

I see you want a 32PLCC package.

I'm not selling parts, but there are plenty for sale on eBay.  
<https://www.ebay.com/sch/i.html?_nkw=28c16>
If possible, try to get the "A" suffix version.  Most are 24 pin DIP
packages, which are probably too big.  However, there are some smaller
packages available.  For example:
<https://www.ebay.com/itm/3-PCS-ATMEL-AT28C16-20JC-IC-EEPROM-16KBIT-200NS-32PLCC-ATMEL/323143000067>

>At $1.50 it is hard to beat.

Looks like 28C16 EEPROMs are getting scarce, so the prices are high.
You probably don't need an electrically erasable EPROM, so a burn once
type is probably cheaper and good enough.  I guess the AT27C256R is
good enough.  

I assume you have an EPROM burner.  I have one of these:
<https://www.ebay.com/itm/Willem-EPROM-programmer-BIOS-4-5/222933620416>
The on board 32PLCC sockets should be useful.  It's rather clumsy to
use without a box, but since I don't use it very often, I can live
with the inconvenience.



-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

[toc] | [prev] | [next] | [standalone]

#518855

On 2018/10/09 5:25 PM, Jeff Liebermann wrote:
> On Tue, 9 Oct 2018 10:01:05 -0700, John Robertson <spam@flippers.com>
> 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.  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
> 
> I see you want a 32PLCC package.
> 
> I'm not selling parts, but there are plenty for sale on eBay.
> <https://www.ebay.com/sch/i.html?_nkw=28c16>
> If possible, try to get the "A" suffix version.  Most are 24 pin DIP
> packages, which are probably too big.  However, there are some smaller
> packages available.  For example:
> <https://www.ebay.com/itm/3-PCS-ATMEL-AT28C16-20JC-IC-EEPROM-16KBIT-200NS-32PLCC-ATMEL/323143000067>
> 
>> At $1.50 it is hard to beat.
> 
> Looks like 28C16 EEPROMs are getting scarce, so the prices are high.
> You probably don't need an electrically erasable EPROM, so a burn once
> type is probably cheaper and good enough.  I guess the AT27C256R is
> good enough.

Actually I am now leaning to using a SST39SF010A which are around $1US 
in 25 lots from Digikey - I did get an assortment of PLC to DIP 
adapters, so the 32 pin package is not a problem.

> 
> I assume you have an EPROM burner.  I have one of these:
> <https://www.ebay.com/itm/Willem-EPROM-programmer-BIOS-4-5/222933620416>
> The on board 32PLCC sockets should be useful.  It's rather clumsy to
> use without a box, but since I don't use it very often, I can live
> with the inconvenience.
> 

I have a bunch of Eprom burners, going back to an ancient Pro-Log which 
reads and burns the odd 1702. My latest is a Xeltek Superpro 610P which 
handles a lot of stuff I use, other than 1970s PROMs, so for those I 
fire up one of my Data I/O 29Bs.

Way back when I wire-wrapped an Eprom copier that went from pairs of 
2708s up to pairs of 2764s using jumper headers to select the operation. 
Used that for copying ROMs to EPROMs before I could afford a computer 
(Apple II clone was my first real computer) Still have those buried in 
my spare parts area...

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."

[toc] | [prev] | [next] | [standalone]

#518907

On Tuesday, October 9, 2018 at 1:01:16 PM UTC-4, 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.  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 :-#)#

$1.1179 qty 1

https://lcsc.com/product-detail/CPLD-FPGA_MICROCHIP_ATF16V8B-15PU_ATF16V8B-15PU_C6509.html

Rick C.

[toc] | [prev] | [next] | [standalone]

#518910

Am 11.10.2018 um 01:46 schrieb gnuarm.deletethisbit@gmail.com:
> On Tuesday, October 9, 2018 at 1:01:16 PM UTC-4, 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.  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 :-#)#
> 
> $1.1179 qty 1
> 
> https://lcsc.com/product-detail/CPLD-FPGA_MICROCHIP_ATF16V8B-15PU_ATF16V8B-15PU_C6509.html
> 
> Rick C.
> 

  <  https://www.digikey.de/products/de?keywords=%20ATF16V8B-15PU  >

€0.75 qty 1 at digikey.

cheers, Gerhard

[toc] | [prev] | [next] | [standalone]

#518918

On Wednesday, October 10, 2018 at 8:08:27 PM UTC-4, Gerhard Hoffmann wrote:
> Am 11.10.2018 um 01:46 schrieb gnuarm.deletethisbit@gmail.com:
> > On Tuesday, October 9, 2018 at 1:01:16 PM UTC-4, 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.  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 :-#)#
> > 
> > $1.1179 qty 1
> > 
> > https://lcsc.com/product-detail/CPLD-FPGA_MICROCHIP_ATF16V8B-15PU_ATF16V8B-15PU_C6509.html
> > 
> > Rick C.
> > 
> 
>   <  https://www.digikey.de/products/de?keywords=%20ATF16V8B-15PU  >
> 
> €0.75 qty 1 at digikey.
> 
> cheers, Gerhard

I'd say this is clearly a good part for this task.  It's small, cheap, easy to design.  I don't know how you might program it though.  I seem to recall reading in one group or another that it is hard to find programmers for smaller PLDs, but I bet you can find them on eBay or Aliexpress. 

Rick C.

[toc] | [prev] | [next] | [standalone]

#518950

Am 11.10.2018 um 03:37 schrieb gnuarm.deletethisbit@gmail.com:
> On Wednesday, October 10, 2018 at 8:08:27 PM UTC-4, Gerhard Hoffmann wrote:

>>
>>    <  https://www.digikey.de/products/de?keywords=%20ATF16V8B-15PU  >
>>
>> €0.75 qty 1 at digikey.
>>
>> cheers, Gerhard
> 
> I'd say this is clearly a good part for this task.  It's small, cheap, easy to design.  I don't know how you might program it though.  I seem to recall reading in one group or another that it is hard to find programmers for smaller PLDs, but I bet you can find them on eBay or Aliexpress.

I still have a Hilo All-11 programmer and a virtual Win XP machine that
can operate it. To my surprise, a Hama USB to RS232 converter worked 
perfectly.

I have used PALs and GALs a lot, until the Xilinx XC2018 & friends appeared.

(See topmost photo there: )


< 
http://www.hoffmann-hochfrequenz.de/project_gallery/project_gallery.html  >

regards, Gerhard

[toc] | [prev] | [next] | [standalone]

#518906

On Tuesday, October 9, 2018 at 3:26:16 AM UTC-4, John Robertson wrote:
> On 2018/10/08 9:15 PM, tom wrote:
> > 
> > "John Robertson" <spam@flippers.com> wrote in message
> > news:FpWdnYuq0ujJaSbGnZ2dnUU7-I_NnZ2d@giganews.com...
> >> 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 :-#)#
> >> -- 
> > 
> > One way to do it is to use an EPROM.  Connect the seven segments to AD0 to
> > AD6. Use the first four data outputs (D0 to D3) for the BCD code. Make up a
> > table with the correct memory locations to put 1s in for the decoder. Tie
> > /CE and /CS to the appropriate levels. A 2716 would work fine, just ignore
> > the unwanted outputs and tie AD7 to ground.
> > 
> > 
> > Regards
> > 
> > 
> 
> Was looking for tiny, I have lots of Eproms, but space, eh? An Eprom 
> would be simple too. The look up table would only take 15 bytes, you 
> would use the Address lines A0-A3 with the Data lines being the outputs. 
> 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...

Actually the inputs will be seven, so 128 words and four bits out, not that it makes much difference these days when small EPROMs are virtually impossible to find. 

Rick C. 

[toc] | [prev] | [next] | [standalone]

#518922

On 2018/10/10 3:45 PM, gnuarm.deletethisbit@gmail.com wrote:
> On Tuesday, October 9, 2018 at 3:26:16 AM UTC-4, John Robertson wrote:
>> On 2018/10/08 9:15 PM, tom wrote:
>>>
>>> "John Robertson" <spam@flippers.com> wrote in message
>>> news:FpWdnYuq0ujJaSbGnZ2dnUU7-I_NnZ2d@giganews.com...
>>>> 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 :-#)#
>>>> -- 
>>>
>>> One way to do it is to use an EPROM.  Connect the seven segments to AD0 to
>>> AD6. Use the first four data outputs (D0 to D3) for the BCD code. Make up a
>>> table with the correct memory locations to put 1s in for the decoder. Tie
>>> /CE and /CS to the appropriate levels. A 2716 would work fine, just ignore
>>> the unwanted outputs and tie AD7 to ground.
>>>
>>>
>>> Regards
>>>
>>>
>>
>> Was looking for tiny, I have lots of Eproms, but space, eh? An Eprom
>> would be simple too. The look up table would only take 15 bytes, you
>> would use the Address lines A0-A3 with the Data lines being the outputs.
>> 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...
> 
> Actually the inputs will be seven, so 128 words and four bits out, not that it makes much difference these days when small EPROMs are virtually impossible to find.
> 
> Rick C.
> 

When EEPROMs are under $1USD who cares if they are way over capacity? 
The device I am going to use ST39SF010A is way overkill, but I just tie 
those unused address lines to Gnd and ignore them.
It would be more elegant if devices that are under 1K in size were still 
made, but why would anyone bother?
Heck all I really need is under 160x4...

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."

[toc] | [prev] | [next] | [standalone]

#518936

On 2018-10-11, John Robertson <spam@flippers.com> wrote:
> On 2018/10/10 3:45 PM, gnuarm.deletethisbit@gmail.com wrote:
>
> When EEPROMs are under $1USD who cares if they are way over capacity? 
> The device I am going to use ST39SF010A is way overkill, but I just tie 
> those unused address lines to Gnd and ignore them.
> It would be more elegant if devices that are under 1K in size were still 
> made, but why would anyone bother?
> Heck all I really need is under 160x4...

You don't need a blanking output? 
you just want 0000 for a blank input?

-- 
  Notsodium is mined on the banks of denial.

[toc] | [prev] | [next] | [standalone]

#518793

On 10/08/2018 08:20 PM, 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 :-#)#


Might as well just use an 8 bit microcontroller like the ATTiny 2313, 
it's a dollar in quantity, doesn't need any external hardware to run at 
~8MHz which is plenty, has 2 kilobytes of program memory which is plenty.

then just sort of the KISS-ish program I can think of, in C++-ish:

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(DIGITAL_IN_PIN_1);
   state->seg_2 = digitalRead(DIGITAL_IN_PIN_2);

   // etc...
}

int decode_state(const State* state) {
   if (state->seg_1 && state->seg_2) {
     return 0x1;
   } else if (state->... {

     // 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;
       // etc.

     default:
	//do something if "decode_state" returns -1 = invalid state
   }
}

int main() {
   State state;

   for (;;) {  // loop forever
     read_state(&state);
     write_values(decode_state(&state));
   }

}

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | sci.electronics.design

csiph-web