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

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

Binary counter - please check my work

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

Contents

  Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-28 19:14 -0400
    Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-28 16:20 -0700
      Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-28 19:31 -0400
      Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-28 22:39 -0400
        Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-28 20:07 -0700
          Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 00:27 -0400
            Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-28 22:44 -0700
              Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-28 22:46 -0700
              Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-29 10:29 -0400
                Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 11:07 -0400
                Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-04-29 20:34 -0700
                  Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-29 23:43 -0400
                    Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-04-29 21:53 -0700
                      Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-30 01:42 -0400
                        Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-04-29 23:28 -0700
                          Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-30 20:10 -0400
                            Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-30 20:26 -0400
                              Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-30 21:07 -0400
                                Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-30 21:20 -0400
                            Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-04-30 18:52 -0700
                              Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-05-01 08:43 -0400
                                Re: Binary counter - please check my work krw@notreal.com - 2017-05-01 13:33 -0400
                                Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-05-01 23:02 -0700
                                  Re: Binary counter - please check my work Jasen Betts <jasen@xnet.co.nz> - 2017-05-02 11:42 +0000
                                    Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-05-02 06:10 -0700
                                      Re: Binary counter - please check my work upsidedown@downunder.com - 2017-05-03 03:26 +0300
                                        Re: Binary counter - please check my work pcdhobbs@gmail.com - 2017-05-02 18:41 -0700
                                        Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-05-02 19:39 -0700
                                  Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-05-02 11:30 -0400
            Re: Binary counter - please check my work Jasen Betts <jasen@xnet.co.nz> - 2017-04-29 20:25 +0000
              Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-29 23:15 -0400
                Re: Binary counter - please check my work upsidedown@downunder.com - 2017-05-01 11:12 +0300
          Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 00:43 -0400
            Re: Binary counter - please check my work Winfield Hill <hill@rowland.harvard.edu> - 2017-04-29 05:31 -0700
              Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 09:48 -0400
            Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-29 08:45 -0700
              Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 12:51 -0400
                Re: Binary counter - please check my work rickman <gnuarm@gmail.com> - 2017-04-29 14:54 -0400
                Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-29 12:34 -0700
                  Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 15:51 -0400
                    Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-29 21:37 -0700
              Re: Binary counter - please check my work Jasen Betts <jasen@xnet.co.nz> - 2017-04-29 20:49 +0000
                Re: Binary counter - please check my work Don Y <blockedofcourse@foo.invalid> - 2017-04-29 14:08 -0700
                Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 17:31 -0400
                  Re: Binary counter - please check my work Jasen Betts <jasen@xnet.co.nz> - 2017-04-30 00:51 +0000
                    Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 21:42 -0400
            Re: Binary counter - please check my work bloggs.fredbloggs.fred@gmail.com - 2017-04-29 12:17 -0700
              Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-29 15:36 -0400
                Re: Binary counter - please check my work bloggs.fredbloggs.fred@gmail.com - 2017-04-30 08:00 -0700
                  Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-30 11:13 -0400
                    Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-30 11:24 -0400
                      Re: Binary counter - please check my work bloggs.fredbloggs.fred@gmail.com - 2017-04-30 08:30 -0700
                        Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-04-30 16:06 -0400
    Re: Binary counter - please check my work Jasen Betts <jasen@xnet.co.nz> - 2017-04-29 00:04 +0000
    Re: Binary counter - please check my work bill.sloman@ieee.org - 2017-04-28 21:14 -0700
    Re: Binary counter - please check my work stratus46 <stratus46@yahoo.com> - 2017-05-01 01:51 -0700
      Re: Binary counter - please check my work stratus46 <stratus46@yahoo.com> - 2017-05-01 01:56 -0700
        Re: Binary counter - please check my work bitrex <bitrex@de.lete.earthlink.net> - 2017-05-01 13:36 -0400

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

#458221

On 4/30/2017 9:52 PM, bill.sloman@ieee.org wrote:
> On Monday, May 1, 2017 at 10:10:33 AM UTC+10, rickman wrote:
>> On 4/30/2017 2:28 AM, bill.sloman@ieee.org wrote:
>>> On Sunday, April 30, 2017 at 3:42:51 PM UTC+10, rickman wrote:
>>>> On 4/30/2017 12:53 AM, bill.sloman@ieee.org wrote:
>>>>> On Sunday, April 30, 2017 at 1:43:55 PM UTC+10, rickman wrote:
>>>>>> On 4/29/2017 11:34 PM, bill.sloman@ieee.org wrote:
>>>>>>> On Sunday, April 30, 2017 at 12:29:55 AM UTC+10, rickman wrote:
>>>>>>>> On 4/29/2017 1:44 AM, Don Y wrote:
>
> <snip>
>
>>>>> Gray code counters don't produce long glitches either, but variation in propagation delays does ensure that transient false states will exist, and can be decoded by a strictly combinational decoder (if it is fast enough).
>>>>
>>>> Nonsense.  Gray code counters are registered like all counters just as
>>>> you said above.  They produce no glitches on the output because only one
>>>> bit changes at a time unlike binary counters where multiple bits change
>>>> at once with unpredictable skew making decoders glitch.
>>>
>>> Oops. I got that wrong. Long time since I looked at Gray codes.
>>>
>>> The decoded output is going to be wrong while the change is propagating through the decoder (which may not be a single stage device, which can be another source of glitches).
>>
>> What decoder?  Again you are making assumptions about some design which
>> may or may not be relevant and so is not a general rule.
>
> If there wasn't some kind of decoder there wouldn't be a problem to have a discussion about. Johnson/ring counters don't need decoders, but that wasn't where the thread started.

