Counting 1-6 instead of 0-9 with a 74LS192 / 74LS47

A solution that just struck me was to connect a three-input AND-gate to output a, b and c of the counter and the output of the AND to the reset-pin. 7 is 111 binary, and when the outputs are high, it will reset.

This will limit the counting to 6 (right?), but I still have no clue of how to start at 1 instead of 0. Perhaps make input-a of the counter to be high at all times?

And no, I have no knowledge about PICs or anything like that, although I know that using one would make this project easier.

--
Sincerely,                      |                http://bos.hack.org/cv/
Rikard Bosnjakovic              |         Code chef - will cook for food
------------------------------------------------------------------------

The 74LS192 has a parallel load function. So, you hard-wire the parallel load inputs to equal binary 1, and instead of doing a reset with 0111, you use it to load the counter. Sadly, the load function is active low, so you need a 3 input NAND gate for the load function.

I haven't tried this, so I don't know if there are strange glitches. However, for your application, I suspect they'll happen so fast you won't notice them.

--
Regards,
   Bob Monsen

--
The 192 has an asynchronous parallel load, so there _will_ be
glitches in the NAND\'s output which will load the 192 at unexpected
times.  The solution is either to buffer the output of the NAND with
a "D" type flip-flop or to switch to a counter with a synchronous
parallel load, like a 161 or 163.

A serendipetous result of doing it that way is that the circuit\'s
POR will set the output of the counter to zero on power-up,
capturing the first count acuurately as \'1\', and thereafter will
roll over to \'1\' inxstead of \'0\'.

Also, he can use the AND he has now and get the inversion he needs
for the load from the flip-flop\'s Q\\ output.

--
Also, if he uses this method, he only needs a two-input AND (two
diodes) to decode 0110, since the next clock will reset the counter
to 0001.

Asynchronous presets, loads, and clears are a BAD idea. Inevitably, they will glitch and cause erratic behavior. Do it right. Use a counter with a synchronous preset, such as a '160 or '161. (Since you don't count beyond 6, either binary or bcd will work.) Use a two input nand to decode state 6 (Qb !& Qc), and connect its output to the counter's preset input. Hardwire the four preset inputs to 0001b. Connect the asynchronous reset to your other reset.

Howard Delman

--
Delman Design
Digital design from conception to production
http://www.blueneptune.com/~delman

"Rikard Bosnjakovic" schreef in bericht news:sRZ_e.34958$ snipped-for-privacy@newsb.telia.net...

Rikard,

You can use the PRESET input to make the counter start at 1. As the preset is asynchronous, you have to preset when the counter reaches 7. A quick-and-dirty way to achieve this is using a three input NAND. Inputs to Qa, Qb and Qc. Output to the PRESET. You may need to stretch the pulse by an RC combination. See below. Of course the A, B, C and D -inputs of the counter have to be connected to Vcc, GND, GND and GND respectively.

__ Qa---| | ___ Qb---|& |o--|___|-+----PRESET Qc---|__| 100 | 74LS10 --- --- |1nF GND---------------+------ created by Andy´s ASCII-Circuit v1.24.140803 Beta

petrus bitbyter

Well, the counting/decoding question has been thoroughly answered - but I'm wondering, how do you get "the pulse of random length to the 555"?

I've also thought about making an oscillator that starts fast, and gradually slows down to about 1 Hz, then stops. But I don't know how to do that yet, at least not without some effort on my part. ;-)

Thanks, Rich

--
Better way:

Let the 555 astable run fast and clock the counter, and use your
SPST switch to enable the counter.  While it\'s pressed, let the
counter run, and when it\'s released, freeze the counter.

Or, while it\'s pressed, release the reset on the 555 and let it run,
and when it\'s released, hold the 555 in reset.

--
Easy.  Drive a VCO with a ramp derived from the integrated output of
the VCO and when the the ramp gets to the voltage corresponding to
1Hz, shut off the VCO.

Doesn't this help produce a more random output? Wouldn't this be preferred in this application?

--
Better yet, count down.

That way you can use the terminal count output to load the counter,
glitch-free, and get rid of the decode.

Like this:

(View with a fixed-pitch font like Courier)

                      Vcc          Vcc--+---+
                       |                |   |
                       |S1    GND---+---|---|---+------+
                       O |          |   |   |   |      |
     +-----[1K]----+   O |       +--+---+---+---+---+  |
     |  +-------+  |   |         |  D3  D2  D1  D0  |  |
     +--|TH  OUT|--+---|---------|>DOWN           MR|--+
     |  |___   _|      |         |                  |
     +-O|DIS   R|O-----+   Vcc---|>UP   LS192       |   
     |  +-------+      |         |__            ____|
  [0.1µF] 7555       [10K]    +--|PL            TCDN|--+
     |                 |      |  |  Q3  Q2  Q1  Q0  |  |
    GND               GND     |  +--+---+---+---+---+  |
                              |     |   |   |   |      |
                              +-----|---|---|---|------+
                                    |   |   |   |
                                 +--+---+---+---+--+
                                 |                 |
                                 |     LS47        |