Of course Johnson ring counters need decoders.  They are very simple and 
decode without glitching because the counter is a Gray code but decoders 
are still required.  The only FSM that needs no decoder for individual 
states is a one-hot FSM.

-- 

Rick C

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

#458242

On Mon, 1 May 2017 08:43:41 -0400, rickman <gnuarm@gmail.com> wrote:

>On 4/30/2017 9:52 PM, bill.sloman@ieee.org wrote:
>> On Monday, May 1, 2017 at 10:10:33 AM UTC+10, rickman wrote:
>>> On 4/30/2017 2:28 AM, bill.sloman@ieee.org wrote:
>>>> On Sunday, April 30, 2017 at 3:42:51 PM UTC+10, rickman wrote:
>>>>> On 4/30/2017 12:53 AM, bill.sloman@ieee.org wrote:
>>>>>> On Sunday, April 30, 2017 at 1:43:55 PM UTC+10, rickman wrote:
>>>>>>> On 4/29/2017 11:34 PM, bill.sloman@ieee.org wrote:
>>>>>>>> On Sunday, April 30, 2017 at 12:29:55 AM UTC+10, rickman wrote:
>>>>>>>>> On 4/29/2017 1:44 AM, Don Y wrote:
>>
>> <snip>
>>
>>>>>> Gray code counters don't produce long glitches either, but variation in propagation delays does ensure that transient false states will exist, and can be decoded by a strictly combinational decoder (if it is fast enough).
>>>>>
>>>>> Nonsense.  Gray code counters are registered like all counters just as
>>>>> you said above.  They produce no glitches on the output because only one
>>>>> bit changes at a time unlike binary counters where multiple bits change
>>>>> at once with unpredictable skew making decoders glitch.
>>>>
>>>> Oops. I got that wrong. Long time since I looked at Gray codes.
>>>>
>>>> The decoded output is going to be wrong while the change is propagating through the decoder (which may not be a single stage device, which can be another source of glitches).
>>>
>>> What decoder?  Again you are making assumptions about some design which
>>> may or may not be relevant and so is not a general rule.
>>
>> If there wasn't some kind of decoder there wouldn't be a problem to have a discussion about. Johnson/ring counters don't need decoders, but that wasn't where the thread started.
>
>Of course Johnson ring counters need decoders.  They are very simple and 
>decode without glitching because the counter is a Gray code but decoders 
>are still required.  The only FSM that needs no decoder for individual 
>states is a one-hot FSM.

Its decoder is on the input to the flop.

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

#458338

On Monday, May 1, 2017 at 10:43:48 PM UTC+10, rickman wrote:
> On 4/30/2017 9:52 PM, bill.sloman@ieee.org wrote:
> > On Monday, May 1, 2017 at 10:10:33 AM UTC+10, rickman wrote:
> >> On 4/30/2017 2:28 AM, bill.sloman@ieee.org wrote:
> >>> On Sunday, April 30, 2017 at 3:42:51 PM UTC+10, rickman wrote:
> >>>> On 4/30/2017 12:53 AM, bill.sloman@ieee.org wrote:
> >>>>> On Sunday, April 30, 2017 at 1:43:55 PM UTC+10, rickman wrote:
> >>>>>> On 4/29/2017 11:34 PM, bill.sloman@ieee.org wrote:
> >>>>>>> On Sunday, April 30, 2017 at 12:29:55 AM UTC+10, rickman wrote:
> >>>>>>>> On 4/29/2017 1:44 AM, Don Y wrote:
> >
> > <snip>
> >
> >>>>> Gray code counters don't produce long glitches either, but variation in propagation delays does ensure that transient false states will exist, and can be decoded by a strictly combinational decoder (if it is fast enough).
> >>>>
> >>>> Nonsense.  Gray code counters are registered like all counters just as
> >>>> you said above.  They produce no glitches on the output because only one
> >>>> bit changes at a time unlike binary counters where multiple bits change
> >>>> at once with unpredictable skew making decoders glitch.
> >>>
> >>> Oops. I got that wrong. Long time since I looked at Gray codes.
> >>>
> >>> The decoded output is going to be wrong while the change is propagating through the decoder (which may not be a single stage device, which can be another source of glitches).
> >>
> >> What decoder?  Again you are making assumptions about some design which
> >> may or may not be relevant and so is not a general rule.
> >
> > If there wasn't some kind of decoder there wouldn't be a problem to have a discussion about. Johnson/ring counters don't need decoders, but that wasn't where the thread started.
> 
> Of course Johnson ring counters need decoders.  They are very simple and 
> decode without glitching because the counter is a Gray code but decoders 
> are still required.  The only FSM that needs no decoder for individual 
> states is a one-hot FSM.

Johnson/ring counters don't need decoders because the counter has as many bistables as it has states. Only one bistable is set in any one state.

The output isn't a Gray code - two outputs change state at once.

-- 
Bill Sloman, Sydney

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

#458375

On 2017-05-02, bill.sloman@ieee.org <bill.sloman@ieee.org> wrote:
>> 
>> Of course Johnson ring counters need decoders.  They are very simple and 
>> decode without glitching because the counter is a Gray code but decoders 
>> are still required.  The only FSM that needs no decoder for individual 
>> states is a one-hot FSM.
>
> Johnson/ring counters don't need decoders because the counter has as many bistables as it has states. Only one bistable is set in any one state.
>
> The output isn't a Gray code - two outputs change state at once.

Johnson counters have half as many bistables as states, and need
simple decoding

http://www.ti.com/lit/ds/symlink/cd4022b.pdf

top of page 2

-- 
This email has not been checked by half-arsed antivirus software 

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

#458382

On Tuesday, May 2, 2017 at 10:31:04 PM UTC+10, Jasen Betts wrote:
> On 2017-05-02, bill.sloman@ieee.org <bill.sloman@ieee.org> wrote:
> >> 
> >> Of course Johnson ring counters need decoders.  They are very simple and 
> >> decode without glitching because the counter is a Gray code but decoders 
> >> are still required.  The only FSM that needs no decoder for individual 
> >> states is a one-hot FSM.
> >
> > Johnson/ring counters don't need decoders because the counter has as many bistables as it has states. Only one bistable is set in any one state.
> >
> > The output isn't a Gray code - two outputs change state at once.
> 
> Johnson counters have half as many bistables as states, and need
> simple decoding
> 
> http://www.ti.com/lit/ds/symlink/cd4022b.pdf
> 
> top of page 2

Oops! But at least I learned something. Johnson counters aren't "ring" counters, or at least not what I thought of as ring counters.

-- 
Bill Sloman, Sydney

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

#458483

On Tue, 2 May 2017 06:10:15 -0700 (PDT), bill.sloman@ieee.org wrote:

>On Tuesday, May 2, 2017 at 10:31:04 PM UTC+10, Jasen Betts wrote:
>> On 2017-05-02, bill.sloman@ieee.org <bill.sloman@ieee.org> wrote:
>> >> 
>> >> Of course Johnson ring counters need decoders.  They are very simple and 
>> >> decode without glitching because the counter is a Gray code but decoders 
>> >> are still required.  The only FSM that needs no decoder for individual 
>> >> states is a one-hot FSM.
>> >
>> > Johnson/ring counters don't need decoders because the counter has as many bistables as it has states. Only one bistable is set in any one state.
>> >
>> > The output isn't a Gray code - two outputs change state at once.
>> 
>> Johnson counters have half as many bistables as states, and need
>> simple decoding
>> 
>> http://www.ti.com/lit/ds/symlink/cd4022b.pdf
>> 
>> top of page 2
>
>Oops! But at least I learned something. Johnson counters aren't "ring" counters, or at least not what I thought of as ring counters.

Original unbuffered 4000 series CMOS was real s_l_o_w compared to
DTL/TTL chips of the  time,  Using better topologies like the Johnson
counter helped a lot.

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

#458500

>Original unbuffered 4000 series CMOS was real s_l_o_w compared to 
>DTL/TTL chips of the  time,  Using better topologies like the Johnson 
>counter helped a lot

I'm quite fond of the HC4017 for various simple timing jobs. not what you'd use in prodiction in all likelihood, but for protos and test jigs, they're the bomb. 

Cheers

Phil Hobbs

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

#458515