I disagree. If you decode only the lower three bits, you are limited to 0-7. You reset the counter instantaneously on x111, so it doen not matter if it accidentally gets set to x111 since it will be forced to an allowed state after detecting the overflow. Getting reset to x000 might be a problem, but this is unlikely if the inputs are hardwired to asynchronously load an allowed value (presuambly x001). If I were paranoid, I might force a reset on both x111 and x000.

I think you are overdesigning to adhere to some hygienic principles. In this application, if all you want is a randomized output, I would cheapen it by taking taking advantage of "problems" like contact bounce, and you might even be able to eliminate the 555.

--
And, if you want to blank the LS47 while the "die is being rolled":

                        Vcc             Vcc--+---+
                         |                   |   |
                         |S1       GND---+---|---|---+------+
                         O |             |   |   |   |      |
     +-----[1K]----+     O |          +--+---+---+---+---+  |
     |  +-------+  |     |            |  D3  D2  D1  D0  |  |
     +--|TH  OUT|--+-----|------------|>DOWN           MR|--+
     |  |___   _|        |            |                  |
     +-O|DIS   R|O--+----+      Vcc---|>UP   LS192       |   
     |  +-------+   |    |            |__            ____|
  [0.1µF] 7555      |  [10K]       +--|PL            TCDN|--+
     |              |    |         |  |  Q3  Q2  Q1  Q0  |  |
    GND             |   GND        |  +--+---+---+---+---+  |
                    |              |     |   |   |   |      |
                    |         Vcc  +-----|---|---|---|------+
                    |          |         |   |   |   |
                    |        [10K]    +--+---+---+---+--+
                    |          |      |  8   4   2   1  |
                    |          |      |__ ___           |
                    |          +-----O|BI/RBO   LS47    |
                    |          |      |                 |
                    |          C                 
                    +--[47k]--B NPN
                               E
                               |     
                               | 
                              GND

--
No, since if the glitches occur (which is almost certain) they won\'t
occur randomly and there there will be states in the 1-to-6 sequence
which will be skipped by the load occurring at the improper place
because of the glitch.

I sse your concern about the data race condition. In a onesies project, I would just see if there is a poblem. If there were, or if I were doing a more careful design, a well-placed capacitor or RC at the output of the NAND could required the x111 state to last for a few hundred ns to a few us before it reset the counters.

You could tie the blanking input on the 7447 to the clock input on the

74192, and connect those to ground thought a NO PB SPST. In a non-critical application like this, I would even leave out the pullup resistor. As long as you buy a cheap switch, I think you can count on it to bounce (that was not intended as a pun, but it came out that way).

--- Even though a '192 is a synchronous counter and the outputs are all supposed to change simultaneously, if you look at the data sheet you'll find that there is a spread in time in how long it takes the outputs to change state once the clock goes high. That means that there will be glitches in the output of the decoder (if the decoder is fast enough), and for any single counter chip and decoder, the glitches will be repeatable and will appear at the same place in the count sequence, time after time, as the counter is going through its routine. For a NAND decoding x111, all that's necessary is for all three of its inputs to be high at the same time, as could happen when x101 goes to x110 if the LSB hasn't yet gone to 0 when the bit next to it goes to 1.

That means that if the broadside load is 0001, when the counter gets to 0110 the NAND will see 0111, its output will go low and it will cause the counter to do a broadside load of 0001 which will kill the counter's output, 0110, in a matter of nanoseconds. That will render it unviewable, making 0110, essentially, a disallowed state. Kinda like a die with six sides, but one of which is unstable, so you never really get to see it.

I like your idea of using contact bounce to advantage, and I think that doing that in conjunction with the last circuit I posted, which will allow the decoder to be eliminated, might be an ideal solution.

That is, as long as the switch can be guaranteed to be noisy and not have the same noise signature, time after time.

But, another problem I see is that of release bounce.

That is, doing it your way, if the switch was pressed and held, the display would show a number and, then, when the switch was released, another number would show up.

Not quite like shooting craps, huh?

-- John Fields Professional Circuit Designer

Howard,

I agree. That's why I named it "quick and dirty". But the OP uses an LS192 and asked for a solution with it. You may bet the RC is not anly stretching the pulse somewhat, it hopefully also kills unwanted gliches.

petrus bitbyter

--- Even though this appears to be a one-off, doing a design for something that someone else will be building requires that more care be put into the design effort than just throwing a bunch of parts together and hoping they'll work.

As far as the RC on the output of the NAND goes, I consider that an improper way to solve the problem inasmuch as there are better ways to go about it which don't depend on the vagaries of the circuit.

---

--- My preference tends toward a little more precision than that. YMMV.

-- John Fields Professional Circuit Designer

It's true I use an LS192 for counting, but that doesn't mean I'm limited to that IC. It only happens to be that that IC is the only counting-IC I have at home. I can, ofcourse, buy other ones.

--
Sincerely,                      |                http://bos.hack.org/cv/
Rikard Bosnjakovic              |         Code chef - will cook for food
------------------------------------------------------------------------