On Wednesday, May 3, 2017 at 10:26:33 AM UTC+10, upsid...@downunder.com wrote:
> On Tue, 2 May 2017 06:10:15 -0700 (PDT), bill.sloman@ieee.org wrote:
> 
> >On Tuesday, May 2, 2017 at 10:31:04 PM UTC+10, Jasen Betts wrote:
> >> On 2017-05-02, bill.sloman@ieee.org <bill.sloman@ieee.org> wrote:
> >> >> 
> >> >> Of course Johnson ring counters need decoders.  They are very simple and 
> >> >> decode without glitching because the counter is a Gray code but decoders 
> >> >> are still required.  The only FSM that needs no decoder for individual 
> >> >> states is a one-hot FSM.
> >> >
> >> > Johnson/ring counters don't need decoders because the counter has as many bistables as it has states. Only one bistable is set in any one state.
> >> >
> >> > The output isn't a Gray code - two outputs change state at once.
> >> 
> >> Johnson counters have half as many bistables as states, and need
> >> simple decoding
> >> 
> >> http://www.ti.com/lit/ds/symlink/cd4022b.pdf
> >> 
> >> top of page 2
> >
> >Oops! But at least I learned something. Johnson counters aren't "ring" counters, or at least not what I thought of as ring counters.
> 
> Original unbuffered 4000 series CMOS was real s_l_o_w compared to
> DTL/TTL chips of the  time,  Using better topologies like the Johnson
> counter helped a lot.

Don't remind me. I was designing it in back when it was appreciably more expensive than TTL. The parts cost for my first CMOS design dropped from 50 UK pounds to 15 UK pounds before the design got released to production.

-- 
Bill Sloman, Sydney

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

#458415

On 5/2/2017 2:02 AM, bill.sloman@ieee.org wrote:
> On Monday, May 1, 2017 at 10:43:48 PM UTC+10, rickman wrote:
>> On 4/30/2017 9:52 PM, bill.sloman@ieee.org wrote:
>>> On Monday, May 1, 2017 at 10:10:33 AM UTC+10, rickman wrote:
>>>> On 4/30/2017 2:28 AM, bill.sloman@ieee.org wrote:
>>>>> On Sunday, April 30, 2017 at 3:42:51 PM UTC+10, rickman wrote:
>>>>>> On 4/30/2017 12:53 AM, bill.sloman@ieee.org wrote:
>>>>>>> On Sunday, April 30, 2017 at 1:43:55 PM UTC+10, rickman wrote:
>>>>>>>> On 4/29/2017 11:34 PM, bill.sloman@ieee.org wrote:
>>>>>>>>> On Sunday, April 30, 2017 at 12:29:55 AM UTC+10, rickman wrote:
>>>>>>>>>> On 4/29/2017 1:44 AM, Don Y wrote:
>>>
>>> <snip>
>>>
>>>>>>> Gray code counters don't produce long glitches either, but variation in propagation delays does ensure that transient false states will exist, and can be decoded by a strictly combinational decoder (if it is fast enough).
>>>>>>
>>>>>> Nonsense.  Gray code counters are registered like all counters just as
>>>>>> you said above.  They produce no glitches on the output because only one
>>>>>> bit changes at a time unlike binary counters where multiple bits change
>>>>>> at once with unpredictable skew making decoders glitch.
>>>>>
>>>>> Oops. I got that wrong. Long time since I looked at Gray codes.
>>>>>
>>>>> The decoded output is going to be wrong while the change is propagating through the decoder (which may not be a single stage device, which can be another source of glitches).
>>>>
>>>> What decoder?  Again you are making assumptions about some design which
>>>> may or may not be relevant and so is not a general rule.
>>>
>>> If there wasn't some kind of decoder there wouldn't be a problem to have a discussion about. Johnson/ring counters don't need decoders, but that wasn't where the thread started.
>>
>> Of course Johnson ring counters need decoders.  They are very simple and
>> decode without glitching because the counter is a Gray code but decoders
>> are still required.  The only FSM that needs no decoder for individual
>> states is a one-hot FSM.
>
> Johnson/ring counters don't need decoders because the counter has as many bistables as it has states. Only one bistable is set in any one state.
>
> The output isn't a Gray code - two outputs change state at once.

I think you need to go back to google and check on that.  You are 
confusing a Johnson ring counter with a one-hot or Overbeck ring counter.

https://en.wikipedia.org/wiki/Ring_counter

-- 

Rick C

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

#458025

On 2017-04-29, bitrex <bitrex@de.lete.earthlink.net> wrote:
> On 04/28/2017 11:07 PM, Don Y wrote:
>
>> There are no "steady state" consequences of this.  However, the
>> temporal behavior of the "4th bit" will vary near the clock edge
>> as it will be more closely synchronized with the other three bits
>> in the case where the state is set-up *before* the clock edge
>> vs. derived from the TRANSITIONED third bit AFTER the clock edge.
>
> It looked to me like the only sequence of transitions where one can get 
> a set of unique bit patterns where some two bits can be ANDed or ORed 
> together to get 8 mutually exclusive "1" outputs where the output is "0" 
> in all the other states.
>
> But I believe I'm wrong. 4 choose 0 + 4 choose 1 is only 5.

for 

"8 mutually exclusive "1" outputs where the output is "0" in all the other states."

use 

CD4022  (counter)

or

74xx328 (3-bit decoder)

etc.


CD4022 may power up in a confused state with 2 outputs high, but a
reset pulse or few clocks will cure that.

-- 
This email has not been checked by half-arsed antivirus software 

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

#458062

On 4/29/2017 4:25 PM, Jasen Betts wrote:
> On 2017-04-29, bitrex <bitrex@de.lete.earthlink.net> wrote:
>> On 04/28/2017 11:07 PM, Don Y wrote:
>>
>>> There are no "steady state" consequences of this.  However, the
>>> temporal behavior of the "4th bit" will vary near the clock edge
>>> as it will be more closely synchronized with the other three bits
>>> in the case where the state is set-up *before* the clock edge
>>> vs. derived from the TRANSITIONED third bit AFTER the clock edge.
>>
>> It looked to me like the only sequence of transitions where one can get
>> a set of unique bit patterns where some two bits can be ANDed or ORed
>> together to get 8 mutually exclusive "1" outputs where the output is "0"
>> in all the other states.
>>
>> But I believe I'm wrong. 4 choose 0 + 4 choose 1 is only 5.
>
> for
>
> "8 mutually exclusive "1" outputs where the output is "0" in all the other states."
>
> use
>
> CD4022  (counter)
>
> or
>
> 74xx328 (3-bit decoder)
>
> etc.
>
>
> CD4022 may power up in a confused state with 2 outputs high, but a
> reset pulse or few clocks will cure that.

I'm not totally sure what is being requested, but would a Johnson ring 
counter do the job?  The mutually exclusive 1 outputs is what this type 
of counter is all about.  It would use a 4 bit shift register, an 
inverter and some logic to detect the various combinations of 10 and 01 
adjacent bits.

I can't find any info on a 74xx328 device.  Did you mean a 74xx138 which 
is a 3 bit to 8 output decoder?

-- 

Rick C

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

#458201

On Sat, 29 Apr 2017 23:15:54 -0400, rickman <gnuarm@gmail.com> wrote:

>On 4/29/2017 4:25 PM, Jasen Betts wrote:
>> On 2017-04-29, bitrex <bitrex@de.lete.earthlink.net> wrote:
>>> On 04/28/2017 11:07 PM, Don Y wrote:
>>>
>>>> There are no "steady state" consequences of this.  However, the
>>>> temporal behavior of the "4th bit" will vary near the clock edge
>>>> as it will be more closely synchronized with the other three bits
>>>> in the case where the state is set-up *before* the clock edge
>>>> vs. derived from the TRANSITIONED third bit AFTER the clock edge.
>>>
>>> It looked to me like the only sequence of transitions where one can get
>>> a set of unique bit patterns where some two bits can be ANDed or ORed
>>> together to get 8 mutually exclusive "1" outputs where the output is "0"
>>> in all the other states.
>>>
>>> But I believe I'm wrong. 4 choose 0 + 4 choose 1 is only 5.
>>
>> for
>>
>> "8 mutually exclusive "1" outputs where the output is "0" in all the other states."
>>
>> use
>>
>> CD4022  (counter)
>>
>> or
>>
>> 74xx328 (3-bit decoder)
>>
>> etc.
>>
>>
>> CD4022 may power up in a confused state with 2 outputs high, but a
>> reset pulse or few clocks will cure that.
>
>I'm not totally sure what is being requested, but would a Johnson ring 
>counter do the job?  The mutually exclusive 1 outputs is what this type 
>of counter is all about.  It would use a 4 bit shift register, an 
>inverter and some logic to detect the various combinations of 10 and 01 
>adjacent bits.

If the strictly bit sequence is needed,  just use four multiple input
OR/NOR gates to combine all the CD4022 Johnson counter output states
that are required for a specific output bit.

>
>I can't find any info on a 74xx328 device.  Did you mean a 74xx138 which 
>is a 3 bit to 8 output decoder?

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

#457949

On 04/28/2017 11:07 PM, Don Y wrote:
> On 4/28/2017 7:39 PM, bitrex wrote:
>> On 04/28/2017 07:20 PM, Don Y wrote:
>>> On 4/28/2017 4:14 PM, bitrex wrote:
>>>> I'd like to have a 74HC163 4-bit counter count the following sequence:
>>>>
>>>> 1000
>>>> 1001
>>>> 1010
>>>> 1011
>>>> 0100
>>>> 0101
>>>> 0110
>>>> 0111
>>>>
>>>> So A, B preset inputs grounded, C, D preset fed back from the outputs
>>>> C, D
>>>> swapped, synchronous preset enable pin (active low) NANDed from A
>>>> and B?
>>>
>>> Why not just use the three LSb's of the counter "as is"and inverting the
>>> most
>>> significant of those (with your NAND gate) to form the MSb (of four)?
>>
>> Ah, indeed, indeed.
>>
>> DUH.
>>
>> This is why I ask...;-)
>
> There are no "steady state" consequences of this.  However, the
> temporal behavior of the "4th bit" will vary near the clock edge
> as it will be more closely synchronized with the other three bits
> in the case where the state is set-up *before* the clock edge
> vs. derived from the TRANSITIONED third bit AFTER the clock edge.

"El Cheapo" 2 switch sample and hold is my ideal, but I don't know that 
it's possible:

<https://www.dropbox.com/s/t1lkycctbqojpt5/20170429_003617.jpg?dl=0>

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

#457963

bitrex wrote...
>
> "El Cheapo" 2 switch sample and hold is my ideal,
> but I don't know that it's possible:
>
><https://www.dropbox.com/s/t1lkycctbqojpt5/20170429_003617.jpg?dl=0>

 Better to use a SPDT type to switch the summing-node
 input current to ground, see AoE III, pages 916-919
 and Figure 13.47.  Current steering with no voltage
 changes on the three switch terminals.  I learned
 that trick from the HP / Agilent Master Designers.


-- 
 Thanks,
    - Win

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

#457971

On 04/29/2017 08:31 AM, Winfield Hill wrote:
> bitrex wrote...
>>
>> "El Cheapo" 2 switch sample and hold is my ideal,
>> but I don't know that it's possible:
>>
>> <https://www.dropbox.com/s/t1lkycctbqojpt5/20170429_003617.jpg?dl=0>
>
>  Better to use a SPDT type to switch the summing-node
>  input current to ground, see AoE III, pages 916-919
>  and Figure 13.47.  Current steering with no voltage
>  changes on the three switch terminals.  I learned
>  that trick from the HP / Agilent Master Designers.

Yep, I was going for something like that...The input to the multiplexer 
is being driven from this little IC that takes an analog input and spits 
out 7 band-passed and peak detected control voltages:

<https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf>

As usual I'm not using it for its intended purpose - I need to pretty 
accurately sample and hold these control voltages while the strobe 
pulses to its clock input cycles around.

What I have drawn there I don't think will work, at least with the 
4051...the 4051 only has one input and 8 outputs but for a dual 
switching arrangement inside the feedback loop it looks like each 
channel needs switches that don't share poles.

So it's get a better switch IC and/or back to the drawing board.

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

#457988

On 4/28/2017 9:43 PM, bitrex wrote:
> On 04/28/2017 11:07 PM, Don Y wrote:
>> On 4/28/2017 7:39 PM, bitrex wrote:
>>> On 04/28/2017 07:20 PM, Don Y wrote:
>>>> On 4/28/2017 4:14 PM, bitrex wrote:
>>>>> I'd like to have a 74HC163 4-bit counter count the following sequence:
>>>>>
>>>>> 1000
>>>>> 1001
>>>>> 1010
>>>>> 1011
>>>>> 0100
>>>>> 0101
>>>>> 0110
>>>>> 0111
>>>>>
>>>>> So A, B preset inputs grounded, C, D preset fed back from the outputs
>>>>> C, D
>>>>> swapped, synchronous preset enable pin (active low) NANDed from A
>>>>> and B?
>>>>
>>>> Why not just use the three LSb's of the counter "as is"and inverting the
>>>> most
>>>> significant of those (with your NAND gate) to form the MSb (of four)?
>>>
>>> Ah, indeed, indeed.
>>>
>>> DUH.
>>>
>>> This is why I ask...;-)
>>
>> There are no "steady state" consequences of this.  However, the
>> temporal behavior of the "4th bit" will vary near the clock edge
>> as it will be more closely synchronized with the other three bits
>> in the case where the state is set-up *before* the clock edge
>> vs. derived from the TRANSITIONED third bit AFTER the clock edge.
>
> "El Cheapo" 2 switch sample and hold is my ideal, but I don't know that it's
> possible:
>
> <https://www.dropbox.com/s/t1lkycctbqojpt5/20170429_003617.jpg?dl=0>

I don't see a second switch...

Presumably, you're using some combinatorial logic to "decode" the
"current state" (or "current selection?") from the counter to
control/sequence the switches.  See my notes in other post re: the
hazzard this presents (esp as you don't want to be "jittering"
the switch(es) needlessly).

You'd need to "sample" the outputs of the "decoder" at some
point after the clock edge that advances the "count".  As I
indicated, putting the extra layer of NAND on the output will
increase the time that it takes for the "count output" to
settle.  And, this can increase the time for the "decoded"
output to settle.

As such, it pushes the point at which you can reliably sample the
decoded output further from the counter's clock edge.  This
can be good -- or bad -- depending on the other edges that you
have available (e.g., if you have a known duty cycle for the
clock driving the counter, you can use the "other" edge to
sample the decoded output -- introducing a fixed and predictable
skew to the control signals.

Or, decode the "count" as an inherent part of the counting
sequence; replacing the binary counter with a suitable
gray/johnson/overbeck counter.  (see other post)

[You should be able to do this with roughly the same amount
of "logic" as your original approach]

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

#457991

On 04/29/2017 11:45 AM, Don Y wrote:
> On 4/28/2017 9:43 PM, bitrex wrote:
>> On 04/28/2017 11:07 PM, Don Y wrote:
>>> On 4/28/2017 7:39 PM, bitrex wrote:
>>>> On 04/28/2017 07:20 PM, Don Y wrote:
>>>>> On 4/28/2017 4:14 PM, bitrex wrote:
>>>>>> I'd like to have a 74HC163 4-bit counter count the following
>>>>>> sequence:
>>>>>>
>>>>>> 1000
>>>>>> 1001
>>>>>> 1010
>>>>>> 1011
>>>>>> 0100
>>>>>> 0101
>>>>>> 0110
>>>>>> 0111
>>>>>>
>>>>>> So A, B preset inputs grounded, C, D preset fed back from the outputs
>>>>>> C, D
>>>>>> swapped, synchronous preset enable pin (active low) NANDed from A
>>>>>> and B?
>>>>>
>>>>> Why not just use the three LSb's of the counter "as is"and
>>>>> inverting the
>>>>> most
>>>>> significant of those (with your NAND gate) to form the MSb (of four)?
>>>>
>>>> Ah, indeed, indeed.
>>>>
>>>> DUH.
>>>>
>>>> This is why I ask...;-)
>>>
>>> There are no "steady state" consequences of this.  However, the
>>> temporal behavior of the "4th bit" will vary near the clock edge
>>> as it will be more closely synchronized with the other three bits
>>> in the case where the state is set-up *before* the clock edge
>>> vs. derived from the TRANSITIONED third bit AFTER the clock edge.
>>
>> "El Cheapo" 2 switch sample and hold is my ideal, but I don't know
>> that it's
>> possible:
>>
>> <https://www.dropbox.com/s/t1lkycctbqojpt5/20170429_003617.jpg?dl=0>
>
> I don't see a second switch...
>
> Presumably, you're using some combinatorial logic to "decode" the
> "current state" (or "current selection?") from the counter to
> control/sequence the switches.  See my notes in other post re: the
> hazzard this presents (esp as you don't want to be "jittering"
> the switch(es) needlessly).

The idea I was thinking about was to somehow use the diodes _themselves_ 
as the switches. Kills two birds with one stone maybe - they act as the 
combinatorial logic (diode logic) and also the switch.

I'd like a sample & hold that has better performance (than just running 
8 4051 outputs to the non-inverting input of a JFET op-amp and hanging a 
cap off it) but don't think I really have the budget for 8 SPDT analogs 
switches as Win suggested. Trying to get creative here, mostly failing. :-)

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

#457999

On 4/29/2017 12:51 PM, bitrex wrote:
> On 04/29/2017 11:45 AM, Don Y wrote:
>> On 4/28/2017 9:43 PM, bitrex wrote:
>>> On 04/28/2017 11:07 PM, Don Y wrote:
>>>> On 4/28/2017 7:39 PM, bitrex wrote:
>>>>> On 04/28/2017 07:20 PM, Don Y wrote:
>>>>>> On 4/28/2017 4:14 PM, bitrex wrote:
>>>>>>> I'd like to have a 74HC163 4-bit counter count the following
>>>>>>> sequence:
>>>>>>>
>>>>>>> 1000
>>>>>>> 1001
>>>>>>> 1010
>>>>>>> 1011
>>>>>>> 0100
>>>>>>> 0101
>>>>>>> 0110
>>>>>>> 0111
>>>>>>>
>>>>>>> So A, B preset inputs grounded, C, D preset fed back from the
>>>>>>> outputs
>>>>>>> C, D
>>>>>>> swapped, synchronous preset enable pin (active low) NANDed from A
>>>>>>> and B?
>>>>>>
>>>>>> Why not just use the three LSb's of the counter "as is"and
>>>>>> inverting the
>>>>>> most
>>>>>> significant of those (with your NAND gate) to form the MSb (of four)?
>>>>>
>>>>> Ah, indeed, indeed.
>>>>>
>>>>> DUH.
>>>>>
>>>>> This is why I ask...;-)
>>>>
>>>> There are no "steady state" consequences of this.  However, the
>>>> temporal behavior of the "4th bit" will vary near the clock edge
>>>> as it will be more closely synchronized with the other three bits
>>>> in the case where the state is set-up *before* the clock edge
>>>> vs. derived from the TRANSITIONED third bit AFTER the clock edge.
>>>
>>> "El Cheapo" 2 switch sample and hold is my ideal, but I don't know
>>> that it's
>>> possible:
>>>
>>> <https://www.dropbox.com/s/t1lkycctbqojpt5/20170429_003617.jpg?dl=0>
>>
>> I don't see a second switch...
>>
>> Presumably, you're using some combinatorial logic to "decode" the
>> "current state" (or "current selection?") from the counter to
>> control/sequence the switches.  See my notes in other post re: the
>> hazzard this presents (esp as you don't want to be "jittering"
>> the switch(es) needlessly).
>
> The idea I was thinking about was to somehow use the diodes _themselves_
> as the switches. Kills two birds with one stone maybe - they act as the
> combinatorial logic (diode logic) and also the switch.
>
> I'd like a sample & hold that has better performance (than just running
> 8 4051 outputs to the non-inverting input of a JFET op-amp and hanging a
> cap off it) but don't think I really have the budget for 8 SPDT analogs
> switches as Win suggested. Trying to get creative here, mostly failing. :-)

why do they need to be SPDT?  Won't a SPST do the job?  You get four on 
a chip so 8 would only be two chips.

-- 

Rick C

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

#458008

On 4/29/2017 9:51 AM, bitrex wrote:
> On 04/29/2017 11:45 AM, Don Y wrote:
>> On 4/28/2017 9:43 PM, bitrex wrote:
>>> On 04/28/2017 11:07 PM, Don Y wrote:
>>>> On 4/28/2017 7:39 PM, bitrex wrote:
>>>>> On 04/28/2017 07:20 PM, Don Y wrote:
>>>>>> On 4/28/2017 4:14 PM, bitrex wrote:
>>>>>>> I'd like to have a 74HC163 4-bit counter count the following
>>>>>>> sequence:
>>>>>>>
>>>>>>> 1000
>>>>>>> 1001
>>>>>>> 1010
>>>>>>> 1011
>>>>>>> 0100
>>>>>>> 0101
>>>>>>> 0110
>>>>>>> 0111
>>>>>>>
>>>>>>> So A, B preset inputs grounded, C, D preset fed back from the outputs
>>>>>>> C, D
>>>>>>> swapped, synchronous preset enable pin (active low) NANDed from A
>>>>>>> and B?
>>>>>>
>>>>>> Why not just use the three LSb's of the counter "as is"and
>>>>>> inverting the
>>>>>> most
>>>>>> significant of those (with your NAND gate) to form the MSb (of four)?
>>>>>
>>>>> Ah, indeed, indeed.
>>>>>
>>>>> DUH.
>>>>>
>>>>> This is why I ask...;-)
>>>>
>>>> There are no "steady state" consequences of this.  However, the
>>>> temporal behavior of the "4th bit" will vary near the clock edge
>>>> as it will be more closely synchronized with the other three bits
>>>> in the case where the state is set-up *before* the clock edge
>>>> vs. derived from the TRANSITIONED third bit AFTER the clock edge.
>>>
>>> "El Cheapo" 2 switch sample and hold is my ideal, but I don't know
>>> that it's
>>> possible:
>>>
>>> <https://www.dropbox.com/s/t1lkycctbqojpt5/20170429_003617.jpg?dl=0>
>>
>> I don't see a second switch...
>>
>> Presumably, you're using some combinatorial logic to "decode" the
>> "current state" (or "current selection?") from the counter to
>> control/sequence the switches.  See my notes in other post re: the
>> hazzard this presents (esp as you don't want to be "jittering"
>> the switch(es) needlessly).
>
> The idea I was thinking about was to somehow use the diodes _themselves_ as the
> switches. Kills two birds with one stone maybe - they act as the combinatorial
> logic (diode logic) and also the switch.
>
> I'd like a sample & hold that has better performance (than just running 8 4051
> outputs to the non-inverting input of a JFET op-amp and hanging a cap off it)
> but don't think I really have the budget for 8 SPDT analogs switches as Win
> suggested. Trying to get creative here, mostly failing. :-)

I'm not sure what you are trying to achieve, overall.
I'd assumed you were using the counter as (or as part of) a sequencer
controlling the switches and other related circuitry/logic.  Hence
my comments on the perils of decoding *after* the "register".

But, the comment immediately above suggest you want an analog mux?

Yet, the schematic suggested you were driving N (8?) similar
circuits from one buffer amp?

Time to defrost some cheese and start making the pizza...

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

#458011

On 04/29/2017 03:34 PM, Don Y wrote:

> I'm not sure what you are trying to achieve, overall.
> I'd assumed you were using the counter as (or as part of) a sequencer
> controlling the switches and other related circuitry/logic.  Hence
> my comments on the perils of decoding *after* the "register".
>
> But, the comment immediately above suggest you want an analog mux?
>
> Yet, the schematic suggested you were driving N (8?) similar
> circuits from one buffer amp?
>
> Time to defrost some cheese and start making the pizza...

Yes, I have to both 1 -> 8 a sequence of already peak-detected positive 
DC signals that come up one after another from a single output line of 
another IC on the positive edge of a clock. And I'd like to hold each 
value in a buffer.

The schematic I posted is no good, sorry. So I'll come back when I have 
something that allows better advice to be given rather than the "I don't 
know what you're trying to do here" situation we have at the moment ;-)

[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